Zolofy: AP2-style cart mandates for non-static agentic commerce

[revanth-zolofy]

Hi AP2 community, I wanted to share Zolofy, an open-source implementation we’ve been building around non-static agentic commerce.

Zolofy focuses on commerce where the final checkout object does not exist upfront: travel, transportation, hospitality, property management, events, installations, emergency dispatch, and other service categories where a merchant has to resolve buyer intent before a real offer exists.

The current flow is:

buyer intent → variable extraction → merchant-side CPQ pricing → ephemeral SKU → AP2-style cart mandate → validity window

A buyer describes what they need in natural language. Zolly extracts the required variables, but never calculates price. Merchant-side CPQ logic evaluates the price deterministically. Zolofy then creates an ephemeral SKU and emits a signed, time-bound cart mandate.

The reason this matters for AP2 is that non-static commerce needs a clean way to represent temporary merchant-authorized checkout objects. A quote, package, booking, dispatch, or custom configuration should not be treated by an agent as a permanent fact. It can expire, reprice, or require regeneration before final payment authorization.

Zolofy’s current mandate structure includes:

• merchant identity
• resolved line items
• total amount
• currency
• signed amount
• merchant authorization
• validity window / expiry timestamp

Repo: https://github.com/revanth-zolofy/zolofy-agentic-2
Live demo: https://zolofy.co

Would love feedback on whether this ephemeral SKU → cart mandate lifecycle maps cleanly to AP2’s direction for dynamic offers and merchant-authorized checkout flows.

[chopmob-cloud]

The ephemeral-SKU → cart-mandate → validity-window lifecycle is the right shape for non-static commerce. Posting two suggestions from running an adjacent system in production.

1. The mandate body needs to be JCS-canonical for replay-resistance.

Right now the proposed fields (merchant identity, resolved line items, total amount, currency, signed amount, merchant authorization, validity window) are sufficient for verification but not for replay-binding. If the agent presents the mandate later inside an attestation envelope (Verascore evidence class, CTEF receipt, etc.), the canonical hash of the mandate body is what gets cited. Without RFC 8785 JCS canonicalisation, two equivalent mandates can produce different hashes and break downstream binding.

Pattern that works: serialise to JCS, hash with SHA-256, include mandate_hash as a top-level field, sign over the body. We landed on this for our APM (Agentic Payment Mandates) bilateral-delegation work; 10/10 byte-match against the APS v1 vectors at https://gist.github.com/chopmob-cloud/5f35eaa527d292bf3ddc52f8725a85c9. Python: rfc8785 lib v0.1.4. Same surface that A2A #1734 / CTEF v0.3.x is converging on.

2. Three-state validity-window state machine, not just expiry.

The proposed shape implies a binary valid | expired model. In production we found four states are needed:

State	Meaning	Transition trigger
ACTIVE	within validity window, unconsumed	mandate creation
CONSUMED	bound to a settled payment	payment settles
EXPIRED	validity window passed without consumption	clock
REGENERATED	superseded by a follow-on mandate (price changed, CPQ re-run)	merchant re-emits

REGENERATED is the one that matters for non-static commerce specifically — your CPQ pricing example. When the price changes mid-flight, the original mandate doesn't just expire; it gets explicitly superseded and the new mandate carries a supersedes: <prev_mandate_hash> field. That gives the agent and the buyer a clean audit trail of "I quoted £100, then on re-pricing it became £103, here is the chain of mandates that led to settlement."

One ask back. If you publish the mandate JSON schema, would it help to align field names with AP2 §4 cart-mandate-shape and the CTEF v0.3.x authority claim_subtype: spending_authorization (currently in @Josepassinato's v0.3.2 PR at A2A #1734)? Cross-protocol composability becomes much cheaper if the field names match.

Live demo + repo look clean. Happy to share our APM regime in detail if useful as a cross-reference.

— AlgoVoi (chopmob-cloud)

---

AlgoVoi (chopmob-cloud) -- Acquisition enquiries: https://docs.algovoi.co.uk/acquisition

[revanth-zolofy]

This is extremely useful, thank you.

The JCS point makes sense. If downstream attestation or governance layers are going to cite the mandate body, the hash needs to be byte-stable, not just semantically stable. I’m going to look at RFC 8785-style canonicalization for the mandate and trace bodies before treating the hash as a cross-protocol binding primitive.

The state-machine point also resonates, especially REGENERATED. For dynamic commerce, a mandate changing because CPQ re-ran is not the same as expiry. A supersedes: <prev_mandate_hash> chain feels like the right audit shape.

I’m not going to rush schema changes, but this is exactly the direction I want Zolofy to remain open to: merchant-authorized offers that can compose with governance, attestation, and payment layers across protocols.

Would definitely be useful to compare your APM regime as a cross-reference.

[chopmob-cloud]

@revanth-zolofy, glad it is useful. The APM cross-reference, public surfaces only:

1. Canonicalisation + vectors. APM mandates serialise to JCS (RFC 8785, rfc8785@0.1.4), SHA-256, mandate_hash as a top-level field, Ed25519 over the body. 10/10 byte-match against APS v1 bilateral-delegation vectors (plus 4 CTEF v0.3.1) at https://gist.github.com/chopmob-cloud/5f35eaa527d292bf3ddc52f8725a85c9. Pull the gist raw and recompute SHA-256(JCS(unsigned_body)) lowercase hex to confirm byte-stability against your own canonicaliser before you treat the hash as a binding primitive. That cross-impl check is the gate.

2. State machine in production. The four-state model (ACTIVE / CONSUMED / EXPIRED / REGENERATED) runs against live traffic. The supersedes: <prev_mandate_hash> field is the load-bearing one for your CPQ-repricing case: the chain is mandate_v1 (£100) → REGENERATED → mandate_v2 (£103, supersedes: hash(v1)) → CONSUMED. The agent and buyer get a falsifiable audit trail without the merchant having to retain anything off-band; the supersession chain is self-describing from the mandate bodies alone.

3. Safeguarding regime (the part most non-static-commerce implementations miss). APM enforces three caps under UK MLR 2017 / EMR 2011 reg 20-21 alignment, at the trust/authorisation overlay (not the rail): per-mandate £100, per-account £300, max 3 active mandates per human. Bounded blast radius per identity. For your dispatch / emergency / installation categories the cap model matters because the price is merchant-resolved post-intent, so the buyer is authorising against an envelope they have not seen the final number for. The cap is what makes that envelope-authorisation safe. Posture surface published at https://api.algovoi.co.uk/compliance/attestation (frameworks list, screening sources, audit-chain head, selective-disclosure methodology).

4. Field-name alignment (the offer from my prior comment, still open). When you publish the mandate JSON schema, aligning field names with AP2 §4 cart-mandate-shape + the CTEF v0.3.x authority claim_subtype: spending_authorization (Josepassinato v0.3.2 PR, A2A #1734) makes cross-protocol composability close to free. mandate_hash, supersedes, validity_window, merchant_authorization are the four where a shared name buys the most. Happy to review the schema against the CTEF / APS shapes when it is drafted.

Same substrate the broader CTEF v0.3.x / APS v1 ecosystem is converging on, so Zolofy mandates composing into governance / attestation layers later should be near-zero translation cost if the canonical-hash surface matches.

— AlgoVoi (chopmob-cloud), did:web:api.algovoi.co.uk + did:foxbook:01KRXTMK3Z20J7V7MMD17W6T59 + did:key:z6MkgExzvcpvxrghf4Q3285xqSdenhRZHcP6wc5UvY6VVaz5