Engineering || Forge Actions I: The Week We Audited Everything, and Met Our Own Ghost
A week-long security-hardening pass across all of EchoForge: a thirteen-component audit, the discovery that our deployed minting policy was compiled from a validator we had renamed away, and a rebuilt authenticity model that answers 'is this really an EchoCert' without trusting any single policy id.
Every product ships with debt. Some of it is code. Some of it is the quiet gap between what you think is deployed and what actually is. This week we spent seven days paying both kinds down at once — and in the process, we met a ghost of our own making.
This is the engineering account. There is a companion note for everyone else in the Echo With You series; if you hold a certificate and just want to know whether anything changed for you, read that one instead.
The Thirteen-Component Audit
We started by auditing EchoForge component by component — not one broad sweep, but thirteen focused passes: EchoCert's backend and frontend, its Aiken validators and Supabase migrations; EchoID's identity and tier engine; EchoUploader; EchoDash; the shared SDK; and the repository infrastructure itself.
The recurring theme was not exotic. It was the oldest lesson in trust systems: verify the thing you actually care about, not a proxy for it. A wallet signature proves someone holds a key — it does not prove they own the address they claim, unless you bind the two. A transaction paying a treasury proves money moved — it does not prove who paid, unless you bind the payer. Each finding was, at heart, a place where a proxy had been mistaken for the real anchor. We tightened those bindings across the stack.
The Ghost in plutus.json
Then we went looking at the on-chain contract, and found something humbling.
EchoCert's minting policy is written in Aiken. We have a validator named echocert.ak. We also have a second validator, documint.ak, a near-identical anchoring policy we had written earlier. Our documentation, our mental model, our blog — all said EchoCert runs echocert.ak.
It does not. It never did.
When we derived the live policy id from first principles — taking the compiled bytes, applying the treasury and issuer parameters, hashing the result — the number that came out matched the chain only when we fed it documint's bytes, not echocert's. We confirmed it byte-for-byte on both mainnet and preprod: we fetched the actual deployed script back from the chain by its hash, diffed it against documint's compiled output, and reproduced the live policy id exactly. The frontend's plutus.json had, at some point, been pointed at documint's bytes while keeping the echocert name. Nobody noticed, because nothing broke: documint and echocert enforce the same guarantees.
The failure was not in the code. It was that the label and the reality had drifted apart, silently, and our documentation described a validator that was never deployed. A ghost: real enough to talk about, not actually there.
Adopting documint, On Purpose
We had two choices: recompile to the "correct" echocert.ak, or adopt the reality. Recompiling would change the policy id and orphan every certificate ever issued. Reality won. We reviewed documint line by line against echocert — issuer signature required, exactly one token, token name bound to the content hash, a treasury payment enforced on-chain — and documint is, if anything, stricter (a five-ADA floor where echocert had one). We formally adopted documint as EchoCert's contract, archived the echocert.ak source with a full reproducible proof of the discrepancy, and added a CI guard that fails the build the instant those frozen bytes ever drift again. The ghost is now documented, fenced, and watched.
One Domain Verification, Not Two
The audit surfaced a second kind of drift — not in code, but in product shape. Two different flows both called themselves domain verification. EchoDash charged fifty ADA to create an organization and quietly recorded a domain as its "authority." EchoCert charged fifty dollars a year to actually prove domain control via a DNS record. One was a real cryptographic proof. The other was a payment with a domain string attached and no proof at all — and, we discovered, its fee was never verified on-chain and could be skipped entirely.
We collapsed the two into one. There is now a single domain-verification flow, in EchoDash, backed by one authoritative endpoint: pay, prove control of the DNS record, done — with the payment now verified on-chain and bound to the paying wallet. Organization creation is just organization creation again, named honestly. A domain you have not proven reserves nothing and grants nothing, which quietly removes the incentive to squat one.
What "Genuine EchoCert" Actually Means
The ghost forced a deeper question. If every issuer mints under their own policy id — and they do, because the policy is parameterised by the issuer's own wallet — then there is no single "official" policy id to check against. So how does a lookup page know a certificate is genuinely an EchoCert and not a look-alike token someone minted themselves?
The answer we shipped is a three-layer check, decided entirely server-side and impossible to forge from metadata:
- —Is it an EchoCert at all? We re-derive the policy id from the deployed contract's bytes, using the official treasury as a fixed parameter and the transaction's real signers as the issuer. If the number matches, the official treasury is provably baked into that policy — and we confirm the mint actually paid that treasury on-chain. An attacker compiling with their own treasury produces a policy id that can never match ours; attaching a five-ADA transfer to our address without the matching contract structure fails too. Both must hold.
- —Does it earn the green badge? Only if the issuer, derived from the chain rather than trusted from a form, holds a live domain verification.
- —Is it official? A reserved layer, wired to EchoID, off by default.
The anchor is the official treasury constant, not "some self-consistent derivation" — because self-consistency is exactly what an attacker can manufacture.
Treasury Rotation, Encoded
One more piece of honesty. Our treasury key rotated once already this year after an unrelated incident. That means the authenticity check has to know history: certificates minted before the rotation derive from the old treasury and are legitimate; the same old key used after the rotation is not. We encoded this as an explicit set of known treasury constants with time gates in both directions, so the model tells the truth across the rotation rather than reading the entire pre-rotation past as forged. The next planned rotation — moving the treasury to cold storage — is already written down as the same procedure, before we need it.
What Shipped
A hardened stack with its trust bindings tightened; a documented, fenced, CI-guarded contract; one honest domain-verification flow with a real, verified payment; and an authenticity model that survives having no single official key. None of it was glamorous. Most of good engineering is not. It is mostly the discipline of making the label and the reality match, and then building a check that screams the moment they drift again.
Published July 3, 2026 · EchoForge · ENGINEERING Series