limlock

spec · v0.1 · experimental · last updated

Payments posture

Statement Limlock supports agent-initiated payment delegation via the emerging A2A-extension standards for payment authorization, settlement, and commerce. Limlock's coordination protocol is designed to compose with these payment protocols rather than replace them — Limlock produces a BookingProposal artifact; downstream payment protocols close the loop. Reference implementations of specific standards will ship as those standards reach production maturity in partner-accepting venues.

What this means in practice

  • Limlock never holds payment. Transactions settle on the venue's payment systems or via the end-user's delegated payment agent. Limlock is never in the flow of funds.
  • The terminal artifact is a BookingProposal. Downstream payment protocols pick up from there. Today that means a deep-link handoff into the course's own booking surface; tomorrow it may mean an AP2 cart mandate signed by the user's agent.
  • Composes, doesn't replace. Card rails, stablecoins, course-side prepayment integrations, AP2 mandates — all compose with Limlock's coordination artifact rather than competing with it.

Why protocol-agnostic phrasing

The agent-payments stack is still consolidating. Drafts and reference implementations exist for authorization (AP2), settlement layers (e.g. x402), and commerce wrappers (e.g. ACP). Which combination wins is genuinely unclear in 2026. Limlock names the category publicly and lets the implementation notes name specifics when they ship — keeping the spec on the right side of the question without betting on which extension wins.

Reference implementation status

As of v0.1:

  • The deep-link handoff is the only payment-adjacent action Limlock takes. The calling agent or human follows the URL into the venue's own booking surface to complete payment.
  • No AP2 (or other agent-payment) extension is declared in /.well-known/agent-card.json yet. The declaration will land once AP2 publishes a stable A2A-extension URI; the blocker is upstream URI stabilization, not Limlock-side scope.
  • The BookingProposal shape is designed to be readable by AP2 cart-mandate generators without modification. See GroupEventIntent v0.1.

External references