Most payment systems today assume a human in the loop. But what happens when agents—not users—initiate and authorize value transfer?

That’s the world Catena Labs’ Agent Commerce Kit (ACK) is preparing us for, and I’ve been experimenting with it firsthand.

ACK is a fully open-source identity and payments protocol designed for machine-native finance, where agents act independently, verifiably, and securely.

I became one of the first engineers to build with ACK, completely entranced by the wild west of agentic commerce:

• Designing a multi-rail payment orchestration service for agents

• Prototyping a Swift SDK for mobile agent identity

• Stress-testing the ACK primitives for high-throughput agentic usage

• Designing an SDK wrapper enabling developers to leverage ACK in their preferred language

This teardown shares what I’ve learned, what’s promising, and where builders should be looking next.

ACK at a glance

• ACK-ID gives agents a verifiable, scoped identity — cryptographically tied to a legal entity and delegable to others.

• ACK-Pay defines a standard for agent-initiated payments across any rail, including receipt verification, human-in-the-loop (HITL) triggers, and auditability.

• The stack is open-source, well-architected, and shockingly almost-ready for real usage. (I was working on building the multi-payment rail infrastructure, but more on that later)

What Is Agent Commerce Kit (ACK)?

ACK is the first open protocol that makes it possible for autonomous agents to act as economic actors securely, transparently, and independently.

It’s built on two core components:

🔐 ACK-ID

ACK-ID provides a decentralized, cryptographically verifiable identity system that allows:

• Agents to identify themselves using W3C-compliant DIDs

• Delegation of authority, where one agent can authorize another within tightly scoped permissions

• Lifecycle controls, including expiration, revocation, and key rotation

• Trust graphs, where agents and entities form nested, revocable relationships

Use cases:

• A parent agent delegates task authority to a sub-agent

• An LLM is issued a short-lived credential to access a third-party service

• An autonomous agent verifies that it was authorized to act on behalf of a manager

💸 ACK-Pay

ACK-Pay defines a multi-phase payment protocol optimized for machine-to-machine (M2M) commerce:

• Agents initiate signed PaymentRequests

• Payment services route and execute those requests across any payment rail (stablecoin, fiat, RTP, etc.)

• Verifiable receipts are generated and signed as part of every successful transaction

• Human-in-the-loop (HITL) fallbacks allow policy-based intervention for risk or compliance

ACK-Pay is rail-agnostic and designed for interoperability, so you don’t need to choose between onchain or offchain: ACK supports both.

Use cases:

• A SaaS bot renews a subscription by triggering an onchain stablecoin transfer

• A settlement agent aggregates 50 micro-payments from worker bots and pays out in bulk

• A platform routes payment decisions to a human approver if trust thresholds are exceeded

The real strength of ACK is how ACK-ID and ACK-Pay work together.

ACK-ID ensures every actor in a transaction has a verifiable, scoped identity.

ACK-Pay ensures every transaction between those actors is auditable, trustworthy, and cryptographically signed.

Together, they form a complete system for agent-native commerce.

What struck me early was how cohesive and extensible the protocol is. ACK doesn’t feel like a toy. It feels like Stripe, OAuth, and Verifiable Credentials had a protocol-native child, built for autonomous software, not just APIs.

I’ll break each piece down and show how one could build on top of it.

ACK-ID: Verifiable, Scoped Identity for Autonomous Agents

Most identity systems, even modern ones, are designed with a single user in mind. A wallet. An account. A session.

ACK-ID flips that on its head. It treats identity as a flexible, cryptographically verifiable chain of delegation, built for agents that represent other agents, not just end users.

At its core, ACK-ID answers this question:

🧠 The Core Pattern: Identity as Delegated Authority

ACK-ID uses W3C DIDs and Verifiable Credentials to create a model of scoped trust:

• An agent is issued a verifiable identifier

• Another agent (or legal entity) can delegate trust to it, cryptographically

• Every identity has a lifecycle: it can be created, expired, rotated, or revoked

This gives builders a flexible foundation for:

• Multi-level delegation (e.g. “agent A can speak for org X, but only for invoice generation”)

• Task-level agents spun up on the fly, with scoped permissions

• A cryptographic paper trail for every actor in the system

🧪 My Experiment: Modeling Agent Delegation with agentid-core

In one of my earliest explorations of the ACK protocol, I built agentid-core — a Go + Solidity toolkit for experimenting with secure, scoped delegation between autonomous agents.

At the time, I didn’t know an official TypeScript SDK existed. So this project became my way of reasoning through the ACK-ID spec from first principles, and making it usable across both offchain and onchain environments.

What the experiment does:

• 🔐 Generates root agent identities with secp256k1 keypairs (ACK-compatible)

• ✍️ Signs identity claims using EIP-712 for structured, human-readable attestations

• 🧾 Delegates scoped authority to sub-agents (e.g. payment bots, routers, verifiers)

• 🔍 Verifies trust chains and enforces them in Solidity via an onchain verifier

What I loved:

• The delegation model feels like OAuth scopes with cryptographic guarantees

• ACK’s trust flows map cleanly into code, especially revocation and expiration

• The Go + Solidity split made it easy to reason across both cloud-native and smart contract environments

What I’m still exploring:

• How to issue credentials programmatically — right now it's CLI-heavy

• What recovery looks like if a delegated key is lost or compromised

• How to model trust boundaries across multi-org agent graphs

💡 Builder Insight

This kind of structure isn’t just useful for agents. It’s useful anywhere you want to model and enforce trust between entities with different scopes:

• Logistics: broker agent → carrier → dispatcher

• Payments: treasury → vendor agent → pay-on-behalf

• Developer platforms: API integrator → sub-agent with limited scope

In traditional systems, you’d do this with hardcoded ACLs or bearer tokens. In ACK, you do it with credentials and cryptographic proofs.

ACK-Pay: Payment Flows That Operate at Machine Speed

Once your agents have identity and trust, the next question becomes:

ACK-Pay is the answer: a protocol for agent-initiated payments with cryptographic verification, human-in-the-loop (HITL) fallbacks, and stablecoin-first rails.

It’s the most “agent-native” payment system I’ve seen.

⚙️ The Core Model

Every ACK-Pay transaction follows a standard structure:

1. Initiate – An agent creates a signed PaymentRequest, scoped to a recipient and purpose.

2. Execute – A payment service (agent-operated or third-party) routes and processes the transfer.

3. Verify – A verifiable PaymentReceipt is generated — signed, timestamped, and referenceable.

4. Fallback – Optional: HITL (human-in-the-loop) intervention hooks for risk or compliance events.

In theory, this works across any payment rail because ACK is rail-agnostic by design. And at the time ACK was released, this had not yet been implemented, so I took a shot at it.

🧪 My Experiment: Multi-Rail Agentic Payment Orchestration

Once I had agentid-core working, I started experimenting with how autonomous agents could initiate and complete payments across multiple rails.

At the time, ACK-Pay didn’t yet have an official implementation, so I designed one from scratch in TypeScript — aiming to stay faithful to the spec while building something extensible.

I split the system into two repos:

• payment-service-core — the orchestration engine that handles routing, execution, and verification

• payment-service-api — the agent-facing HTTP layer for submitting signed requests and retrieving receipts

This service supports the full ACK-Pay flow:

• Accepts a signed PaymentRequest

• Verifies ACK-ID identity and delegated permission scope

• Routes to the appropriate payment rail (mocked for now, plugin-ready)

• Returns a signed PaymentReceipt — cryptographically verifiable and spec-compliant

The result: every payment initiated by an agent is auditable, trust-scoped, and verifiable, regardless of the underlying rail.

From there, the architecture naturally split into two clean components:

Separation of Concerns

• payment-service-core handles execution logic, routing, and receipt generation

• payment-service-api is a clean, agent-facing interface with signature validation baked in

Receipts as First-Class Outputs

Instead of just returning 200 OK, the service generates signed, ACK-compliant receipts, enabling verifiable-by-default workflows for downstream systems. No implicit trust, no assumptions.

Current Gaps

• No stablecoin adapters yet (e.g., USDC via Circle) — currently mocked, but adapter system is pluggable

• Permission scopes are cryptographically enforced but not yet deeply validated at the API layer

• No rate-limiting or queuing for high-frequency agents (e.g., market bots) — load behavior is still exploratory

But building for agentic payment flows raised some fascinating design questions — especially around transaction volume, batching, and replay protection…

Replay Protection
How should the system prevent an agent from reusing a signed PaymentRequest unintentionally or maliciously?

Batching + Throttling
What happens when a high-frequency agent fires off 1,000 requests in 30 seconds? How do you preserve trust boundaries while staying performant?

Rail-Agnostic Finality
What does “final” mean when your payment rail is USDC on Ethereum vs. internal ledger movement vs. future RTP systems?

Multi-Agent Coordination
Could two agents collaboratively fulfill a single payment? How would receipts reflect partial completion or shared execution?

It’s tempting to hand-wave edge cases like these. But if agents are to operate autonomously, and if we’re serious about protocol-grade guarantees, then these aren’t edge cases. They’re the system.

Building resilient, verifiable infrastructure means sweating the edge cases. That’s where the trust gets earned.

💡 Builder Insight

If you're building:

• Wallets for agents or automated actors

• Treasury automation systems

• Agent-driven marketplaces
  …this model gives you the cryptographic primitives you’ll eventually need.

Think of it like Stripe, if Stripe was designed for bots, and instead of webhooks, you got signed receipts and scoped identity proofs.

Bonus Experiments: Swift SDK + Cross-Language Interop

As I started wiring up the TypeScript SDKs and orchestration flow, I found myself wondering:

That’s what led to ack-swift, my first pass at translating ACK-ID into Apple-native tooling — using Swift, local key storage, and familiar developer ergonomics.

📱 Why Mobile Agents Matter

• In many real-world cases, humans and agents will co-operate, and mobile becomes the most natural bridge.

• Example: A human receives a request from an agent for approval, payment, or task delegation.

• Or: A mobile wallet app holds agent credentials and signs requests locally, then syncs back to the ACK network.

These use cases need:

• Secure key management

• Local signing / verification

• Smooth UX to approve, delegate, or revoke agent actions

ACK enables this, but a Swift-native SDK helps bring it to life.

🧪 What I Built in ack-swift

So far, I’ve scaffolded:

• Agent ID models and credential structs

• Local key generation + message signing

• A basic signer/verifier interface matching ACK-ID primitives

• Hooks for DID-document parsing (eventually for cross-agent trust resolution)

This isn’t production-ready, but it’s already helped clarify:

• How ACK’s trust model ports across language boundaries

• Where developer ergonomics can be improved

• How to design future agent-human UX (QR-style delegation, 1-tap approval, biometric unlocks)

💡 Builder Insight

Cross-platform SDKs will be critical for ACK adoption:

• Swift = mobile agent wallets, human-facing approvals

• TypeScript = orchestration, dashboards, dev tools

• Rust = low-level agent runtimes, LLM-agent integrations

ACK is protocol-first. But SDKs will determine how fast it spreads.

Four Gaps in ACK — and the Opportunities They Create

Despite how well-thought-out ACK already is, it’s still early. And that’s a good thing because it means there are meaningful problems left to solve.

If you’re the kind of builder who likes working on frontier infrastructure, this section is your roadmap.

Here’s some ideas to get you going:

1. Build a Hosted Credential Issuer

ACK-ID requires a credential issuer to create and sign identity attestations, but there’s no plug-and-play option yet. You either:

• Mock it manually via CLI tools

• Or roll your own issuer logic (like I did in agentid-core)

This slows onboarding and makes it harder to test delegation chains quickly.

2. Build Stablecoin Rail Adapters

ACK-Pay is rail-agnostic — but executing payments still requires someone to:

• Integrate with stablecoin APIs (e.g. Circle)

• Simulate real value movement (testnets, sandboxes)

• Generate ACK-compliant receipts

Start with a USDC testnet → receipt verification flow and open it to the community.

3. Build Dev Tools: Playground, Inspector, Explorer

Today, ACK is code-first — which is great for protocol devs, but slows broader adoption. There’s no:

• Credential viewer

• Identity explorer

• Payment debugger

You could build a lightweight “ACK Agent Inspector” that visualizes agent trust relationships, scopes, and status (expired/revoked/etc).

4. Build a Trust Registry for Agent Discovery

There’s no global directory or trust index for ACK agents — yet.

• No DNS-like lookup for agents by purpose

• No discovery tools for finding verifiers or payment processors

• No ENS-style aliasing or reputation

A minimal trust registry could make it easier to bootstrap inter-agent trust in new ecosystems.

These aren’t wishlist items; they’re inevitable infrastructure needs. The only question is: who’s going to ship them first?

Developer Friction You Might Hit

From my own experience:

• Docs are strong conceptually, but the rest is on you to make magic happen

• You’ll hit edge cases (nested delegation chains, revocations mid-flight) early if you’re doing orchestration

• Some terminology feels protocol-heavy, looking at diagrams helped me a lot (and hopefully you too!)

The upside? It’s open-source. It’s cleanly architected. And the core team is active on Slack and Discord.

This Is a Moment for Builders

If you’ve ever wanted to:

• Contribute to an emerging protocol at the right moment

• Build infra that agents (not just humans) rely on

• Shape how programmable finance evolves over the next 5 years

Then ACK is your playground.

And the gaps above? Those are invites.

What This Means for Fintech Builders

If you’ve been heads down in Stripe docs, Plaid integrations, or KYC vendor contracts for the last few years, ACK might feel… futuristic.

But here’s the truth:

And not in 10 years — in the next 12–24 months.

Agents Will Need:

• Identity: Not a wallet address. A scoped, verifiable identity with revocable credentials.

• Payments: Not an API key. A trust-scoped flow that handles execution, audit, and fallback.

• Delegation: Not user impersonation. A cryptographic model for trust-with-limits.

• Compliance hooks: Not hardcoded policies. Dynamic human-in-the-loop review triggers.

ACK is the first protocol I’ve seen that ties all of that together, without depending on any one chain, wallet, or infrastructure provider.

Reframing the Stack

This shift mirrors how OAuth replaced username/password, or how JWT replaced session tokens.

ACK could be the primitive that replaces "trust the API key."

Who Should Pay Attention

This isn’t just for protocol nerds. ACK is directly relevant for:

• Wallet teams – looking to support agents, shared custody, or programmable spending

• Infra startups – building trust layers for LLM agents or B2B automations

• AI x Fintech hybrids – where bots or LLMs take financial actions on behalf of users

• Risk and compliance engineers – who need audit trails and scoped trust for unpredictable workflows

• Solo fintech devs and builders – looking to learn from the edges and ship faster

My Take 🧠

If I were building a new fintech product today, I wouldn’t just integrate ACK.

I’d design my architecture with agent-first primitives from day one — and let humans be the fallback path, not the other way around.

The mental model shift is simple, but profound:

Where to Now?

ACK is one of the most composable, well-architected protocols I’ve ever built on, and it's still early.

If you’re even a little curious about building for agentic finance, here’s what I recommend:

Start Here:

• Explore the docs: agentcommercekit.com

• Join the community

• Check out the community repo

Want More?

I was thinking of hosting a live teardown session soon, but only if there’s a demand for it:

• Diagrams, flows, and architecture talk-through

• Live code Q&A

• Open discussion on what you’re building

Reply if you want an invite — or ping me directly on X / LinkedIn.

And if you’re already building with ACK (or want to), I’d love to connect.
Let’s turn agents into first-class fintech citizens, together.

—

Enjoying this? Share it with your fintech engineering friends — and don’t forget to subscribe.

This teardown was made possible by Trio, a fintech-native engineering partner helping teams build the next generation of financial technology and infrastructure.

Subscribe to Ledger Drift for high-signal insights into how modern fintech is built, from systems to code to teams.