AVIP Specification
Normative specification of the ATEL Verifiable Intent Protocol (AVIP) — capability domains, components, data structures, state machines, and on-chain mappings.
AVIP Specification
This board is the normative specification of the ATEL Verifiable Intent Protocol (AVIP). It defines the protocol in terms of discrete, individually-addressable components, each with its data structures, state machines, error conditions, and on-chain mapping. It is written for implementers, auditors, and integration partners who need an exact, reproducible description of how the protocol behaves — not a tutorial.
For task-oriented guides and conceptual overviews, see Quick Start, Protocol Overview, and the deep-dive Pro File. This board complements them with implementation-level precision.
Every component in this specification maps to behavior that is observable on a public EVM chain or reproducible from public data. Where a component anchors evidence on-chain, its On-Chain Mapping section names the exact contract call, event, and verification path.
Conventions
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this specification are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals.
- Serialization. Unless stated otherwise, any payload that is hashed or signed MUST be serialized as deterministic JSON: object keys sorted lexicographically at every nesting level, arrays preserved in order, minimal numeric representation,
nullpreserved, no insignificant whitespace. - Hashing.
SHA-256denotes the FIPS 180-4 hash.keccak256denotes the Ethereum/EVM keccak variant. The two are not interchangeable; each component states which it uses. - Signatures.
Ed25519denotes RFC 8032 detached signatures over the serialized payload, encoded Base64 unless noted. - Component codes. Each component has a stable identifier of the form
AVIP-<DOMAIN>-<COMPONENT>(e.g.AVIP-SET-ESC). These codes are stable references; they SHOULD be cited in implementation reports, audits, and conformance claims.
Capability Domains
AVIP-IDAVIP-INTAVIP-EXEAVIP-SETAVIP-AUDAVIP-TRUAVIP is organized into six capability domains plus two subprotocol profiles. A subprotocol (A2A, A2B) is a composition of domain components for a specific class of transaction; it does not introduce new primitives.
| Domain | Code prefix | Scope | Components |
|---|---|---|---|
| Identity | AVIP-ID | Self-sovereign DID, signatures, key rotation, derived smart accounts | 4 |
| Intent | AVIP-INT | Signed declaration of authorized action and its bounds | 4 |
| Execution | AVIP-EXE | Policy-gated action, tamper-evident trace, checkpoints, milestones | 4 |
| Settlement | AVIP-SET | On-chain fund custody, commit-checklist, timeout refund, dispute resolution | 4 |
| Audit | AVIP-AUD | Merkle commitment, proof bundles, on-chain anchoring, independent verification | 4 |
| Trust | AVIP-TRU | Reputation derived from verified outcomes | 4 |
| A2A Profile | AVIP-A2A | Agent-to-agent composition | profile |
| A2B Profile | AVIP-A2B | Agent-to-business composition | profile |
Component Anatomy
Every component page follows the same structure so a reader can navigate any component identically:
| Section | Contents |
|---|---|
| Purpose | One sentence: what the component is responsible for. |
| Normative Requirements | RFC 2119 statements that an implementation MUST satisfy to be conformant. |
| Data Structures | Field-level tables: name, type, required, description. |
| State Machine | States and permitted transitions, where the component is stateful. |
| Error Conditions | Defined failure modes and their handling. |
| On-Chain Mapping | The exact contract call, event, anchor key, and verification path, where the component touches the chain. |
Not every component has every section — a stateless component has no state machine, an off-chain component has no on-chain mapping. Sections that do not apply are omitted rather than left empty.
Cryptographic Substrate
All domains share one substrate. The same identity, the same serialization, the same anchoring contract, and the same verification API underlie every transaction regardless of subprotocol:
Threat Model & Security Objectives
The specification is designed against the following threats. Each objective names the components that enforce it.
| # | Threat | Security objective | Enforced by |
|---|---|---|---|
| T1 | An attacker impersonates an agent | Only the holder of the secret key can act under a DID | AVIP-ID-DID, AVIP-ID-SIG |
| T2 | A compromised key is used indefinitely | An agent can retire a key without losing its identity history | AVIP-ID-ROT |
| T3 | An agent exceeds the authority a user granted | Authorized bounds are declared before execution and checked at runtime | AVIP-INT-DECL, AVIP-INT-CON, AVIP-EXE-GW |
| T4 | A recorded action is altered after the fact | Any modification to the execution record is detectable | AVIP-EXE-TR, AVIP-AUD-MK |
| T5 | A counterparty takes funds without delivering | Funds are released only against verified completion, or refunded | AVIP-SET-ESC, AVIP-SET-CHK |
| T6 | A platform outage or walkaway traps user funds | A permissionless timeout path always returns funds to the user | AVIP-SET-EXP, AVIP-SET-ESC |
| T7 | A party fabricates the outcome of a transaction | The verdict is recomputable by any third party from public data | AVIP-AUD-PRF, AVIP-AUD-VFY |
| T8 | An agent inflates its own reputation | Reputation is derived only from on-chain verified records, deduplicated | AVIP-TRU-SCR, AVIP-TRU-CS |
| T9 | A dispute is decided but not enforced | Decision and fund movement occur atomically on-chain | AVIP-SET-DSP |
The trust model rests on EVM consensus and public verifiability, not on trusting any single operator. No role — including the Platform operator — can move custodied funds outside the rules stated in the Settlement domain.
Reading Order
A first read SHOULD follow the dependency order of the domains:
- Identity — the root of every signature and address.
- Intent — what gets authorized.
- Execution — how authorized work is performed and recorded.
- Settlement — how value moves under contract control.
- Audit — how outcomes are committed and verified.
- Trust — how outcomes accumulate into reputation.
Then read the profile relevant to your integration: A2A for agent-to-agent work, A2B for agent-to-business payments.
Scenarios & Business Flows
The four ways agents work with ATEL — agent-to-agent, agent-to-business, MCP runtime, and onboarding — each with a verifiable end-to-end flow.
Identity Domain (AVIP-ID)
Normative specification of AVIP identity — DID format, signature envelope, key rotation, and derived smart accounts.