Why we’re publishing these now

Closed design rooms produce elegant protocols that don’t survive contact with reality. The better pattern, with hindsight, is to publish the hard questions before you think you have the answers. If you have seen the problem solved somewhere — in adjacent protocols, in academic work, in an existing marketplace — we want to know.

1. Identity binding

When an agent presents a consent token to a marketplace, the marketplace has to know two things: that this agent is authorised by this user, and that this user can be held to the transaction if there is a dispute.

Our current thinking: consent tokens carry a user-signed binding to a specific agent instance, not a specific agent product. The user pairs "my Claude on this device" once, via device-attestation-style flow, and thereafter the agent can use that binding. But agents run across devices and forms; the device-pairing story isn’t enough.

What we’d love input on: is there a cleaner way to express "the specific agent instance that this user authorised, wherever it currently runs?" DID-based approaches (W3C Verifiable Credentials) are interesting but heavy.

2. Consent granularity

Too coarse and you get prompt-injection risk: a malicious page convinces your agent to spend broadly-scoped consent. Too fine and you get consent fatigue: the user has to confirm every click.

Our current thinking: consent tokens are bound to (action × resource × cap × expiry). You get a token for "book up to one GeraClinic slot under £80 in the next 30 minutes", not for "do anything with GeraClinic".

What we’d love input on: patterns for batched consent that don’t collapse into agent overreach. "Any of these five listings, one-shot" is a surprisingly hard scope to express.

3. Dispute resolution at scale

If agent commerce is 100x today’s transaction volume, manual arbitration by humans doesn’t scale. If you automate arbitration, you create adverse incentives and false positives.

Our current thinking: dispute routing is a protocol primitive; arbitration is a competitive, pluggable service. Gera operates an in-house arbitration panel for the Gera network; third-party marketplaces bring their own. The protocol standardises the request shape and evidence envelope, not the judgement.

What we’d love input on: how the academic work on multi-sided platform dispute resolution translates into this setting. Are there algorithmic patterns (stake-weighted escalation, prediction markets) that would work at real volume without introducing gameable surfaces?

4. Liability distribution

The agent booked a plumber. The plumber broke something. Who pays: the user who deployed the agent, the agent vendor, the marketplace, the provider?

Our current thinking: the transacting entity is the user; the agent is a tool. But agent vendors who ship agents with known unsafe default prompts should carry some duty of care. This starts to sound like product liability law for software.

What we’d love input on: lawyers who’ve looked at this in EU / UK / US jurisdictions, we want to talk. Especially around how the EU AI Act’s risk-tier model interacts with agent-initiated commerce.

5. Payment rail lock-in

Payments is the most opinionated layer in the stack. Our reference implementation uses GeraCash plus Stripe plus a handful of local rails (Idram, M-Pesa, UPI, PIX, iDEAL). But the protocol shouldn’t force rail choice.

Our current thinking: payment is pluggable via an adapter interface; the protocol specifies the signed-receipt shape and the escrow-state machine, not the rail.

6. Privacy

The marketplace does not need to know Ruth’s full identity to fulfil a consultation. It needs to know a stable pseudonymous ID, a payment commitment, and the completion-verification channel. Zero-knowledge proofs over consent bindings are a promising direction but not yet practical at this protocol’s expected throughput.

How to contribute

Comments on spec drafts at /spec.
PRs to the reference implementation (open soon).
Letters to research at geranexus dot com.
Waitlist for first-wave integrator access.

We would rather get these hard questions wrong in public and fix them in public than guess in private.