gyotak-purchase

Review systems answer the question “did this person buy it?” by asserting it themselves. The platform holds the order record, marks the review “verified purchase,” and the reader trusts the platform. That arrangement works while the platform is both honest and present. It does nothing for a post written on a social network the seller does not control, and it degrades quickly once generating a plausible first-hand account costs nothing.

That cost is now approximately zero. A language model will produce a detailed, specific, emotionally convincing account of a meal that never happened, and it will do so faster than a real customer can type. The effect is not simply that fabrications appear; it is that the economics invert. Making content becomes cheap while being found becomes expensive, and attention concentrates on whoever is best at capturing it rather than on whoever has something real to report.

That concentration is what an advertiser is currently paying for. A manufacturer’s budget flows to accounts optimised for impressions — which need not have used the product, or made anything at all — while the customer who did buy it, ate it, and told a friend receives nothing but the time they spent. If the same budget reached buyers instead, it would reach people with first-hand knowledge, and the reader who acted on their account would in turn have something to gain. Whether that is better advertising is a business judgment; what makes it possible at all is narrower and technical: the reader, or an agent acting for the reader, must be able to tell a real purchase from a claimed one.

A commitment published on a public ledger answers exactly that narrow question. It does not make an account true, and it does not judge whether the fish was good. It establishes that a record with this shape existed at block N, that its author could not have back-dated it, and that only a party holding the opening value can claim it. That is a small thing to prove, but it is the thing that fabrications cannot borrow. The rest of this report describes how gyotak-purchase produces such records, how anyone can check them, and precisely where the guarantee stops.

The contract is 151 lines of Compact (pragma language_version >= 0.22) with three ledger fields — purchases, bindings and owner — and six circuits beyond the constructor: the pure helper publicKey, the two writes recordPurchase and recordXBinding, rotateOwner, and the read-only verifyPurchase and verifyXBinding. Its structure follows gyotak-catch v3 (TR-2026-012) with two differences: there is no GPS range proof, because a purchase has no coordinates, and the value being committed is the buyer’s identifier rather than a location.

2.1 A commitment the buyer can open unaided

The buyer’s identifier and the opening nonce enter recordPurchase as witnesses and never appear on chain:

const buyerId = getBuyerId(purchaseId);
const nonce   = getPurchaseNonce(purchaseId);
const purchaseCommitment = persistentCommit<Bytes<32>>(buyerId, nonce);

The design decision that matters is what persistentCommit computes. For a Bytes<32> value it is the plain SHA-256(nonce ‖ buyerId32) — no domain separation, no field arithmetic, nothing a verifier would need a Midnight library to reproduce. We treated this as a claim to be measured rather than assumed. Before recording anything we computed the digest externally in Node, then submitted the transaction and read the stored commitment back from the indexer. The two matched exactly (§ 4).

The consequence is the point of the whole design. A buyer holding their nonce can verify their own record with one hash on any machine, in any language, with no dependency on GYOTAK and no dependency on Midnight tooling. Had we used a Midnight-specific commitment scheme, the guarantee would still hold cryptographically but only for verifiers willing to install our stack — which, for a reader scrolling a social feed, is the same as no guarantee at all.

2.2 The second record: two identifiers, and why one is not enough

A commitment alone establishes that someone bought a lot. It says nothing about who is posting. recordXBinding adds that link as a separate record in a separate ledger map:

purchases   every purchase; the buyer is hidden inside a commitment
bindings    the subset a buyer has claimed, naming where they post and who they are

A binding holds two identifiers. The first is the account handle the buyer will post from. The second is their own referral identifier — the value GYOTAK issues to a customer when their payment is confirmed, which the customer uses to earn a commission when someone buys through their link.

An earlier version of this contract recorded only the handle, and this report said plainly that the handle proves nothing about who is posting: it is self-reported, and the operator does not verify that the account belongs to the person claiming it. That remains true. What changed is that the handle is no longer alone.

A referral identifier is different in kind. GYOTAK issues it, and it reaches the customer only inside their personal connection URL — the address they use to talk to our ordering system. Holding it is evidence of having been that customer. But it is not sufficient on its own either, and for the opposite reason: it appears in the post, because publishing it is the whole point. Anyone reading a genuine post can copy the referral URL out of it.

The pairing is what works. A fabricated post must match a binding on both fields — the account it was published from, and the referral URL it carries. Copying a referral identifier out of someone else’s post fails because the handle recorded beside it belongs to that other person. Claiming a handle that is not yours fails because you cannot produce the matching referral identifier. Only a party holding that buyer’s connection URL can produce the pair.

This is evidence, not proof. A connection URL can be shared, or leaked, and the operator would not detect it. § 5 states what remains.

2.3 Both identifiers are stored in plaintext

Neither value is hashed. A hashed value would still be verifiable — a reader who sees the post has both in front of them and could compute the digest — but it would require every verifier to run a hash, which for a reader scrolling a social feed is the difference between checking and not checking. Neither value is secret: the buyer publishes both when they post.

The cost is enumerability, and it is larger for the referral identifier than for the handle. A referral identifier is stable across a buyer’s purchases. Anyone who reads it from one post can find every binding that buyer has made — not only this purchase, but all of them, past and future.

We consider that a property rather than a defect. A reader can distinguish someone who bought once and keeps promoting from someone who buys repeatedly, and that distinction is exactly what a reader wants. But it is also a consequence a buyer may not anticipate from publishing a single post, and it cannot be undone. A buyer who stays silent is unaffected: their purchases appear in purchases as commitments and nowhere else, which is the ordinary case and the reason the two maps are separate.

2.4 Time binding and immutability

Both writing circuits constrain the caller-supplied timestamp to within ±600 seconds of the producing block’s clock, using blockTimeGte(t - 600) and blockTimeLte(t + 600) — the same window used by gyotak-temp-log and gyotak-catch v3. Neither a purchase nor a binding can be back-dated to precede a post that motivated it.

Writes are insert-only in both maps: a second write to the same key is rejected. There is no update path and no delete path anywhere in the contract. Neither a handle nor a referral identifier can be reassigned after the fact, which is what makes a binding’s block time meaningful as evidence that the claim preceded the post it supports.

2.5 Connection to the catch record

lotId is SHA-256("gyotak:lot:" ‖ catch_report_id), stored in plaintext. It resolves to the landing recorded by gyotak-catch v3, which carries species, region, and landing date, and which in turn links to the hourly storage temperatures published by gyotak-temp-log. A purchase commitment is therefore not an isolated token: it names a specific physical lot whose provenance is independently readable on the same chain.

2.6 Authorization

All three state-mutating circuits gate on assert(publicKey(localSecretKey()) == owner). The public key derivation uses the domain tag gyotak:purchase:pk:, distinct from the tags used by the other GYOTAK contracts (gyotak:pk: and gyotak:templog:pk:), so a single operator secret yields a different owner key per contract and authorization does not leak across them. rotateOwner allows the admin key to change without redeploying, preserving the contract address and therefore every verification link already published.

The two records are written at different moments, by different triggers, and the gap between them is where the buyer’s choice lives.

1. Purchase        the customer orders, through an AI chat over their own
                   connection URL
2. Payment         confirmed. The referral identifier is issued at this moment,
                   automatically, and reaches the customer in their confirmation
3. Picking         staff pick the physical packs; the shipped lot resolves
                   to exactly one catch record, or no commitment is issued
4. Commitment      the operator issues a purchase commitment (nonce + buyerId32)
5. On-chain        a mirror process records it: recordPurchase
   ── the buyer may stop here; nothing public names them ──
6. Claim           the buyer asks for their proof and gives a handle
7. On-chain        the mirror records the link: recordXBinding

Steps 1 to 5 happen for every paid order whose lot resolves cleanly. Steps 6 and 7 happen only when the buyer asks.

Step 6 is where the two identifiers come together, and how it is done matters. The claim arrives over the buyer’s own connection URL. The tool that receives it takes no customer identifier as an argument — the connection itself is the only accepted credential — and the operator looks up that customer’s referral identifier server-side rather than accepting one from the caller. A referral connection cannot be used to claim: those connections are deliberately excluded from identity resolution, so a referrer cannot claim someone else’s purchase.

Step 3 deserves a note. A commitment is issued only when the picked lot resolves to exactly one catch record on a chain the operator has already published. If two landings share a date and species, the resolution is ambiguous and no commitment is issued at all. We would rather publish nothing than publish a lot identifier that points at the wrong landing.

The contract is deployed on Midnight Mainnet at d11d52bd5875ecc2e89e97149e0237db20a91c989f30268950e892655a2a2a57 and on Preprod at e413ff91958079d1ee2e4c792fe19a9c14a5d4ed7eb7966d3526308a3ea2f846, both with owner = 20fc1d0d5c405e95c669158a3db32217e2be65247dbea06e243745832af2e1be. The Mainnet ledger is empty at the time of writing; the records below are the Preprod rehearsal that preceded it.

4.1 The encodings, measured

The first pair of records was built by hand to test two claims.

That the commitment is a plain SHA-256. Test values were generated in memory, the digest was computed locally before submission, and the transaction was then sent. Reading the stored record back from the indexer gave:

record  PB-20260918-b7f3c55d
local   SHA-256(nonce ‖ buyerId32) = bdeb7b88c067d51437ccf20222b9032faff29920dfdbff1139be2ec3bbc4a4a3
chain   purchaseCommitment         = bdeb7b88c067d51437ccf20222b9032faff29920dfdbff1139be2ec3bbc4a4a3
→ MATCH

That the referral identifier survives the round trip. A referral identifier is aff_ followed by 32 hex characters — 36 characters, too long for Bytes<32> as ASCII. The hex decodes to 16 raw bytes, which we store right-padded with zeros; aff_ is a constant, so the value is recoverable. A binding was recorded with a handle and a test referral identifier, and both read back matching.

4.2 A real order, end to end

The second pair came from a real customer order, and travelled the entire path in § 3 without hand intervention at any step that a customer would not take themselves. The order was placed through an AI chat over the customer’s own connection URL; payment was confirmed, issuing the referral identifier; staff picked three packs of Kuro-Kanpachi from a lot landed on 2026-09-05; the picked lot resolved to exactly one catch record; a commitment was issued; a mirror process recorded it on chain; the buyer then claimed it through their own connection and supplied a handle; and the mirror recorded the binding with both identifiers.

The mirror re-verifies SHA-256(nonce ‖ buyerId32) against the stored commitment before submitting, and submits only on a match. It also refuses to write a binding for a purchase that is not confirmed on this contract.

The referral identifier read back from this binding reconstructed exactly to the value the operator had issued to that customer when their payment was confirmed.

In both pairs the binding settled 84 seconds after its purchase — 14 blocks — and the contract’s own committedAt and boundAt preserve the same order. The claim is visibly later than the purchase it refers to.

4.3 Build reproducibility

The contract source is 6,574 bytes, SHA-256 b4dc7879e5e872d9044747184f8c8bf62bb0a74b3e647b656d0810bfc901235e, compiled with compactc 0.30.0 (language 0.22.0, runtime 0.15.0). A full rebuild from a clean directory, including proving-key generation, reproduced all twenty artefacts under contracts/managed/keys and contracts/managed/zkir byte for byte. The verifier keys stored in both deployed contracts’ state are byte-for-byte identical to the rebuilt files. The per-file SHA-256 table is published in the deployment request accompanying this report.

4.4 Cost

On Preprod each transaction settled for approximately 0.30 DUST, read from the DustSpendProcessed events on chain rather than from the indexer’s fee field, which reports 1 speck and does not reflect what was actually spent. A purchase and its binding therefore cost about 0.60 DUST. The Mainnet deploy cost 50 DUST, a deliberate fee overhead set for deploys only: a deploy that fails and has to be repeated produces a different contract address, which would invalidate every verification link already published. Recording transactions use the ordinary overhead. The contract holds no assets.

Verified:

• The circuit’s persistentCommit(buyerId32, nonce) equals an externally computed SHA-256(nonce ‖ buyerId32), byte for byte.
• A referral identifier survives the round trip through its 16-byte encoding and reconstructs exactly.
• Two purchases and two bindings written and read back on Preprod, all values matching.
• One pair produced by a real customer order travelling the full path of § 3, including the buyer’s own claim through their connection URL.
• In both pairs the binding settled after its purchase, in block time and in the contract’s own timestamps.
• All twenty compiled artefacts reproduce byte for byte from a clean rebuild, and the verifier keys in both deployed contracts match them.

Deployed on Mainnet:

• At d11d52bd5875ecc2e89e97149e0237db20a91c989f30268950e892655a2a2a57, block 2,636,444 (2026-09-18T13:22:54Z). Authorization has been requested; the ledger is empty at the time of writing. An earlier version of this contract was authorized separately and remains deployed with one purchase and one binding recorded; nothing further will be written to it.

Disclosed openly — what this does not prove:

• That the claimant is the buyer. The referral identifier narrows this considerably. It is issued by the operator and reaches the customer only inside their personal connection URL, so producing a matching handle-and-referral pair requires that URL. But a connection URL can be shared, or leaked, and the operator would not detect it. The claim is evidenced, not proven.
  An earlier version of this contract recorded only the handle, and this report described that as its sharpest limit: a handle is self-reported and anyone can claim one. That limit is not gone, but it no longer stands alone.
• That the referral identifier is still active. Referral identifiers are permanent once issued, but the operator can suspend one and issue a replacement. A binding is a historical fact — at this block, this purchase was claimed under this identifier — not a statement about where a commission is payable today.
• That a purchase physically occurred. The chain attests that GYOTAK recorded a commitment; it cannot attest to events in the world. An operator determined to publish false records would produce chain data indistinguishable from honest records.
• That whoever opens a commitment is the buyer. Opening demonstrates knowledge of the nonce, nothing more. A nonce can be shared or leaked.
• Anonymity after a claim. Once a purchase is bound, it is publicly tied to both identifiers, and the set of bound accounts and referral identifiers is enumerable from contract state. Because a referral identifier is stable across a buyer’s purchases, reading it from one post reveals every claim that buyer has made — permanently (§ 2.3). The commitment protects a buyer who stays silent; a buyer who claims is choosing to be named and to be linkable across their claims.
• Verifiability by a plain chat AI. As noted in § 6, the indexer requires POST. An assistant restricted to URL fetching cannot read contract state and should say so.

Path A — An agent that can issue a GraphQL POST

The Midnight indexer exposes contract state over GraphQL. Query contractAction(address) for the contract address above and read the state field. Records in purchases are keyed by purchaseId and carry purchaseCommitment, lotId, committedAt and schema; records in bindings use the same key and carry handle, referrerId, boundAt and schema. No GYOTAK service is involved in this path; the only party trusted is the indexer operator.

To check a post: take the purchase id from the post, read both records, and compare both identifiers against what the post shows — the account that published it, and the referral URL it carries. Both must match. Either one alone can be forged, for opposite reasons: a handle because anyone can claim one, a referral identifier because it is visible in the post and can be copied.

If the post also publishes the nonce, the commitment can be opened locally — compute SHA-256(nonce ‖ buyerId32) and compare.

The encodings: a handle is ASCII right-padded with zero bytes to 32; a referral identifier is the 16 bytes behind aff_<hex>, right-padded to 32, so reconstructing it means taking the first 16 bytes, hex-encoding them, and prepending aff_.

Path B — A reader with a browser

The 64-character transaction hashes from § 4 resolve on a Midnight block explorer, establishing that the transactions exist, which blocks carried them, and when those blocks were produced. The explorer does not decode contract state, so this path confirms existence and timing but not contents.