Mandate rules

MandateRegistry stores the authority that binds an agent to a Vault. The stored rules are the rules written for that Mandate. The evaluator uses effective rules, which combine the active Mandate with every active ancestor in its lineage. These effective rules are the current implementation of the effective authority that a proposal can actually use.

MandateRules

The current Solidity shape is:

struct MandateRules {
    bool canDelegate;
    uint256 minNativeAmount;
    uint256 maxNativeAmount;
    bool escalateNativeAmount;
    uint256 minNativeUsd;
    uint256 maxNativeUsd;
    bool escalateNativeUsd;
}

Native amounts are integer units of the native token. On the current X Layer testnet, OKB uses 18 decimals, so 1000000000000000000 represents 1 OKB. Native-USD thresholds are whole dollars; the evaluator multiplies them by the Chainlink feed's decimal scale internally. Deployments without a configured Chainlink feed reject nonzero native-USD rules.

Both bounds in one denomination may be zero-disabled, but when both are non-zero the minimum cannot exceed the maximum. The registry rejects an invalid range when a Mandate is created or updated.

PreflightRules

The current Solidity shape is:

struct PreflightRules {
    uint256 minNativeBalance;
    bool escalateNativeBalance;
    uint256 minNativeUsdBalance;
    bool escalateNativeUsdBalance;
}

The evaluator applies these fields to the projected Vault balance after the plan's aggregate native outflow. A Preflight breach is separate from the amount range: a plan can be below a native amount maximum and still fail because the Vault would retain too little native balance or its remaining balance would fall below a USD floor.

Validity windows

Each Mandate carries validAfter and validUntil fields (both uint64). These define when the authority can be used:

• validAfter: the Mandate cannot authorise proposals before this Unix timestamp. A value of 0 means no start constraint.
• validUntil: the Mandate cannot authorise proposals after this Unix timestamp. A value of 0 means no end constraint.

When both are non-zero, validUntil must be at or after validAfter. The registry rejects an invalid window at creation and update time.

Validity windows intersect across lineage. The effective window is the tightest combination of every active ancestor:

effective validAfter  = latest ancestor validAfter
effective validUntil  = earliest ancestor validUntil

Outside the effective window, the Mandate is not active for evaluation even if its stored status is ACTIVE.

Inheritance

The registry supports a maximum delegation depth of 2. A child Mandate cannot broaden its parent's effective authority:

• the effective minimum is the greatest active minimum in the lineage;
• the effective non-zero maximum is the tightest active maximum in the lineage;
• canDelegate and every escalation flag remain enabled only when all active lineage entries enable them;
• the effective Preflight floor is the greatest active floor, and its escalation flag is also the conjunction of the lineage flags;
• the effective validity window is the intersection of all ancestor windows.

At the maximum delegation depth, canDelegate is forced off. getEffectiveRules, getEffectivePreflightRules, and getEffectiveValidityWindow require an active lineage, while getLineage can still be used to inspect a revoked lineage.

Deployment-gated behaviour

Native-USD rules and Preflight floors require a Chainlink feed to be configured on the evaluator. Deployments with a feed support minNativeUsd, maxNativeUsd, minNativeUsdBalance, and escalateNativeUsdBalance; the evaluator reads the current price from the feed at evaluation time and fails closed when the answer is unavailable or invalid. Deployments without a feed reject nonzero native-USD thresholds at Mandate creation and update time.

SWAP actions require a swap adapter to be configured on the Vault's executor. Deployments with an adapter validate pool registration, route topology, output floors, and deadline before executing. Deployments without one return SWAP_UNSUPPORTED.

Nonce cancellation, per-Vault and per-Mandate pausing, and validity windows are fully enforced regardless of deployment configuration.

See Inspect a Mandate for read-only calls and Mandates for the stable product model.