ACK-Pay Agent Settlement
Agent identity verification before any payment fires. KYA-first architecture from Catena Labs — ACK-ID attestation, ACK Rulebook capability envelopes, ACKReceipt audit trail. Settles USDC on Base.
CTR (USD 10,000+)TRAVEL-RULE (USD 3,000+)ENHANCED-DUE-DILIGENCE (USD 50,000+)
Step 1 · Agent Wallet + ACK-ID AttestationPolicy-EnforcedBlockchain-Native
A machine principal's authenticated session — identity is a cryptographic credential bound to the operator, not a human login. The equivalent of a trader's authenticated authorization in a bilateral institutional payment.
The agent holds a wallet on Base with a Catena Labs ACK-ID attestation — a W3C Verifiable Credential linking the agent's DID (typically did:web:catena.inc with an `ACKIdentityService` endpoint, or did:pkh for self-issued agents) to its operating principal. L4 Account and L5 Application are lit, both above the enforcement line, policy-enforced. The ACK-ID credential carries the five fields Sean Neville foregrounds in the a16z framing: principal (who the agent represents), permissions (what the agent may do), constraints (per-transaction and temporal bounds), liability (which entity's BSA program attaches), and reputation (prior compliance behavior). Builder: resolve the agent's DID via the ACK-ID resolver SDK; the credential is retrieved, signature-verified against the issuer's public key, and the principal graph is cached for downstream delegation checks. Compliance officer: KYA checkpoint KYA-1 (Resolve Principal) fires here — before any ACK-Pay session opens, the agent's principal must be identifiable, attestable, and revocation-checked. GENIUS §6 AML/BSA obligations attach to the resolved principal; the agent operating under that principal inherits the principal's BSA program and customer identification program coverage. Honesty marker: ACK-ID is an emerging standard — as of April 2026, production deployments are limited to Catena Labs' own pilot partners, and the revocation-list infrastructure is centralized at catena.inc. A decentralized revocation registry is on Catena's roadmap but not yet live.
Step 2 · ACK-Pay Session + Counterparty ResolutionCode-EnforcedBlockchain-Native
The trade-counterparty onboarding check in a bilateral institutional payment — both sides prove identity, and both are screened before any obligation is booked.
The agent initiates an ACK-Pay session against the counterparty's endpoint. The counterparty's ACK-ID is resolved and the two DID documents are cross-verified — both parties must present valid, non-revoked credentials. OFAC sanctions screening fires against both wallet addresses via the Chainalysis oracle at 0x40C5...8fb on Base. If the transfer exceeds $3,000 (US) or €1,000 (EU), Travel Rule data is packaged in IVMS101 format alongside the ACK-ID attestations — the ACK framework treats Travel Rule as a first-class payload field, not an out-of-band message. L3 Execution and L4 Account lit: the counterparty resolution and sanctions gate are code-enforced at the Base consensus boundary; the session negotiation itself happens at the account layer. Builder: `ackPay.openSession({ counterpartyDid, amount })` returns a `SessionContext` with both attestations, the OFAC check result, and (if applicable) the IVMS101 bundle; the SDK halts the session if any gate fails and surfaces a structured error naming the failing check. Compliance officer: satisfies GENIUS §6 (AML/BSA attribution via dual ACK-ID resolution), §7 (Travel Rule for qualifying amounts), and §8 (foreign-issuer screening if the counterparty agent operates from a non-US jurisdiction — ACK-ID jurisdiction metadata drives this check). Honesty marker: ACK-Pay production deployments are pre-launch as of April 2026; Catena's early partners are piloting the session flow, but no mass-market ACK-Pay endpoints exist yet. Reliance on the session's Travel Rule packaging requires the receiving VASP to also run an ACK-Pay-compatible IVMS101 parser — sunrise issue remains.
Step 3 · Delegation + Capability Envelope (ACK Rulebook)Code-EnforcedBlockchain-Native
The corporate authorization matrix check plus the card-scheme MCC allow-list — may this agent commit this principal's funds, for this category, at this amount, right now?
Before settlement fires, the ACK Rulebook evaluates the agent's delegation chain against its capability envelope — this is where Neville's 'permissions' and 'constraints' become code-enforced policy. The Rulebook is an on-chain (or verifiable off-chain) policy object encoding per-transaction limits, daily caps, permitted merchant categories (as MCCs or ACK category hashes), temporal bounds, and delegation-depth limits (how many hops the agent sits below the root principal). The delegation chain itself is walked from the agent upward — each hop must have a valid ACK-ID attestation, unexpired delegation, and non-attenuated scope relative to the parent (a child delegation cannot expand a parent's constraints). L3 Execution and L4 Account lit: the Rulebook evaluator runs at the execution layer, and the delegation graph is cached in the agent's account state. Builder: `rulebook.evaluate({ agent, target, amount, category, timestamp })` returns `{ allowed: bool, violations: string[] }` — the ACK-Pay session halts with a structured error naming each violated constraint. Compliance officer: this is the code-enforced KYA-2 (Verify Delegation) and KYA-3 (Evaluate Capability Envelope) checkpoint pair, rendered together because the Rulebook evaluates them as a single atomic policy decision. GENIUS §6 attribution depends on the Rulebook evaluation passing — a payment outside the envelope cannot be cleanly attributed to the principal's BSA program. C5 Licensing attaches where the agent operates on behalf of a licensed entity; the Rulebook encodes the licensee's permitted product scope and geographic restrictions. C16 Programmable Compliance is entirely satisfied here — the Rulebook is the canonical artifact of machine-enforced policy in the ACK architecture.
Step 4 · ACK-Pay Settlement (USDC on Base)Code-EnforcedBlockchain-Native
The execution leg of a correspondent-bank payment — terms agreed, screening passed, now value moves atomically with the negotiated conditions encoded in the settlement instruction.
The agent signs an ACK-Pay Verifiable Payment instruction — a typed-data object containing the session ID, counterparty ACK-ID, amount, asset (USDC), and a hash of the Step 3 Rulebook evaluation. The settlement contract on Base verifies the signature, checks that the Rulebook evaluation hash matches the current Rulebook state (to prevent replay against a stale Rulebook), and executes the USDC transfer via EIP-3009 `transferWithAuthorization`. L1 Network, L2 Consensus, and L3 Execution all lit: the full stack below the enforcement line processes the transfer in a single Base block (~2s). Builder: `ackPay.settle(sessionId, signedInstruction)` relays the instruction to the ACK-Pay settlement contract; the contract emits `PaymentSettled(sessionId, agent, counterparty, amount, rulebookHash)`, which downstream audit tooling indexes. Compliance officer: GENIUS §4 reserve-backing obligations apply to the USDC in transit — Circle must maintain 1:1 reserves in USD or short-term Treasuries. Recordkeeping (C11) anchors to the block transaction hash, which is cryptographically linked back to Step 3's Rulebook evaluation and Step 2's ACK-ID session context. The Verifiable Payment model produces a cleaner audit trail than raw ERC-20 transfers because every settlement carries its compliance context as on-chain calldata — an examiner can reconstruct the full decision tree from a single block transaction.
Step 5 · ACK Receipt + Credential HealthPolicy-EnforcedBlockchain-Native
The signed bilateral confirmation in a correspondent-bank payment — both sides acknowledge settlement and the compliance record crystallizes into the transaction's permanent account history.
The ACK-Pay session closes with a bilateral signed receipt: a W3C Verifiable Credential of type `ACKReceipt` binding the agent's DID, the counterparty's DID, the settled amount, the Base transaction hash, and the Step 3 Rulebook evaluation hash. Both parties sign the receipt — it is independently verifiable by any third party without access to Catena Labs infrastructure. The agent's credential health score (KYA-5) updates: a successful, in-envelope settlement increments the agent's reputation, while any mid-session fault (failed Rulebook eval, OFAC hit, stale delegation, counterparty dispute) decrements it. L4 Account and L5 Application lit on both sides: receipt issuance is off-chain, policy-enforced by the ACK-Pay session-close handshake, but the cryptographic binding to the on-chain transfer is intact. Builder: the receipt is returned in the session-close callback; persist the VC alongside the transaction hash in durable storage for audit, and feed credential-health deltas back to the ACK-ID issuer for reputation rollup. Compliance officer: satisfies C11 (recordkeeping under GENIUS §6 and §4(c)), C12 (independent audit trail for monthly attestation under §4(b)), and contributes to the agent's credential health feed (KYA-5) for future reputation-based gating. The receipt is the artifact that rolls up into the principal's monthly reserve attestation. Honesty marker: credential health is a Catena Labs concept — not yet a cross-vendor standard. Agents operating across multiple ACK-Pay issuers will carry separate reputation scores until a federation model ships.
Resolved 5 steps across 1 chain(s). 3 threshold(s) triggered. Frameworks: Bank Secrecy Act, GENIUS Act, OFAC Sanctions Program, FATF Recommendation 16 (Travel Rule), Common Reporting Standard / FATCA.
ACK-ID DID Resolver
Step 1 KYA-1 primitive: resolve did:web:catena.inc with its ACKIdentityService and ACKPaymentService endpoints alongside did:pkh, did:key, did:ion, did:hedera, and did:ethr — benchmarking the ACK-ID identity substrate.
ACK-ID Delegation Explorer
Step 3 KYA-2 tool: interactive tree navigator for multi-level Catena Labs ACK-ID delegation chains with permission attenuation — trace the principal → agent trust path that GENIUS §6 requires for BSA attribution.
ACK Rulebook Capability Simulator
Step 3 KYA-3 tool: evaluate an ACK Rulebook against a proposed payment — per-transaction limits, daily caps, permitted MCCs, temporal bounds, and delegation depth. The canonical C16 Programmable Compliance artifact.
ACK Compliance Pipeline
End-to-end KYA-4 compliance pipeline with preset agent DIDs, real-time audit record generation, and verifiable credential export — rolling up the ACK-ID, Rulebook, and OFAC decisions into a single examinable trail.
ACKReceipt Verifier
Step 5 verification of the `ACKReceipt` VC issued at session close: signature check, issuer validation, revocation check, claims evaluation. Independently verifiable without access to Catena Labs infrastructure.
Sample ACK Receipt (VC Format)
{"@context": ["https://www.w3.org/2018/credentials/v1"],"type": ["VerifiableCredential","ACKReceipt"],"issuer": "did:web:receipts.acme-psp.com","issuanceDate": "2026-04-01T14:32:18Z","credentialSubject": {"payer": "did:web:agent.acme-corp.com","payee": "did:web:vendor.eu-payments.fr","amount": "3500.00","currency": "USDC","settlementNetwork": "Base","requestToken": "req_7f3a8b2c"},"proof": {"type": "Ed25519Signature2020","verificationMethod": "did:web:receipts.acme-psp.com#key-1","signatureValue": "eyJhbGciOiJFZERTQSIsImtpZCI6ImRpZDp3ZWI6cmVjZWlwdHMuYWNtZS1wc3AuY29tI2tleS0xIn0"}};