FAQ: Common Objections to Agent Commerce, Answered Honestly

1. “Agents will be jailbroken, and then an attacker can do anything.”

True — and the consent token design assumes this. A jailbroken agent cannot forge a consent token because the token is signed by the user’s key, not the agent’s. The worst case is that the agent tricks the user into approving a malicious consent card. The mitigation is the consent card UX: the user must see the counterparty, amount, and action before approving. This is identical to how card authentication works today, and it has the same residual risk.

2. “Regulators will never allow it.”

Regulators actually want auditable, receipt-based transaction chains. The current web is harder to regulate than a protocol- compliant agent economy would be. We have had early conversations with the FCA and ICO (both unpaid, both exploratory). Nothing is promised, but the reception has been “show us the spec and let us argue about it” — not “no.”

3. “Why not just use OAuth?”

OAuth is designed for standing authorisation (GitHub allows Vercel to read my repos). Agent commerce is per-transaction authorisation with a monetary cap. Retrofitting OAuth into per-transaction mode produces either too-broad grants (phishing targets) or too-many grants (UX disaster). A purpose-built consent-token format with narrow scope and short expiry is simpler to reason about.

4. “Escrow is too slow and expensive for small transactions.”

Agreed for sub-£2 transactions. Our planned mitigation is a fast-settle mode with a shorter dispute window (e.g. 24 hours) and a lower-friction arbitration path (automated, small-claims- style). For larger transactions — the ones where fraud actually hurts — escrow is the right default.

5. “Ed25519 receipts are too much bandwidth.”

A full receipt chain is ~2 KB. For high-volume marketplaces this adds up. We plan to support batched receipts (one signature over a Merkle root of many receipts) for large aggregators. The single-transaction overhead is tolerable for any transaction large enough that users care about disputability.

6. “Users will approve anything; consent is theatre.”

Partly true. The mitigation is not to make users read more — it is to make the agent refuse worse deals on the user’s behalf. Preferences set once (“never approve anything above £200 without re-auth” or “always require refund ladder”) filter 90% of bad transactions before the user ever sees them. The consent card is the last line of defence, not the first.

7. “Which payment rail? You cannot please everyone.”

We are not trying to. GeraNexus is neutral on payment rails. Stripe, GeraCash, Skyfire, iDEAL, Idram, UPI, PIX — any of them can plug into the escrow state. The protocol specifies the state transitions and the receipts, not the rails.

8. “This will be EU-centric and US-incompatible.”

The consent-token + receipt model is GDPR-native (explicit, auditable, minimally scoped) but it is not EU-exclusive. US regulators (CFPB, FTC) have been increasingly receipt-friendly since 2024. The larger divide is cultural: EU users expect consent, US users expect convenience. The consent UX can be tuned per-region without changing the protocol.

9. “How does this interact with chargebacks?”

Chargebacks operate at the card-network layer and always will. The GeraNexus receipt chain becomes first-class evidence in a chargeback dispute (the user approved X, the marketplace delivered Y, here are the signatures). Our belief is that over time the receipt chain reduces chargeback rates rather than eliminating the mechanism.

10. “Small businesses cannot afford to implement this.”

We are building drop-in adapter libraries for the common backends (Next.js, Rails, Django, Laravel, Go, Express). The target integration cost is a half-day for a small business with an existing booking system. If it ends up being a week, we have failed and we will simplify the spec.

11. “LLMs hallucinate — agents will book wrong things.”

True. The protocol cannot stop an agent from believing a user said “tomorrow” when they said “Tuesday.” The mitigation is the consent card: the user sees the final proposed action before approving, and misinterpretations are caught at that point. Agent reliability will also improve; this objection gets smaller each year.

12. “The big marketplaces (Amazon, Uber, Booking) will never adopt this.”

Maybe not at first. But the regulatory pressure on opaque marketplaces is increasing, and the first platform to offer genuinely auditable agent commerce will have a compliance story competitors cannot match. More practically: we do not need the giants. A long tail of small marketplaces (plus the Gera portfolio itself) is enough to prove the model. Giants follow.

Where we are still unsure

Two objections we do not have a clean answer for yet:

• Cross-jurisdiction enforcement of dispute outcomes. A UK arbitration panel ruling against a Georgian marketplace is a signed receipt. Enforcing it is a separate legal question we are working through with GeraCompliance.
• Consent key recovery. If a user loses their consent key and it was on-device, their recovery flow depends on their identity provider. This is outside the protocol’s scope but inside the UX experience.

If you have an objection we have not answered here, file an issue on the spec repo or email [email protected]. Good objections make the spec better.