MandateRegistry contract — that defines the complete operational envelope within which a registered agent is permitted to act. Every time an agent attempts to submit a protocol interaction, the MandateRegistry validates the proposed action against the agent’s active mandate before allowing execution to proceed. Actions that fall outside the mandate’s scope are rejected at the contract level, with no possibility of override from off-chain systems.
Mandates are designed to be precise and restrictive by default. A mandate does not grant general protocol access; it grants access to a specific set of actions, on a specific set of assets, up to defined volume limits, for a bounded time period. Principals configure mandates to reflect exactly the operational scope their agents require — nothing more.
What a Mandate Defines
Each mandate record specifies:- Agent address — the on-chain identity of the authorized autonomous program
- Permitted actions — a closed enumeration of allowed operation types (
BORROW,REPAY,DEPOSIT,WITHDRAW,SWAP) - Allowed asset list — explicit allowlist of token addresses the agent may interact with
- Allowed protocols — which Synclear sub-protocols or external integrations are in scope
- Spending limits — per-transaction caps and daily rolling volume limits
- Expiry — a Unix timestamp after which the mandate is no longer valid
Mandate Lifecycle
Mandates move through a defined set of states from creation to termination. Understanding this lifecycle is essential for principals managing multiple agents or rotating credentials.1
Creation
A principal submits a mandate configuration to the
MandateRegistry contract. The mandate is stored on-chain in a PENDING state and is not yet executable by the agent. Creation requires the principal to hold the appropriate role for the account being delegated.2
Activation
The principal explicitly activates the mandate, transitioning it to
ACTIVE. From this point, the agent’s transactions are validated against it. Activation is an irreversible state transition — once active, a mandate cannot be returned to PENDING.3
Suspension
An active mandate can be suspended by the principal at any time, transitioning it to
SUSPENDED. While suspended, all agent transactions referencing this mandate are rejected. Suspension is reversible; the principal can reactivate a suspended mandate without creating a new one.4
Revocation
A mandate can be permanently revoked by the principal, transitioning it to
REVOKED. Revocation is final and irreversible. To restore agent access after revocation, a new mandate must be created and activated.Mandate Expiry
Every mandate must include an expiry timestamp at creation. Once the current block timestamp exceeds the mandate’sexpiresAt value, the MandateRegistry treats the mandate as expired and rejects all agent transactions against it. Expired mandates cannot be reactivated; the principal must create a new mandate with an updated expiry to restore agent access.
This forced expiry model ensures that delegated authorizations are periodically reviewed rather than persisting indefinitely.
Explore Mandate Configuration
Configuring Mandates
Detailed field-by-field reference for the mandate schema, plus step-by-step instructions for creating and activating a mandate through the Synclear interface.
Spending Limits
How per-transaction caps, daily rolling limits, cooldown periods, and rate limiting are defined, enforced on-chain, and queried programmatically.