Phase 0 Feasibility Gate

Onchain Graveyard sells one thing: a permanent, personal memorial that cannot be resold. That single product promise is also the hardest technical constraint in the proposal, and it is worth stating plainly why.

On Cardano's eUTxO ledger, a minting policy alone cannot make a token non-transferable. A minting policy runs when tokens are minted or burned — it does not run when an owner moves a native token that is already sitting in an ordinary wallet address. Any design that says "mint it straight to the buyer's wallet and it will be soulbound" is mistaken, and we corrected exactly that mistake in our own earlier draft.

Non-transferability therefore requires the token to live at a spend validator that forces a continuing output on every spend. And because we refuse to be custodial, that validator must be shared custody: the owner holds the spending key, the operator holds no key at all over the owner's certificate. That is the core of what CIP-113 describes, and it is the part we had to prove we can build and run before asking anyone to fund it.

An earlier, custodial design of ours failed its own internal audit on precisely this point. So the gate below is not a formality — a negative result would have meant not submitting.

Two Aiken validators, roughly 350 lines together, written for this gate and open in the repository at onchain/validators/.

The four properties under test

The bench is a Hydra Head running in offline mode. A Hydra Head is isomorphic with Cardano layer 1: the same Conway ledger rules, the same Plutus V3 cost model, the same min-UTxO arithmetic. What differs is that transactions settle in milliseconds and no node, faucet or block wait is involved. Every "accepted" or "rejected" below is therefore a verdict of the real ledger rules, applied to a real, signed transaction.

Each gate is one transaction. The valid case and its attack variant are produced by the same builder with one parameter changed, so a passing gate cannot be an artefact of two differently written transactions.

Two verification layers back each other up: the Aiken unit tests (23 on these two validators, 54 across the package) name which condition in the validator fires, while the Head gives the ledger's verdict on a fully signed transaction built through the same SDK path the production service will use.

Thirteen signed transactions. Two had to settle; eleven had to be refused. All thirteen behaved as required.

A Head does not report how much a script actually consumed, so we did not estimate it. For each script slot we lowered that one redeemer's execution budget — leaving the others untouched — and binary-searched down to the exact point where the ledger starts refusing the transaction. That threshold is the real consumption. Min-ADA was found the same way, by walking the certificate's UTxO down until the ledger's minimum-value rule rejects it.

Roughly 150 transactions go into those searches. A failing submission changes no state, so the same target can be probed repeatedly; only a successful probe consumes a plot and needs a fresh one.

What a player actually pays at the cheapest tier is the service price (1 ADA) plus the locked min-ADA plus the network fee: ≈ 2.93 ADA for a typical inscription and ≈ 3.78 ADA for the longest one. All three components must be shown on the payment screen before signing.

What the operator fronts to open the pilot's 1,500 plots is ≈ 1,714 ADA of reclaimable working capital — our own money, not a Catalyst budget line.

The point of measuring is to be corrected. Three planning assumptions in our own proposal did not survive contact with the ledger, and we would rather publish that than carry it into a budget.

One optimisation is already visible in the numbers: both transactions currently carry the full validator inline. Publishing the two validators as reference scripts should bring the engrave transaction down to roughly 1–1.5 KB, trading size for the reference-script fee. That is month-1 work, deliberately not done in this proof.

The harness builds the validators, starts a throwaway Head in Docker, runs all thirteen gates, performs the measurement searches and writes both a report and its raw data — including the full ledger error for every refused transaction. Deterministic keys mean a rerun produces the same addresses and script hashes.