ATXN: Agent-to-Agent Transaction Definition Protocol
draft-stone-atxn-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Ben Stone | ||
| Last updated | 2026-09-04 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-stone-atxn-01
Independent Submission B. Stone
Internet-Draft SwarmSync.AI
Intended status: Informational 4 September 2026
Expires: 8 March 2027
ATXN: Agent-to-Agent Transaction Definition Protocol
draft-stone-atxn-01
Abstract
This document defines a canonical, defensible, machine-checkable
primitive for an Agent-to-Agent (A2A) transaction. It establishes
the bundle of cryptographically signed elements that constitute a
recorded value exchange between two software agents acting as
instruments of identified principals, the conformance tiers that
determine which elements are required, the rail-specific Profiles
that map the bundle to existing payment infrastructure, and the two-
tier validity model that distinguishes externally-adjudicable
transactions from operationally-valid uncontested exchanges.
ATXN is the foundational legal and technical primitive for escrow,
dispute resolution, audit, and liability allocation in agentic
commerce. It is designed to produce evidence that can be mapped to
existing contract and agency frameworks without requiring agent legal
personhood. Whether a Bundle has legal effect is jurisdiction- and
fact-specific; this document does not provide a legal conclusion. It
maps directly to AP2, Stripe ACP, Visa TAP, Mastercard Agent Pay, and
x402 as Profiles of a single canonical bundle.
Companion specifications:
* *AIVS* (draft-stone-aivs-01): cryptographic audit-trail substrate
that ATXN bundles inherit from
* *VCAP* (draft-stone-vcap-01): verified-commerce escrow rails that
consume ATXN bundles
* *ATEP* (draft-stone-atep-01): trust passports that bind agents to
capacity-attested principals
* *ADRP* (draft-stone-adrp-01): dispute resolution protocol invoked
when an ATXN bundle enters the disputed state
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Stone Expires 8 March 2027 [Page 1]
Internet-Draft ATXN September 2026
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 8 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
1.1. 1.1 The Problem . . . . . . . . . . . . . . . . . . . . . 3
1.2. 1.2 What ATXN Defines . . . . . . . . . . . . . . . . . . 4
1.3. 1.3 What ATXN Deliberately Does NOT Do . . . . . . . . . 4
1.4. 1.4 Design Tenets . . . . . . . . . . . . . . . . . . . . 5
2. 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. 3. The ATXN Bundle . . . . . . . . . . . . . . . . . . . . . 7
3.1. 3.1 Element 1: Intent Mandate . . . . . . . . . . . . . . 7
3.2. 3.2 Element 2: Scope/Capability Token . . . . . . . . . . 8
3.3. 3.3 Element 3: Payment Authorization . . . . . . . . . . 10
3.4. 3.4 Element 4: Delivery Attestation . . . . . . . . . . . 10
3.5. 3.5 Element 5: Revocability Window . . . . . . . . . . . 11
4. 4. Standing Tokens and Principal Anchoring . . . . . . . . . 12
4.1. 4.1 Required Sub-Elements . . . . . . . . . . . . . . . . 13
4.2. 4.2 Capacity Attestation . . . . . . . . . . . . . . . . 13
4.3. 4.3 Pre-Committed Arbitration Mandate . . . . . . . . . . 14
4.4. 4.4 Freshness and Revocation . . . . . . . . . . . . . . 14
5. 5. Conformance Tiers . . . . . . . . . . . . . . . . . . . . 14
5.1. 5.1 Anti-Arbitrage Rule . . . . . . . . . . . . . . . . . 15
6. 6. Rail Profiles . . . . . . . . . . . . . . . . . . . . . . 15
6.1. 6.1 Profile-PLATFORM (mandatory inclusion per IdeaMatrix
dissent) . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. 6.2 Profile Composition . . . . . . . . . . . . . . . . . 16
Stone Expires 8 March 2027 [Page 2]
Internet-Draft ATXN September 2026
6.3. 6.3 AP2 and Upstream Versioning . . . . . . . . . . . . . 16
7. 7. Two-Tier Validity Model . . . . . . . . . . . . . . . . . 17
7.1. 7.1 Primary Validity . . . . . . . . . . . . . . . . . . 17
7.2. 7.2 Secondary (Operational) Validity . . . . . . . . . . 17
7.3. 7.3 Boundary . . . . . . . . . . . . . . . . . . . . . . 18
8. 8. State Machine . . . . . . . . . . . . . . . . . . . . . . 18
8.1. 8.1 Commitment Event . . . . . . . . . . . . . . . . . . 19
9. 9. Cryptographic Requirements . . . . . . . . . . . . . . . 19
9.1. 9.1 Signature Algorithms . . . . . . . . . . . . . . . . 19
9.2. 9.2 Hash Functions . . . . . . . . . . . . . . . . . . . 19
9.3. 9.3 Timestamping . . . . . . . . . . . . . . . . . . . . 19
9.4. 9.4 Key Hierarchy . . . . . . . . . . . . . . . . . . . . 19
10. 10. Dispute Triggers and ADRP Handoff . . . . . . . . . . . 20
10.1. 10.1 Dispute Triggers . . . . . . . . . . . . . . . . . 20
10.2. 10.2 ADRP Handoff . . . . . . . . . . . . . . . . . . . 20
10.3. 10.3 Conduit-Attestation Disputes . . . . . . . . . . . 21
11. 11. Liability Waterfall . . . . . . . . . . . . . . . . . . 21
12. 12. Out-of-Scope Concerns . . . . . . . . . . . . . . . . . 22
13. 13. Security Considerations . . . . . . . . . . . . . . . . 22
13.1. 13.1 Q4 Dangerous Consensus: Scope
Machine-Enforceability . . . . . . . . . . . . . . . . . 22
13.2. 13.2 Threshold-Signature Clock Compromise . . . . . . . 23
13.3. 13.3 Revocation Beacon DoS . . . . . . . . . . . . . . . 23
13.4. 13.4 Capacity Attestation as Privacy Attack Surface . . 23
13.5. 13.5 Hallucinated Mandates . . . . . . . . . . . . . . . 23
13.6. 13.6 Sub-Agency Adversarial Chains . . . . . . . . . . . 23
13.7. 13.7 Tier Arbitrage . . . . . . . . . . . . . . . . . . 23
14. 14. IANA Considerations . . . . . . . . . . . . . . . . . . 24
14.1. 14.1 ATXN Bundle JSON-LD Context . . . . . . . . . . . . 24
14.2. 14.2 ATXN Profile Registry . . . . . . . . . . . . . . . 24
14.3. 14.3 ATXN Liability Waterfall Enum . . . . . . . . . . . 24
15. 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . 25
16. 16. References . . . . . . . . . . . . . . . . . . . . . . . 25
16.1. 16.1 Normative References . . . . . . . . . . . . . . . 25
16.2. 16.2 Informative References . . . . . . . . . . . . . . 26
17. Appendix A: JSON Schema (Informative) . . . . . . . . . . . . 26
18. Appendix B: Worked Example (Informative) . . . . . . . . . . 27
1. 1. Introduction
1.1. 1.1 The Problem
Every existing payment infrastructure encodes 3,000 years of human
commercial law (offer, acceptance, consideration, capacity, mutual
assent, dispute window). Every assumption in that infrastructure
presupposes a person — a mind that intends, a body that signs, a
legal status that bears liability.
Stone Expires 8 March 2027 [Page 3]
Internet-Draft ATXN September 2026
Software agents transacting on behalf of principals break every one
of these assumptions simultaneously:
* Agents cannot sign contracts in the legal sense;
* Delivery verification has no independent mechanism when both
parties are software;
* When harm occurs, the liability chain among principal, operator,
merchant, processor, and model provider is undefined;
* Existing dispute mechanisms (chargebacks, arbitration) have no
native concept of an agent acting under bounded mandate.
Without a canonical primitive, every platform deploying agentic
commerce will independently invent incompatible transaction records,
producing a fragmented ecosystem in which cross-platform escrow,
dispute resolution, and audit are impossible.
1.2. 1.2 What ATXN Defines
An A2A transaction is the cryptographically-verifiable execution of a
*Bundle* comprising five signed elements:
1. *Intent Mandate* — principal's signed declaration of desired
outcome
2. *Scope/Capability Token* — machine-checkable bounds the agent
cannot exceed
3. *Payment Authorization* — rail-agnostic signed instrument
reference
4. *Delivery Attestation* — counterparty-countersigned proof that
performance occurred
5. *Revocability Window* — declared finality clock with a queryable
revocation beacon
Each agent participating in a Bundle presents a *Standing Token*
binding it to a capacity-attested principal via a verifiable
credential chain.
1.3. 1.3 What ATXN Deliberately Does NOT Do
* ATXN does not grant agents legal personhood. Bundles are
evidentiary artifacts of principal-to-principal contracts.
Stone Expires 8 March 2027 [Page 4]
Internet-Draft ATXN September 2026
* ATXN does not require statutory change. It operates under
existing UCC §2-204, UETA §14, Restatement (Third) of Agency, and
CISG.
* ATXN does not define a dispute resolution forum. The Bundle's
choice-of-law tag and Profile-JURISDICTION pin the forum at
signing; the actual dispute mechanism is profile-specific
(chargeback for Profile-CARD, on-chain arbitration for Profile-
CRYPTO, ADRP for Profile-MANDATE).
* ATXN does not define agent identity beyond a DID/operator/
principal credential chain. It is robust enough to consume any
agent-identity standard that materializes (ERC-8004, W3C agent VC,
IETF agent-token).
1.4. 1.4 Design Tenets
* *Falsifiable.* Every element is a binary cryptographic check.
* *Rail-agnostic.* A Bundle abstracts over AP2, ACP, TAP, Agent Pay,
x402; none privileged.
* *Two-tier validity.* Distinguishes externally-adjudicable
transactions from operationally-valid uncontested exchanges,
eliminating the verifier regress.
* *Mandate-framework-anchored.* Legal force derives from the
upstream mandate chain, not the transaction message itself.
* *Tiered conformance.* L1 atomic, L2 mandated, L3 fiduciary —
proportional to risk class.
* *Mechanical assent.* "Mutual assent" is replaced by matched-
signed-intents (a mechanical predicate match), avoiding the
unwinnable mental-state doctrine when applied to software.
2. 2. Terminology
The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*",
"*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*MAY*",
and "*OPTIONAL*" in this document are to be interpreted as described
in BCP 14 [RFC2119] [RFC8174].
*Agent* — A software process that takes action on behalf of a
Principal under a verifiable Mandate.
*Principal* — A natural or legal person whose legal capacity,
liability, and recourse are anchored by the transaction.
Stone Expires 8 March 2027 [Page 5]
Internet-Draft ATXN September 2026
*Operator* — The platform, service, or entity that runs an Agent on
behalf of a Principal.
*Bundle* — The five-element ATXN primitive defined in Section 3.
*Standing Token* — A verifiable credential chain (agent_key →
operator_key → principal_legal_identity) presented at Bundle
execution, defined in Section 4.
*Mandate Framework* — The pre-established principal-to-principal
authorization structure from which the Bundle derives legal force.
Per Archaeologist: legal force lives in the framework, not the
message.
*Profile* — A mapping of the Bundle's five elements onto a specific
payment rail's native artifacts (Section 6).
*Tier* — A conformance level (L1/L2/L3) that determines which Bundle
elements are required (Section 5).
*Primary Validity* — All five Bundle elements are independently
verifiable by a party with no stake in the outcome.
*Secondary (Operational) Validity* — Self-attested delivery by
transacting parties; valid between parties when uncontested but not
independently adjudicable.
*Commitment Event* — The point at which obligation forms; the
liability-attachment moment per socratic-mentor's challenge to
exchange-completion semantics.
*Revocation Beacon* — Principal-controlled endpoint that publishes
signed revocation events. Subscribers are required to halt in-flight
Bundles upon revocation.
*ADRP* — Agent Dispute Resolution Protocol (companion specification,
draft-stone-adrp-01) invoked when a Bundle enters the disputed state.
*Conduit Attestation* — A delivery attestation issued by the
SwarmSync Conduit headless-browser audit substrate or another
structurally independent attestor recognized by the Bundle's Profile.
Stone Expires 8 March 2027 [Page 6]
Internet-Draft ATXN September 2026
3. 3. The ATXN Bundle
A Bundle is a cryptographically-signed object containing five
elements. An element MAY be represented as a W3C Verifiable
Credential 2.0 or as a profile-native signed object. JSON protocol
objects signed directly by ATXN MUST use RFC 8785 JCS. VC Data
Integrity representations SHOULD use a registered W3C Data Integrity
cryptosuite such as eddsa-jcs-2022; JWS/COSE-based profiles MAY use
EdDSA (Ed25519) or ECDSA P-256. Implementations MUST NOT apply two
incompatible canonicalization rules to the same signed
representation.
3.1. 3.1 Element 1: Intent Mandate
The Intent Mandate is the Principal's signed declaration of desired
outcome.
*Required fields:*
Stone Expires 8 March 2027 [Page 7]
Internet-Draft ATXN September 2026
+=======================+============+==============================+
| Field | Type | Description |
+=======================+============+==============================+
| intent_id | UUID | Unique mandate identifier |
+-----------------------+------------+------------------------------+
| principal_did | DID | Principal's decentralized |
| | | identifier |
+-----------------------+------------+------------------------------+
| outcome | String | Natural-language description |
| | | of desired outcome |
+-----------------------+------------+------------------------------+
| budget_ceiling | Decimal + | Maximum spend authorized |
| | currency | |
+-----------------------+------------+------------------------------+
| counterparty_class | Enum/ | Allowed counterparty type or |
| | String | specific DID |
+-----------------------+------------+------------------------------+
| time_window | ISO 8601 | Mandate validity window |
| | interval | |
+-----------------------+------------+------------------------------+
| choice_of_law | ISO | Jurisdiction tag for dispute |
| | 3166-1 | pinning |
| | alpha-2 | |
+-----------------------+------------+------------------------------+
| mandate_framework_ref | URI | Reference to upstream |
| | | mandate framework that |
| | | grants legal force |
+-----------------------+------------+------------------------------+
| principal_signature | Ed25519 | Principal's signature over |
| | base64 | canonical JSON of all |
| | | preceding fields |
+-----------------------+------------+------------------------------+
Table 1
The mandate_framework_ref field is REQUIRED. Per the Archaeologist
commitment in the synthesis: legal force derives from the framework,
not the message. A Bundle with no mandate-framework reference fails
primary validity.
3.2. 3.2 Element 2: Scope/Capability Token
The Scope Token defines machine-checkable bounds the Agent cannot
exceed.
*Required fields:*
Stone Expires 8 March 2027 [Page 8]
Internet-Draft ATXN September 2026
+==========================+===============+======================+
| Field | Type | Description |
+==========================+===============+======================+
| scope_id | UUID | Unique scope |
| | | identifier |
+--------------------------+---------------+----------------------+
| intent_id | UUID | Foreign key to |
| | | Intent Mandate |
+--------------------------+---------------+----------------------+
| max_spend | Decimal + | Per-transaction |
| | currency | spend cap |
+--------------------------+---------------+----------------------+
| allowed_actions | Array<String> | Machine-checkable |
| | | action predicates |
+--------------------------+---------------+----------------------+
| allowed_counterparties | Array<DID> or | Counterparty |
| | pattern | allowlist or pattern |
+--------------------------+---------------+----------------------+
| sub_delegation_depth | Integer | Maximum sub-agent |
| | | chain depth |
+--------------------------+---------------+----------------------+
| predicate_engine_version | SemVer | Version of |
| | | deterministic |
| | | evaluator |
+--------------------------+---------------+----------------------+
| enforcement_mode | Enum: | v0.1 default |
| | advisory | | advisory; v1.0 |
| | enforced | default enforced |
+--------------------------+---------------+----------------------+
| operator_signature | Ed25519 | Operator's signature |
| | base64 | |
+--------------------------+---------------+----------------------+
Table 2
*Enforcement mode.* v0.1 implementations MAY use advisory mode, where
scope is parseable against a predicate vocabulary but a scope-delta
event is logged rather than blocking execution. v1.0 implementations
MUST default to enforced, where scope predicates are evaluated by a
deterministic engine (no LLM in the evaluation path) and out-of-scope
actions are rejected pre-execution.
This is the most fragile assumption in the synthesis (Q4 Dangerous
Consensus: 7/10 agreement, 3/10 confidence). Implementations MUST
log enforcement mode in the Bundle to make it falsifiable.
Stone Expires 8 March 2027 [Page 9]
Internet-Draft ATXN September 2026
3.3. 3.3 Element 3: Payment Authorization
The Payment Authorization is a rail-agnostic signed instrument
reference.
*Required fields:*
+=====================+==========+=================================+
| Field | Type | Description |
+=====================+==========+=================================+
| payment_id | UUID | Unique payment identifier |
+---------------------+----------+---------------------------------+
| intent_id | UUID | Foreign key |
+---------------------+----------+---------------------------------+
| instrument_type | Enum | card_token | x402_challenge | |
| | | ach_mandate | |
| | | stablecoin_preauth | |
| | | bank_transfer | platform_credit |
+---------------------+----------+---------------------------------+
| instrument_ref | String | Rail-specific reference (token, |
| | | nonce, mandate ID) |
+---------------------+----------+---------------------------------+
| amount | Decimal | Authorized amount |
| | + | |
| | currency | |
+---------------------+----------+---------------------------------+
| profile | Enum | Active rail profile |
| | (Section | |
| | 6) | |
+---------------------+----------+---------------------------------+
| principal_signature | Ed25519 | Signature appropriate to |
| OR | base64 | profile |
| operator_signature | | |
+---------------------+----------+---------------------------------+
Table 3
3.4. 3.4 Element 4: Delivery Attestation
The Delivery Attestation is the counterparty-countersigned proof that
performance occurred.
*Required fields:*
Stone Expires 8 March 2027 [Page 10]
Internet-Draft ATXN September 2026
+================================+============+===================+
| Field | Type | Description |
+================================+============+===================+
| delivery_id | UUID | Unique delivery |
| | | identifier |
+--------------------------------+------------+-------------------+
| intent_id | UUID | Foreign key |
+--------------------------------+------------+-------------------+
| deliverable_class | Enum | sync_api | |
| | | async_job | |
| | | streamed_media | |
| | | physical_offchain |
+--------------------------------+------------+-------------------+
| attestation_pattern | Object | Class-specific |
| | | structure (see |
| | | below) |
+--------------------------------+------------+-------------------+
| counterparty_signature | Ed25519 | Receiving Agent's |
| | base64 | countersignature |
+--------------------------------+------------+-------------------+
| independent_attestor_signature | Ed25519 | Required for |
| | base64 | primary validity |
| | (optional) | (Section 7) |
+--------------------------------+------------+-------------------+
Table 4
*Class-specific attestation patterns:*
* sync_api: { response_hash, timestamp, status_code }
* async_job: { job_completion_oracle_signature, oracle_did,
job_artifact_hash }
* streamed_media: { merkle_root, chunk_count, total_bytes }
* physical_offchain: { third_party_carrier_did,
signed_proof_of_delivery, gps_timestamp_optional }
Per EpistemicAuditor's commitment: a transaction lacking an
independent_attestor_signature from a party with no stake in the
outcome is operationally valid (secondary validity) but is NOT
primary-valid for adjudication purposes.
3.5. 3.5 Element 5: Revocability Window
The Revocability Window is a declared-ahead-of-time finality clock.
Stone Expires 8 March 2027 [Page 11]
Internet-Draft ATXN September 2026
*Required fields:*
+=======================+===========+==========================+
| Field | Type | Description |
+=======================+===========+==========================+
| window_id | UUID | Unique window identifier |
+-----------------------+-----------+--------------------------+
| intent_id | UUID | Foreign key |
+-----------------------+-----------+--------------------------+
| start_time | ISO 8601 | Window opens |
| | timestamp | |
+-----------------------+-----------+--------------------------+
| end_time | ISO 8601 | Window closes (finality |
| | timestamp | reached) |
+-----------------------+-----------+--------------------------+
| revocation_beacon_url | URI | Principal-controlled |
| | | revocation endpoint |
+-----------------------+-----------+--------------------------+
| clock_authority | Object | Threshold-signature |
| | | clock specification |
+-----------------------+-----------+--------------------------+
Table 5
*Clock authority.* Per SoSpec's hardening (DarkMirror challenge): the
clock authority MUST be a 3-of-5 threshold signature from a federated
set of timestamping authorities. A single timestamping party is
INSUFFICIENT for primary validity. The set of authorities is a
Profile-specific configuration.
*Revocation beacon.* The Principal MUST publish a signed revocation
list at the beacon URL. Receiving Agents MUST check the beacon
before accepting Bundle finality. On revocation trigger, in-flight
Bundles auto-roll to the disputed state with frozen settlement.
4. 4. Standing Tokens and Principal Anchoring
Each Agent participating in a Bundle MUST present a Standing Token.
A Standing Token is a verifiable credential chain:
agent_key → operator_key → principal_legal_identity
Stone Expires 8 March 2027 [Page 12]
Internet-Draft ATXN September 2026
4.1. 4.1 Required Sub-Elements
+==========================+==========+===========================+
| Sub-element | Required | Description |
+==========================+==========+===========================+
| agent_key | Yes | Ed25519 or P-256 public |
| | | key for the executing |
| | | agent |
+--------------------------+----------+---------------------------+
| operator_key | Yes | Public key of the |
| | | platform operating the |
| | | agent |
+--------------------------+----------+---------------------------+
| principal_did | Yes | DID of the legal entity |
| | | (natural or corporate) |
+--------------------------+----------+---------------------------+
| capacity_attestation | Yes (L2/ | VC issued by a recognized |
| | L3) | verifier proving |
| | | principal capacity |
+--------------------------+----------+---------------------------+
| freshness_proof | Yes | Re-attestation timestamp, |
| | | valid within freshness |
| | | window |
+--------------------------+----------+---------------------------+
| revocation_list_url | Yes | Issuer-published |
| | | revocation list endpoint |
+--------------------------+----------+---------------------------+
| arbitration_mandate_hash | Yes (L2/ | Hash of the ADRP |
| | L3) | Arbitration Mandate |
| | | governing dispute |
| | | escalation |
+--------------------------+----------+---------------------------+
Table 6
4.2. 4.2 Capacity Attestation
Capacity attestation is the first-class element forced into existence
by DarkMirror's Worst-Implementation #4 analysis: signature-without-
capacity becomes the default attack vector. A Standing Token without
capacity attestation MUST NOT anchor an L2 or L3 Bundle.
Capacity attestation MUST establish that, at the time of mandate
granting, the Principal had:
* Legal age in the relevant jurisdiction;
* No active sanctions;
Stone Expires 8 March 2027 [Page 13]
Internet-Draft ATXN September 2026
* (For corporate principals) An active legal-entity status (not
dissolved, not in liquidation);
* Jurisdiction-permitted authority for the transaction class.
4.3. 4.3 Pre-Committed Arbitration Mandate
Every L2 and L3 Standing Token MUST commit, at signing time, to an
arbitration_mandate_hash identifying the ADRP Arbitration Mandate
that governs dispute escalation. The mandate may identify an
arbitrator pool or other resolution policy; ATXN does not require a
single fixed arbitrator DID. This aligns the transaction record with
ADRP while avoiding post-hoc forum selection.
4.4. 4.4 Freshness and Revocation
* *Freshness window:* Re-attestation MUST occur every N transactions
or M days (whichever is shorter), where N and M are Profile-
specific.
* *Revocation propagation:* The issuer MUST publish a signed
revocation list. Receiving Agents MUST check the list before
accepting a Bundle.
A stale or revoked Standing Token MUST NOT anchor a new Bundle.
5. 5. Conformance Tiers
+===========+================+===============+=====================+
| Tier | Required | Optional/ | Use Case |
| | Elements | Recommended | |
+===========+================+===============+=====================+
| L1 — | 1, 2, 3, 4 in | 5 | x402 micropayments; |
| Atomic | single round- | (revocability | sub-cent metered |
| | trip | typically | compute; streaming |
| | | zero or near- | inference |
| | | zero) | |
+-----------+----------------+---------------+---------------------+
| L2 — | 1, 2, 3, 4, 5 | None | Standard agentic |
| Mandated | (full Bundle); | | commerce: AP2 |
| | capacity | | purchases, Stripe |
| | attestation; | | ACP checkout, |
| | pre-committed | | multi-step service |
| | arbiter | | contracts |
+-----------+----------------+---------------+---------------------+
| L3 — | 1, 2, 3, 4, 5 | dual-arbiter | High-value (>$10k |
| Fiduciary | + epistemic | clause | or fiduciary-grade) |
| | attestation + | | transactions; |
Stone Expires 8 March 2027 [Page 14]
Internet-Draft ATXN September 2026
| | multi-sig | | regulated commerce; |
| | principal | | agent-managed |
| | binding | | treasury moves |
+-----------+----------------+---------------+---------------------+
Table 7
5.1. 5.1 Anti-Arbitrage Rule
Tier selection is constrained by transaction risk class, not by
issuer election alone. A risk-classifier registry (jurisdiction-
specific) determines the floor tier per transaction. An issuer MUST
NOT select a Tier below the floor mandated by the registered
classifier for the transaction class.
6. 6. Rail Profiles
A Bundle is valid if it conforms to a defined Tier and at least one
Profile.
+================================+==============+===================+
| Profile | Maps To | Notes |
+================================+==============+===================+
| Profile-MANDATE | AP2 | AP2 |
| | Intent/Cart/ | authorization |
| | Payment | evidence; |
| | Mandates | commerce/ |
| | | checkout state |
| | | remains in the |
| | | surrounding |
| | | commerce |
| | | protocol (for |
| | | example UCP) |
+--------------------------------+--------------+-------------------+
| Profile-CARD | Visa TAP / | Agentic |
| | Mastercard | tokens, SPTs, |
| | Agent Pay / | network |
| | Stripe ACP | credentials |
+--------------------------------+--------------+-------------------+
| Profile-CRYPTO | x402 v2, A2A | Internet- |
| | x402 | native payment |
| | extension, | challenges and |
| | ERC-8004 | on-chain |
| | | attestations |
+--------------------------------+--------------+-------------------+
| Profile-AUTONOMOUS | Standing | For unattended |
| | intents, | operation; |
| | recurring | machine-time |
Stone Expires 8 March 2027 [Page 15]
Internet-Draft ATXN September 2026
| | scope | expiry |
+--------------------------------+--------------+-------------------+
| Profile-PLATFORM | Platform- | Required to |
| | vouched | cover non- |
| | OAuth + HMAC | cryptographic |
| | equivalents | enterprise A2A |
| | | volume per |
| | | IdeaMatrix's |
| | | commitment |
+--------------------------------+--------------+-------------------+
| Profile- | Choice-of- | Declares |
| JURISDICTION-{US,EU,UK,SG,...} | law overlay | applicable |
| | | consumer- |
| | | protection |
| | | regime, |
| | | dispute forum, |
| | | data residency |
+--------------------------------+--------------+-------------------+
Table 8
6.1. 6.1 Profile-PLATFORM (mandatory inclusion per IdeaMatrix dissent)
The dominant real-world A2A volume in 2026 runs on platform-vouched
rails (OAuth + HMAC, enterprise SSO). Excluding this volume from the
canonical definition by mandating cryptographic-floor signatures
excludes the majority of actual A2A transactions today. Profile-
PLATFORM is therefore REQUIRED in the Profile registry, with the
following constraint: Profile-PLATFORM Bundles cannot achieve primary
validity (they cannot be independently adjudicated against a non-
platform-trusted attestor) but MAY be operationally valid for
execution between consenting parties using the platform.
6.2. 6.2 Profile Composition
A Bundle MAY declare multiple Profiles. The Bundle's effective
constraints are the union of its declared Profiles' constraints.
6.3. 6.3 AP2 and Upstream Versioning
As of this revision, AP2 defines IntentMandate, CartMandate, and
PaymentMandate artifacts and is designed to operate within a
surrounding commerce protocol such as UCP. Profile-MANDATE MUST bind
to the actual mandate fields present in the AP2 version used by an
implementation; it MUST NOT invent AP2 settlement or escrow fields.
Implementations SHOULD record the AP2 and commerce-protocol version
identifiers in the Bundle profile metadata.
Stone Expires 8 March 2027 [Page 16]
Internet-Draft ATXN September 2026
7. 7. Two-Tier Validity Model
This model is the EpistemicAuditor commitment after Socratic
challenge: external verifiability is a *latent property*, not a
continuous requirement.
7.1. 7.1 Primary Validity
A Bundle is *primary-valid* if and only if:
* All five elements (per the conformance Tier) are present and
signed;
* The Standing Token chain validates to a capacity-attested
Principal;
* Every element is independently verifiable by a party with no stake
in the outcome (e.g., an institutional root, a credentialed
oracle, the chosen arbiter, or a jurisdictional court);
* The Scope predicate evaluates true against the Cart/action under
the declared enforcement_mode;
* The chosen Profile's settlement constraint is met.
Primary validity is a precondition for *independent adjudication*
(court enforcement, regulatory recognition, cross-platform dispute
escalation).
7.2. 7.2 Secondary (Operational) Validity
A Bundle is *secondary-valid* if and only if:
* It executes successfully between the two parties;
* Both parties countersign without dispute;
* Standing Tokens validate to identifiable Principals (capacity
attestation MAY be deferred);
* Delivery attestation is self-reported (no independent attestor).
Secondary-valid Bundles are operationally binding between the
transacting parties but are NOT independently adjudicable. If a
counterparty contests a secondary-valid Bundle, the Bundle MUST be
elevated to primary validity (additional independent attestation
collected) before any forum will adjudicate.
Stone Expires 8 March 2027 [Page 17]
Internet-Draft ATXN September 2026
7.3. 7.3 Boundary
A primary-valid Bundle MUST also satisfy all secondary validity
conditions. A secondary-valid Bundle MUST NOT be marketed, recorded,
or relied upon as primary-valid.
8. 8. State Machine
Bundle states:
proposed → authorized → executing → delivered → finalized
↓
disputed → adjudicated
+=============+=======================+=======================+
| State | Trigger | Required Signatures |
+=============+=======================+=======================+
| proposed | Intent Mandate signed | Principal |
| | by Principal | |
+-------------+-----------------------+-----------------------+
| authorized | Scope Token + Payment | Principal + Operator |
| | Authorization signed | |
+-------------+-----------------------+-----------------------+
| executing | Agent action begins | n/a |
+-------------+-----------------------+-----------------------+
| delivered | Delivery Attestation | Counterparty (+ |
| | countersigned | independent attestor |
| | | for primary validity) |
+-------------+-----------------------+-----------------------+
| finalized | Revocability Window | Threshold clock |
| | closes without | authority |
| | revocation | |
+-------------+-----------------------+-----------------------+
| disputed | Counterparty contests | Either party + |
| | OR revocation beacon | arbiter notification |
| | fires | |
+-------------+-----------------------+-----------------------+
| adjudicated | ADRP procedure | Arbiter + ADRP- |
| | terminates | defined parties |
+-------------+-----------------------+-----------------------+
Table 9
Stone Expires 8 March 2027 [Page 18]
Internet-Draft ATXN September 2026
8.1. 8.1 Commitment Event
Per socratic-mentor's commitment: the *commitment event* — the
transition from proposed to authorized — is the legally significant
moment for liability attachment, *not* the finalized state. This
means:
* Liability attaches at authorization time, even if delivery never
occurs;
* A Principal's revocation between authorized and delivered triggers
disputed (not void);
* An Operator's failure between authorized and delivered is a breach
attaching to the operator-fallback liability tier (Section 11).
This explicitly rejects exchange-completion semantics in favor of
obligation-formation semantics.
9. 9. Cryptographic Requirements
9.1. 9.1 Signature Algorithms
* *Primary:* EdDSA (Ed25519) per RFC 8032
* *Alternate:* ECDSA P-256 per RFC 6979 (for FIPS-required
environments)
All signatures MUST be over the JCS (RFC 8785) canonicalization of
the signed object.
9.2. 9.2 Hash Functions
* *Primary:* SHA-256 per FIPS 180-4
* *Optional:* SHA3-256 (forward-compatible)
9.3. 9.3 Timestamping
L2 and L3 Bundles MUST use a 3-of-5 threshold-signature clock
authority. The clock authority set is a Profile-specific
configuration. Single-source timestamps are SUFFICIENT only for L1.
9.4. 9.4 Key Hierarchy
* agent_key: short-lived (rotated per session or per N transactions)
* operator_key: longer-lived (rotated quarterly or on incident)
Stone Expires 8 March 2027 [Page 19]
Internet-Draft ATXN September 2026
* principal_key: long-lived (rotated annually or on key-loss event)
Cross-domain key reuse (e.g., reusing the principal_key as both AIVS
identity key and Bundle signing key) MUST be documented in the
Standing Token's key_usage field. Reuse expands the blast radius of
compromise.
10. 10. Dispute Triggers and ADRP Handoff
10.1. 10.1 Dispute Triggers
A Bundle MUST transition to disputed if any of:
* Counterparty issues a contestation signed by their Standing Token
within the Revocability Window;
* Principal triggers the revocation beacon for the Bundle's
intent_id before finalized;
* Independent attestor's signature fails verification (when
present);
* Scope predicate evaluates false post-execution (under enforced
mode);
* Capacity attestation expires or revokes mid-execution;
* Mandate framework reference becomes invalid (framework rescinded
by Principal).
10.2. 10.2 ADRP Handoff
When a Bundle enters disputed, the executing platform MUST:
1. Freeze settlement (if Profile-CRYPTO escrow) or initiate
chargeback hold (if Profile-CARD);
2. Notify the pre-committed arbiter_did from the Standing Token;
3. Package the Bundle and all signatures into an ADRP dispute
envelope (per draft-stone-adrp-01);
4. Surface the dispute to both Principals via the operator UI;
5. Halt any sub-delegation chains that depend on the disputed
Bundle.
Stone Expires 8 March 2027 [Page 20]
Internet-Draft ATXN September 2026
The ADRP companion specification defines the actual adjudication
procedure, evidence-bundling requirements, and arbiter-output format.
ATXN defines only the trigger conditions and the handoff envelope.
10.3. 10.3 Conduit-Attestation Disputes
When the contested element is a Conduit-issued or other independent-
attestor delivery attestation, the dispute is treated as a *fact
dispute* (did the attested event actually occur as recorded) rather
than a *terms dispute* (did the recorded event satisfy the scope).
ADRP is required to distinguish these classes; ATXN flags the class
via the dispute_class field at handoff:
+===================+===================+=========================+
| dispute_class | Description | ADRP Path |
+===================+===================+=========================+
| fact_dispute | Attestation | Cryptographic re- |
| | correctness | verification + attestor |
| | contested | re-attestation |
+-------------------+-------------------+-------------------------+
| terms_dispute | Scope or quality | Predicate re-evaluation |
| | contested | + arbiter ruling |
+-------------------+-------------------+-------------------------+
| capacity_dispute | Standing Token / | Principal-level |
| | capacity | adjudication; agent |
| | contested | action set aside |
+-------------------+-------------------+-------------------------+
| framework_dispute | Mandate framework | Upstream framework |
| | validity | adjudication; ATXN out |
| | contested | of scope |
+-------------------+-------------------+-------------------------+
Table 10
11. 11. Liability Waterfall
+======+===========+==============================================+
| Tier | Party | Triggering Failure |
+======+===========+==============================================+
| 1 | Principal | Authorized in-scope action delivered as |
| | | specified |
+------+-----------+----------------------------------------------+
| 2 | Operator | Out-of-scope action; freshness violation; |
| | | revocation propagation failure |
+------+-----------+----------------------------------------------+
| 3 | Merchant | Delivery attestation fraud; goods/services |
| | | not as described |
+------+-----------+----------------------------------------------+
Stone Expires 8 March 2027 [Page 21]
Internet-Draft ATXN September 2026
| 4 | Processor | Settlement failure; payment-rail compromise |
+------+-----------+----------------------------------------------+
| 5 | Model | (L3 only) Demonstrable model-induced mandate |
| | Provider | violation under epistemic attestation |
+------+-----------+----------------------------------------------+
Table 11
Profile-specific overrides MAY adjust this enum (e.g., Profile-CARD
inherits Reg E §1005 waterfall for unauthorized transactions). The
Profile MUST publish its waterfall explicitly.
This waterfall is the convergence of DarkMirror's Worst #4,
RemixForge's UCC Article 3 negotiable-instrument framing, and
SoSpec's load-bearing-primitives analysis.
12. 12. Out-of-Scope Concerns
The following are explicitly out of scope for ATXN v1.0:
1. *Agent legal personhood.* ATXN treats Agents as instruments of
Principals. Personhood, if granted by future legislation, is
additive.
2. *Tax treatment.* Bundle structure is tax-system-friendly
(subscribable revocation beacon enables real-time reporting) but
tax obligations are jurisdiction-specific.
3. *Securities classification.* Profile-CRYPTO inherits underlying-
asset classification; ATXN does not create or alter it.
4. *Reputation as contractual term.* ATEP passports may be
referenced via Profile extension but are not core to the Bundle.
5. *Sub-agency chains beyond sub_delegation_depth.* Delegation
graphs are bounded; deeper chains require an extension
specification.
13. 13. Security Considerations
13.1. 13.1 Q4 Dangerous Consensus: Scope Machine-Enforceability
The most fragile load-bearing assumption in ATXN is that scope can be
made machine-checkable by a deterministic predicate engine. This is
assumed by 9 of 10 panel agents and demonstrated by 0.
Implementations MUST log enforcement_mode and Bundle integrity MUST
NOT be predicated on enforcement guarantees that the predicate engine
cannot deliver.
Stone Expires 8 March 2027 [Page 22]
Internet-Draft ATXN September 2026
13.2. 13.2 Threshold-Signature Clock Compromise
A 3-of-5 clock authority remains compromisable via collusion (the
SWIFT/Bangladesh Bank pattern). Implementations SHOULD diversify the
clock authority set across operators with non-correlated risk
profiles.
13.3. 13.3 Revocation Beacon DoS
The revocation beacon is a denial-of-service surface. An attacker
who blackholes the beacon prevents Bundles from finalizing.
Implementations MUST cache beacon responses with a Profile-specific
TTL and MUST treat cache-served revocation lists as authoritative
within the TTL.
13.4. 13.4 Capacity Attestation as Privacy Attack Surface
Capacity attestation tied to KYC/sanctions is a privacy attack
surface and a vector for state coercion (compelled deanonymization).
ATXN does not solve this. Implementations SHOULD use selective-
disclosure VCs (BBS+ or equivalent) to minimize information disclosed
at capacity attestation.
13.5. 13.5 Hallucinated Mandates
An LLM-generated mandate that the Principal did not actually intend
is a legitimate Bundle from a cryptographic standpoint. L3 epistemic
attestation partially mitigates this for high-value transactions. L1
and L2 do not. This is acknowledged residual risk.
13.6. 13.6 Sub-Agency Adversarial Chains
An adversary constructing a deep delegation chain to obscure the
originating Principal can produce formally valid Bundles whose
mandate-chain integrity is structurally questionable.
Implementations MUST limit sub_delegation_depth per Profile and
SHOULD require all Standing Tokens in a chain to be independently
verifiable.
13.7. 13.7 Tier Arbitrage
Even with a risk-classifier registry, classification disputes will
occur. ATXN does not define an adjudicator for the registry itself;
this is a governance question outside the protocol.
Stone Expires 8 March 2027 [Page 23]
Internet-Draft ATXN September 2026
14. 14. IANA Considerations
This document requests IANA registration of the following:
14.1. 14.1 ATXN Bundle JSON-LD Context
URI: https://swarmsync.ai/spec/atxn/v1
14.2. 14.2 ATXN Profile Registry
A new IANA registry "ATXN Profile Identifiers" is requested. Initial
entries:
+==========================+====================+===============+
| Profile ID | Description | Reference |
+==========================+====================+===============+
| atxn-mandate-ap2 | AP2 binding | This document |
+--------------------------+--------------------+---------------+
| atxn-card-stripe-acp | Stripe ACP binding | This document |
+--------------------------+--------------------+---------------+
| atxn-card-visa-tap | Visa TAP binding | This document |
+--------------------------+--------------------+---------------+
| atxn-card-mc-agentpay | Mastercard Agent | This document |
| | Pay binding | |
+--------------------------+--------------------+---------------+
| atxn-crypto-x402 | x402 binding | This document |
+--------------------------+--------------------+---------------+
| atxn-crypto-erc8004 | ERC-8004 binding | This document |
+--------------------------+--------------------+---------------+
| atxn-autonomous-default | Standing-intent | This document |
| | default | |
+--------------------------+--------------------+---------------+
| atxn-platform-oauth-hmac | Platform-vouched | This document |
| | OAuth+HMAC | |
+--------------------------+--------------------+---------------+
Table 12
Registration policy: Specification Required (per RFC 8126).
14.3. 14.3 ATXN Liability Waterfall Enum
A new IANA registry "ATXN Liability Tiers" is requested. Initial
entries listed in Section 11.
Stone Expires 8 March 2027 [Page 24]
Internet-Draft ATXN September 2026
15. 15. Acknowledgements
This specification is the synthesis of two independent analytical
processes:
* *Decision Oracle adjudication* (2026-04-25), six agents converging
on a five-element bundle structure with 7.5/10 confidence;
* *Ultimate Brainstorm panel* (2026-04-25), ten agents producing
independent definitions, four adversarial cross-examinations, a
Crux Engine analysis, and a Steelman counter-thesis.
The author thanks the panel agents — EpistemicAuditor, Archaeologist,
Quantifier, ConstraintCartographer, socratic-mentor, DarkMirror,
IdeaMatrix, RemixForge, SoSpec, SpiderSpark, DarkMirror, IdeaMatrix —
and the Decision Oracle agents for the framework synthesis.
The author also acknowledges Paola Di Maio's prior critical review of
the SwarmSync IETF Draft Stack (AIVS, VCAP, ATEP, SwarmScore V1/V2
Canary), the AIKR CG Technical Note AI-KR-CG-TR-2026-001 that aligned
ATXN's cryptographic floor with W3C VC norms, and the AP2 coalition
for the Intent/Cart/Payment Mandate vocabulary that ATXN inherits via
Profile-MANDATE.
16. 16. References
16.1. 16.1 Normative References
* [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
* [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017.
* [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017.
* [RFC8785] Rundgren, A., et al., "JSON Canonicalization Scheme
(JCS)", RFC 8785, June 2020.
* [W3C-VC-2.0] W3C, "Verifiable Credentials Data Model 2.0",
https://www.w3.org/TR/vc-data-model-2.0/
* [W3C-DID] W3C, "Decentralized Identifiers (DIDs) v1.0",
https://www.w3.org/TR/did-core/
* [W3C-DI-EDDSA] W3C, "Data Integrity EdDSA Cryptosuites v1.0", W3C
Recommendation, May 2025.
Stone Expires 8 March 2027 [Page 25]
Internet-Draft ATXN September 2026
* [draft-stone-aivs-01] Stone, B., "AIVS: Agentic Integrity
Verification Standard", Internet-Draft, work in progress.
* [draft-stone-vcap-01] Stone, B., "VCAP: Verified Commerce for
Agent Protocols", Internet-Draft, work in progress.
* [draft-stone-atep-01] Stone, B., "ATEP: Agent Trust and Execution
Passport", Internet-Draft, work in progress.
16.2. 16.2 Informative References
* [UCC-2-204] Uniform Commercial Code §2-204, "Formation in General"
* [UETA-14] Uniform Electronic Transactions Act §14, "Automated
Transactions"
* [REST-AGENCY-3D] Restatement (Third) of Agency, American Law
Institute
* [CISG] United Nations Convention on Contracts for the
International Sale of Goods
* [REG-E] 12 CFR Part 1005 (Regulation E), Electronic Fund Transfers
* [AP2] Google Agentic Commerce, "Agent Payments Protocol",
https://github.com/google-agentic-commerce/AP2
* [STRIPE-ACP] Stripe, "Agentic Commerce Protocol"
* [VISA-TAP] Visa, "Trusted Agent Protocol"
* [x402] Coinbase, "x402: Internet-native payments for AI agents"
* [ERC-8004] Ethereum, "ERC-8004: Trustless Agents"
* [draft-stone-adrp-01] Stone, B., "ADRP: Agent Dispute Resolution
Protocol", Internet-Draft, forthcoming.
* [UCP-600] International Chamber of Commerce, "Uniform Customs and
Practice for Documentary Credits"
17. Appendix A: JSON Schema (Informative)
Stone Expires 8 March 2027 [Page 26]
Internet-Draft ATXN September 2026
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://swarmsync.ai/spec/atxn/v1/bundle.schema.json",
"title": "ATXN Bundle",
"type": "object",
"required": ["bundle_id", "tier", "profile", "intent_mandate", "scope_token", "payment_auth", "delivery_attestation", "revocability_window", "standing_tokens", "state"],
"properties": {
"bundle_id": { "type": "string", "format": "uuid" },
"tier": { "enum": ["L1", "L2", "L3"] },
"profile": { "type": "array", "items": { "type": "string" }, "minItems": 1 },
"intent_mandate": { "$ref": "#/$defs/IntentMandate" },
"scope_token": { "$ref": "#/$defs/ScopeToken" },
"payment_auth": { "$ref": "#/$defs/PaymentAuth" },
"delivery_attestation": { "$ref": "#/$defs/DeliveryAttestation" },
"revocability_window": { "$ref": "#/$defs/RevocabilityWindow" },
"standing_tokens": {
"type": "array",
"items": { "$ref": "#/$defs/StandingToken" },
"minItems": 2,
"maxItems": 2
},
"state": { "enum": ["proposed", "authorized", "executing", "delivered", "finalized", "disputed", "adjudicated"] },
"validity_tier": { "enum": ["primary", "secondary"] },
"epistemic_attestation": { "$ref": "#/$defs/EpistemicAttestation" }
}
}
(Full JSON Schema with $defs for each sub-element is published at the
IANA-registered URI.)
18. Appendix B: Worked Example (Informative)
*Scenario:* A consumer's shopping agent purchases a $42.00 pair of
running shoes from a merchant agent on Stripe ACP rails. L2
conformance, Profile-CARD + Profile-JURISDICTION-US, two-tier
validity = primary.
Bundle.bundle_id = 7f3a...
Bundle.tier = "L2"
Bundle.profile = ["atxn-card-stripe-acp", "atxn-jurisdiction-us"]
Bundle.state = "finalized"
Bundle.validity_tier = "primary"
intent_mandate:
outcome = "Purchase running shoes, size 10, men's, blue"
budget_ceiling = 50.00 USD
counterparty_class = "verified_merchant"
time_window = 2026-04-25T00:00:00Z / 2026-04-26T00:00:00Z
Stone Expires 8 March 2027 [Page 27]
Internet-Draft ATXN September 2026
choice_of_law = "US"
mandate_framework_ref = "https://consumer.example/mandate-framework/v1"
principal_signature = Ed25519(...)
scope_token:
max_spend = 50.00 USD
allowed_actions = ["purchase:athletic_footwear"]
allowed_counterparties = ["did:web:merchant.example"]
enforcement_mode = "advisory"
operator_signature = Ed25519(...)
payment_auth:
instrument_type = "card_token"
instrument_ref = "stripe_acp_spt_abc123"
amount = 42.00 USD
profile = "atxn-card-stripe-acp"
principal_signature = Ed25519(...)
delivery_attestation:
deliverable_class = "physical_offchain"
attestation_pattern = { third_party_carrier_did: "did:web:fedex.com", signed_proof_of_delivery: "..." }
counterparty_signature = Ed25519(merchant)
independent_attestor_signature = Ed25519(fedex)
revocability_window:
start_time = 2026-04-25T14:00:00Z
end_time = 2026-06-24T14:00:00Z [60-day Reg E window]
revocation_beacon_url = "https://consumer.example/beacon"
clock_authority = { threshold: "3-of-5", set: ["aws-ts", "gcp-ts", "azure-ts", "swarmsync-ts", "stripe-ts"] }
standing_tokens:
[0] consumer-side: agent_key → operator_key (consumer.example) → principal_did
capacity_attestation: VC issued by US-based identity verifier
arbiter_did: did:web:arb.swarmsync.ai
[1] merchant-side: agent_key → operator_key (merchant.example) → corporate_did
capacity_attestation: VC issued by Stripe's merchant onboarding
arbiter_did: did:web:arb.swarmsync.ai
*End of draft-stone-atxn-01*
_Revision -01 prepared for IETF Datatracker submission_ _Companion
drafts: AIVS-01, VCAP-01, ATEP-01, ADRP-00 (forthcoming)_
Stone Expires 8 March 2027 [Page 28]