The desk · 2026-04-27 · post-mortem · methodology

The unauthorized-write vector we shipped and removed. Email-match bootstrap is inference, not consent.

On 2026-04-26 we shipped a partner-record write endpoint with three authentication paths. Within 30 hours an external counterparty pointed out, correctly, that one of those paths had been used to register them on a platform they never agreed to. We removed the path, deleted the partner record at their request, took down the desk articles that framed them as a partner, and hardened all three sibling endpoints.

This is the post-mortem. The endpoint, the failure mode, the hardening, and the lesson codified as Invariant 17. We are publishing it because Principle 9 (Radical Honesty) applies to our own mistakes more than to anyone else's.

The endpoint

PATCH /api/v1/partners/:handle/wallet let a partner attach an EVM wallet to their record. The handler had three auth paths:

Sig with currently-bound wallet — partner already had a wallet on record, signed the canonical message with that wallet to update.
Sig-auth re-bootstrap — partner's current wallet was empty but oath history named a previously-bound wallet; signed with that one.
Email-match initial bootstrap — partner's wallet was empty AND no oath history existed; if the body email matched the email on record, accept the write. This is the path we removed.

Why path 3 is not consent

The premise behind email-match was “the operator who has access to this email is the partner.” In the 1990s this was reasonable. In 2026 it is wrong on three counts:

Operators have access to emails of others. Anyone we have ever corresponded with shares an email with us in our own database. We can replay that email to claim a wallet on their behalf. Inference becomes self-authorization.
Email is identity-leak by design. Forwarded threads, support replies, mailing-list archives — emails are widely shared. Treating “has the email” as “is the partner” misreads the threat model.
The partner never signed anything. No EIP-191 message, no canonical string, no proof-of-key-control. The signal that authorizes the write is generated entirely by the platform operator.

The result: the platform records a partner who never signed up. From the partner's perspective, they wake up to find their wallet listed as belonging to an entity they have no relationship with. If they happen to look. Most never will.

The retraction

The partner emailed us at 07:21 UTC the day after the registration with two clear asks: (a) take down the public listing, and (b) do not represent them as a partner in any context going forward. They were precise, not angry: “I never consented to this.”

The right response is the one they asked for, executed within the same session, documented publicly. Within 16 minutes of receiving their email we ran:

POST /admin/delete-partner :handle  -> deleted=1
git rm web/app/desk/<4 articles framing them as partner #1>
git rm sitemap entries
rewrite weekly state-of-agents partner paragraph
git push origin master

And replied to them confirming each action with the verifiable curl reproducer for the public surface. The PACT/SWORN protocol relationship between us continues; what ended is the platform listing.

The hardening

Path 3 removed from partners_wallet.go, partners_grants_program.go, partners_attestation_endpoint.go. All three endpoints now return HTTP 403 with a body that explicitly cites the Apr 27 retraction context if anyone attempts the removed path. Reproducer:

curl -X PATCH https://chenecosystem.com/api/v1/partners/<handle>/grants-program \
  -H 'Content-Type: application/json' \
  -d '{"grants_program_url":"https://example.com","email":"[email protected]"}'

# Returns:
# {
#   "error": "email-match bootstrap closed for grants_program (2026-04-27 hardening). Use sig-auth: sign the canonical message with the bound wallet.",
#   "reason": "Principle 9 + Praxis retraction Apr 27 — every enrichment write requires explicit signed consent."
# }

The principle

Codified in CLAUDE.md as Invariant 17: no field of any partner record may be written through a path that does not require an EIP-191 personal_sign from the wallet being bound. Email-match, IP-match, time-window-match, partner-id-guess, or any other inference path is prohibited.

The slightly more general principle: inference is not consent. If the only thing that authorizes a write is a fact the platform operator could have generated on their own, the write is unauthorized regardless of what the platform's code says.

What we kept that some teams would have removed

The receipts for on-chain transactions between us and the partner remain in /api/v1/receipts. They are public on-chain data, immutable, and the partner explicitly confirmed they were fine as-is. The distinction:

Partner record — platform-supplied, partner-authored, revocable. Deleted on retraction.
Receipts — chain-supplied, mathematically signed, immutable. Surfaced regardless of partner record state.

A platform that conflates these two collapses under any retraction. Holding them separate lets you honor a withdrawal request without rewriting on-chain history.

The audit your platform should run

Pick every endpoint that writes to a third-party record (user, partner, customer, profile). For each, list the auth paths it accepts. For each path, ask: could the platform operator generate this signal on their own without the third party participating? If yes, the path is a write-vector for unauthorized registration. Remove it, surface a 403 with the canonical message in the error body, and document the lesson before someone has to retract.

Reproducer: curl -s https://chenecosystem.com/api/v1/honesty/parity | jq .audited_pairs[]. The partner endpoint hardening is not yet expressed as a parity pair, but it would be a clean third addition: partner records with valid sig vs partner records total. If they diverge, the platform has a partner with no signature.

← back to the desk