Transaction lifecycle

An Action Plan can be evaluated without moving capital, then submitted through the executor when the caller is ready to transact. The authorisation result and the transaction receipt answer different questions: the first says whether the plan is permitted, while the second says whether the submitted operation committed.

Normal execution

Signed Action Plan
        ↓
Grantline.evaluate (read-only)
        ↓
      ALLOW
        ↓
Grantline.execute(plan, signature)
        ↓
VaultExecutor executes actions in order
        ↓
Vault calls and ActionPlanExecuted

Grantline.execute computes the digest and calls VaultExecutor.execute. The evaluator checks the complete signed plan. A result other than ALLOW becomes EvaluationDenied, so the executor does not call the Vault for a denied or escalatable normal plan. For an allowed plan, it confirms that the supplied Vault matches the Mandate, computes the digest, rejects a used or reserved nonce, and consumes the nonce through the registry before the first external Vault call.

The executor then translates each supported action into a Vault call. Native transfers call the Vault with value and an empty payload. Token transfers call the token's transfer function through the Vault and accept the standard empty or true return conventions. SWAP actions call vault.executeSwap(adapter, params) after adapter route validation. Once every action succeeds, the executor emits ActionPlanExecuted.

Escalated execution

ESCALATE
    ↓
Grantline.submitEscalation(plan, signature)
    ↓
EscalationManager stores plan and reserves nonce
    ↓
Vault controller approves
    ↓
Grantline.executeEscalated(digest)
    ↓
Current evaluation and exact digest check
    ↓
Reserved nonce consumed, actions execute, status becomes EXECUTED

The escalated entrypoint loads the complete plan and signature from EscalationManager. It requires APPROVED, evaluates the stored proposal again, and rejects only a current DENY. It then recomputes the digest, consumes the matching reservation, executes the actions, and marks the manager record EXECUTED in the same transaction.

Denied and failed paths

A read-only evaluation can return DENY with a failure code and no state change. If a caller submits that plan to the normal executor, the transaction reverts with EvaluationDenied before the registry consumes a nonce or the Vault receives a call.

An ALLOW result does not guarantee downstream success. A recipient can reject a native call, a token can return false or malformed data, a token target can fail validation, or a SWAP output can fall below minAmountOut. The executor reverts the complete plan when any action fails, so earlier actions do not remain completed and ActionPlanExecuted does not persist.

The same atomicity applies to escalated execution. If the action loop or the final escalation status update fails, the nonce, Vault calls, execution event, and status change all roll back. An approved escalation can therefore remain APPROVED after a failed attempt.

Reading the receipt

Receipt status 1 means the submitted transaction committed. Receipt status 0 means it reverted. A successful ActionPlanExecuted event proves that the complete plan reached the executor's successful execution point; it does not prove that an earlier proposal was allowed, because a read-only evaluation leaves no event, and it does not replace the transaction receipt when diagnosing a reverted attempt.

The ActionPlanExecuted event records the digest, Mandate, agent, Vault, nonce, aggregate native amount, USD valuation of the outflow, action count, projected remaining balance, and USD valuation of the remaining balance.

See Enforcement boundary for the contract roles and Records for the traceability model.