Execution Domain — AVIP-EXE

The Execution domain governs what happens between a signed Intent and its Settlement. It gates each action against the Intent, records every action in a tamper-evident chain, periodically checkpoints that chain, and — for agent-to-agent work — advances milestones.

AVIP-EXE-GW — Action Gateway

Purpose

An off-chain policy engine bound to a signed Intent that authorizes or denies each tool call before it reaches a counterparty.

Normative Requirements

For each tool call, the Gateway MUST verify all of the following, and MUST deny the call if any fails:

• The tool is in the Intent's allowedTools.
• The call's arguments are consistent with the Intent's scope and maxAmount.
• Required prerequisite tools have already succeeded (e.g. wallet.deposit before bitrefill.createInvoice).
• The Intent's deadline has not passed.
• For amounts above requiresConfirmAbove, a user-confirmation record exists.

A denied call MUST still be recorded (see Error Conditions). The Gateway MUST write exactly one ActionTrace record per call, whether allowed or denied.

Data Structures

ActionTrace record

Error Conditions

Deny records are audit-critical: they prove the system refused an out-of-policy attempt rather than silently dropping it. The records form a hash chain whose Merkle root becomes the on-chain auditRoot (see Audit).

AVIP-EXE-TR — Execution Trace

Purpose

An append-only, hash-chained log of everything that happens during task execution. Tampering with any event invalidates every subsequent hash.

Normative Requirements

• Each event MUST contain a hash computed by the formula below and a prev pointer to the previous event's hash.
• The first event of a trace MUST use 0x00 as its prev (genesis anchor).
• The event data MUST be hashed independently (SHA-256 of its deterministic serialization) before inclusion in the event preimage.
• After a terminal event (TASK_RESULT or TASK_FAILED), an implementation MUST refuse to append further events.

Event Hash Formula

event_hash = SHA-256(
    seq + "|" + timestamp + "|" + event_type + "|"
  + SHA-256(sorted_stringify(data)) + "|" + prev_hash
)

• seq — 0-based sequence number
• timestamp — ISO 8601
• event_type — one of the recognized types below
• data — payload, serialized with recursively sorted keys
• prev_hash — previous event's hash, or 0x00 for genesis

Data Structures

TraceEvent

Event types

State

Persistence

Traces are persisted as JSONL — one event per line — at {storage_dir}/{task_id}.trace.jsonl. The format supports append-only writes, streaming reads, and crash recovery. A loaded trace preserves original timestamps and hashes and MUST NOT recompute them.

AVIP-EXE-CP — Checkpoint

Purpose

A signed waypoint in the trace that captures a Merkle root and cumulative statistics, enabling verification of a long trace without processing every event.

Normative Requirements

• A checkpoint MUST be created automatically after every N non-checkpoint events (default N = 50); the counter resets after each checkpoint.
• A checkpoint event MUST be signed by the agent's Ed25519 identity over the checkpoint's own event hash.
• Checkpoint events MUST NOT count toward the next checkpoint trigger.

Data Structures

Checkpoint data

checkpoint.sig = agent_identity.sign(checkpoint.hash)

Verification

A verifier checks a checkpoint by (1) recomputing the checkpoint's event hash, (2) verifying the signature against the agent's public key from the DID, and (3) confirming the Merkle root matches a tree recomputed from the events.

AVIP-EXE-MS — Milestone

Purpose

The unit of stepwise delivery and verification in the A2A profile. A paid A2A order is divided into milestones; each is submitted, verified, and (on the final one) drives settlement.

Normative Requirements

• The milestone count MUST come from the Intent's milestoneCount (default 5).
• Each milestone MAY be submitted up to 3 times before mandatory arbitration is triggered.
• All milestones MUST pass verification before settlement releases funds.

Data Structures

Milestone trace record

State Machine

Scope compliance (withinScope) is currently a soft check — structural matching of the milestone's capability against the Intent's scope. It is a structured signal, not a cryptographically enforced guarantee, and is reported transparently as such in the Completion Proof (scopeCheckType = soft).

On-Chain Mapping

Each verified milestone is anchored via the AnchorRegistry: