gyotak-purchase

Before the change described here, TR-2026-015 opened its list of limits with the one that mattered most: the handle is what the buyer told us, and GYOTAK does not verify that they own the account. The claim arrives over the buyer’s own authenticated connection, so the operator knows which customer is speaking; but that knowledge lives entirely off chain. A third party reading the ledger sees only that GYOTAK wrote “purchase P is claimed by @handle,” and has to take the operator’s word for the step that produced it.

There is a second dependency of exactly the same shape, and it is the one this report attacks. The reward loop that makes the whole design worth building does not run on handles; it runs on referral URLs. A buyer posts about the fish they ate and includes their referral URL; a reader who orders through that URL makes the poster a referrer. Nothing published on chain connects the referral URL in the post to the purchase the post is about. A reader can verify that someone bought lot X, and can see an account claiming it, but cannot verify that the URL collecting the reward belongs to that buyer rather than to whoever copied the post.

Both gaps have the same structure: the operator holds a fact, acts on it correctly, and publishes only the result. That is exactly the arrangement TR-2026-015 § 1 argued against in the case of “verified purchase” badges. Applying our own argument to ourselves, the question becomes narrow and technical: is there a value already in the buyer’s hands that GYOTAK cannot forge on their behalf, and that a reader can compare against a post without any cooperation from us?

There is. The referral id is issued by the operator, not by the buyer, and it exists in exactly one place a buyer can reach: the personal token URL they were given after their payment was confirmed. It is also, by design, the value the buyer publishes. The rest of this report describes what follows from stamping it into the claim, what that still fails to prove, and which parts of the surrounding loop are running today rather than planned.

2.1 What the record would carry

The v2 binding carried four values: purchaseId, handle, boundAt and schema. The v3 binding adds one more, in plaintext — and drops purchaseId, which duplicated the map key:

v2 XBinding    purchaseId  handle  boundAt  schema
v3 XBinding                handle  boundAt  schema  referrerId

The referral id is an operator-issued token. It is not a name a buyer picks, and not a value a buyer can mint: it is generated by the operator from 16 random bytes and written into exactly one place a customer ever sees — the personal connector URL they receive once their first payment is confirmed. The claim already reaches us over that connection, and the operator already records which referral id was present when the claim was made.

2.2 What a third party could then check

With the id on chain, the check a reader performs becomes local and complete. They have a post in front of them; the post carries a referral URL ending in some id R, and names a lot. They read the chain: purchase P is recorded for that lot, and the binding for P says handle = @h, referrerId = R. What follows does not depend on GYOTAK’s honesty at the moment of reading: the account claiming this purchase claimed it from a connection holding R, and R is the id that will earn on any order placed through this post. The referral URL and the purchase are welded together in public, by a record neither the poster nor a copier can produce after the fact.

That is worth stating precisely, because it is easy to overclaim. This does not prove that the account is the buyer. It proves that whoever made the claim held the buyer’s personal connector URL, and it makes the reward destination part of the same immutable record as the claim. A copier who lifts the post and swaps in their own referral URL now produces a post that fails a check any reader can run.

2.3 Why plaintext

The handle in v2 is stored in plaintext for a reason TR-2026-015 § 2.3 gives: a reader who sees the post already knows it, so publishing it lets them compare directly instead of computing a digest. The referral id is the same case, only stronger — publishing it is its entire purpose. The buyer puts it in the post themselves; it is printed in their own profile if they choose; it travels through every link a reader clicks. Hashing it would hide nothing that is not already public, and would cost the one property that makes the check usable by an ordinary assistant: a string comparison, with no crypto library and no opening value.

The cost is the same as for the handle: the set of referral ids that have claimed a GYOTAK purchase becomes publicly enumerable. That, again, is the point. These are the ids of people who chose to speak, and who are asking readers to trust their account of a meal. The buyers who stay silent have no binding at all, and their purchases name no one.

2.4 Two constraints that come with it

The past is not rewritten. Three bindings were stamped with the v2 circuit before v3 existed — two on Preprod, one on Mainnet. They have no referrerId field, and the operator does not add one to its own copy of them afterwards: back-filling a value that was never stamped would make the operator’s record and the chain disagree, and the only thing the chain guarantees is that GYOTAK recorded a thing and has not changed it since. The absence of a referral id is therefore meaningful in its own right — it says “stamped under v2, or no referral id existed” — and it is kept as an absence rather than filled with a blank value, which would erase the difference between “no referrer” and “not captured.” The same rule governs the v2 contract itself: it remains deployed, holding what it holds, and nothing further is written to it.

The value is fixed; its meaning is not. A referral id, once issued, never changes. Whether it is still active does change: an operator can suspend a referrer, after which the customer’s next confirmed payment issues a different id. A stamped id is therefore a fact about the moment of the claim, not an instruction about where to send money. Rewards are computed from the operator’s own records; nothing should ever be paid out by reading an id off the chain. We state this here because the record invites exactly that mistake.

A binding belongs to a purchase, not to a person. It is written in its own transaction, separate from the transaction that recorded the purchase, and the operator keeps at most one such record per purchase. A handle attached to one purchase does not carry over to the next. Claiming again means claiming a different purchase — and, as implemented today, a binding is written only when the buyer claims that particular purchase, so a repeat purchase is bound when its buyer asks, not automatically. § 7 sets that choice of trigger beside the alternative.

This is deliberate, and it is not an implementation detail. Two things follow from it.

A single purchase does not buy a permanent voice. If the binding were per customer, a person who bought once could keep publishing referral-bearing posts indefinitely, each backed by the same year-old purchase, and the record would say the same thing on the thousandth post as on the first. Binding per purchase means the record a poster can point to is as recent as their last actual purchase. Someone who wants to keep speaking with a record behind them has to keep being a customer.

Repeat purchase becomes visible. The reverse of the same property is more interesting. A sequence of bindings under one handle is a public record of buying the same thing again, and again. For a reader deciding whether to believe an account of a meal, that is closer to what they actually want to know than any single verified purchase: not “did this person buy it once” but “do they keep buying it.” No wording in a post can fake it, because each entry in the sequence required a payment the operator confirmed.

3.1 Why the purchase record itself carries no account

It would be simpler to put the handle in the purchase record and skip the second transaction. We do not, and the reason is the one the commitment exists for. If the purchase record named the account, then every purchase by that customer would be tied to that account the moment they spoke once. The buyer who tells no one would lose the protection retroactively, because the link would already be written into the record of the purchase itself.

The same reasoning rules out the convenience of a permanent customer-to-handle mapping on the operator’s side. Such a mapping would rebuild exactly the link the split was designed to prevent, only off chain instead of on it — and a commitment scheme whose privacy is undone by the operator’s own convenience is not a privacy scheme. The operator therefore looks up a returning buyer’s previous handle by walking their own bindings, and stores no direct mapping.

The binding is one step in a cycle whose other steps are ordinary commerce. Written out, the cycle is short:

1. Order       the customer orders in an AI chat (MCP)              [implemented]
               if they arrived through a referral URL, the referrer
               is taken from the connection token, never from a
               free-form argument
2. Payment     confirmed; the operator issues this customer their    [implemented]
               own referral code automatically, without being asked
3. Proof       a purchase commitment is issued once the shipped lot  [implemented]
               resolves to exactly one catch record (TR-2026-015)
4. Insert      a printed card in the box carries the way back to     [not implemented]
               the chat and to the buyer's own referral URL
5. Post        the buyer's own AI writes the post; GYOTAK returns    [implemented]
               facts and constraints, not text
6. Claim       the buyer claims the purchase and gives a handle;     [implemented]
               the referral id present on that connection is
               recorded with it, and stamped by the v3 circuit
7. Next order  a reader orders through that URL, and step 1 records  [implemented]
               it as a referral. The cycle closes.

Step 2 is the part that gives the cycle its shape, and it is worth being precise about. The referral code is not applied for; it is issued at the moment a payment is confirmed, for chat orders placed by an identified customer. Nobody is admitted to the referral programme by audience size, follower count, or an application an operator approves. The only qualification is having bought something. A person who has not bought cannot refer, and a person who has bought is already a referrer whether or not they ever use it.

Step 5 is described in § 5.3; step 6 is what § 2 and § 3 are about. Step 4 is now the only step not in place, and the one piece of the cycle that is physical: a card in the box, in the customer’s language, that leads back to the chat. There is no code for it and there could not be; it is a printing and packing task, listed here because the cycle does not close without it.

One property of the whole arrangement deserves naming, because it is the reason for building it rather than buying advertising. In an ordinary affiliate programme the incentive flows to whoever can attract attention, and knowledge of the product is optional. Here the right to refer is issued by purchase, so the set of people who can earn is a subset of the people who have first-hand knowledge. That does not make what they write true — § 8 is explicit about this — but it means the budget reaches buyers rather than audiences.

A referral programme attracts three predictable abuses: referring yourself, claiming a post that was never made, and flooding the network with operator-written copy under customers’ names. Each is handled by structure rather than by policing, and all three defences are implemented and running.

5.1 Self-referral is excluded automatically

A customer cannot earn on their own order. The exclusion is applied in two places, because orders arrive by two paths. In the chat path it lives in the earnings calculation itself: any order whose buyer is the referrer is discarded, and the summary and the line-item detail apply the identical rule, so the two can never disagree. In the web-shop path, where the order does not identify the buyer as a known customer, the check happens at the moment the order is accepted — an order whose email matches the referrer’s own is recorded with no referrer at all, rather than being filtered out later.

One detail of that calculation is worth recording because it is the kind of thing that fails silently. The exclusion has to treat an order with no buyer identity as “not self” explicitly. State the test the obvious way instead, and an order with no identity makes the comparison indeterminate rather than false, so those orders drop out of the totals entirely. A self-referral filter that quietly zeroes everybody’s earnings is worse than none, so the rule names the missing-identity case first.

5.2 Posts are registered and verified independently

A buyer who has posted can register the URL, and the operator checks it without asking the buyer for anything further. The registration is refused immediately if the URL is not HTTPS, or if its host does not match the platform named. It is also refused if the URL is one of GYOTAK’s own pages: the referral landing page and the photo capture page both contain the referral id by construction, so reporting one of them would sail through verification without anything having been posted at all. That case was found and closed; it is the kind of hole a verifier passes rather than catches.

Verification itself runs periodically and is deliberately modest. For X, the public embed endpoint is queried first and the post text searched for the referral id, following shortened links one hop to see where they land. Otherwise the public page is fetched and the body searched. A post that cannot be read at all — a login wall, a page that is only a script shell — is not marked as rejected, because a fetch cannot distinguish “the link is not there” from “we could not see the page.” After a limited number of attempts such a report is marked unverifiable and left for a human. We would rather carry an honest ‘unknown’ than a confident false negative.

5.3 GYOTAK does not write the post

The tool a customer’s assistant calls to prepare a post returns no draft and no template. It returns the order’s facts, the images, a verification link, and three lists: what may be said, what must never be claimed, and what the post must include — the referral URL verbatim, and a clear disclosure that it is a referral link. It ends with an instruction to the assistant saying, in as many words, that GYOTAK does not prescribe the wording and that the text should suit the person writing it.

The prohibitions are specific and unflattering to us, which is the point of having them: the post must not claim that the referral or the order is recorded on chain, must not claim a payment transaction exists for a bank-transfer order, must not present the crypto settlement as running on a production network, must not present the sample verification link as the record of the lot the buyer received, and must not claim the photo is proven authentic or not AI-generated.

Three reasons for refusing to ghostwrite, in increasing order of importance. A text written by the operator and posted under a customer’s name is the operator speaking while appearing not to. Identical drafts across many accounts are detectable, and being detected as coordinated is the exact failure this whole design exists to avoid. And the customer’s own assistant knows the customer — their language, their cooking, what they actually thought of the fish — which is the part we could not supply even if we wanted to.

A post about a meal usually has a photo, and a photo is now the cheapest thing in the world to fabricate. The capture page (implemented, in production) does not try to prove that an image is real. It produces a narrow, checkable record about one specific act of capture, and refuses to say more than that.

Six properties, in the order they occur:

The limit, stated plainly. Social networks re-encode uploaded images. The bytes in the post will not hash to the value that was stamped, and no reader should expect them to. What the record attests is that a file with this hash was captured at this time, from this province, by someone holding a capture link issued to a buyer. It does not attest that the image in the post is that file, that the image is not AI-generated, or that the meal in it is the lot that was bought. The page also cannot prove the file came from the camera rather than the photo library: requesting the camera is a request, and how it is honoured is the platform’s decision, not ours.

We consider that narrowness a feature. The alternative — a badge asserting the photo is genuine — would be a claim we cannot support, on exactly the model of the “verified purchase” badge this line of work exists to replace.

The mechanism described here is not specific to fish, to Midnight, or to X. What it needs is only this: an operator-issued value that exists solely in the hands of the party who performed a real act, published in the same immutable record as that party’s public claim. Several variants follow, disclosed so that the shape is public rather than left to be re-derived.

These variants are disclosed, not built. They are listed because the invention is the pattern, not any one instantiation of it, and because a design disclosure that describes only the version one company happens to have shipped leaves the pattern available to be claimed by someone else.

Implemented and running:

• A referral code is issued automatically when a chat order’s payment is confirmed, for orders placed by an identified customer. Failure to issue one never blocks the payment.
• Referral attribution on the next order is taken from the connection token first; a referrer id passed as a plain argument is accepted only if it resolves to an active referrer.
• The claim records the buyer’s handle, and the referral id present on that connection, as one record per purchase, and is idempotent for purchases already claimed.
• Self-referral is excluded from the earnings calculation and refused at web-shop order acceptance.
• Post URLs can be registered and are verified periodically against the public page; GYOTAK’s own pages are refused at registration.
• The share kit returns facts, prohibitions and required inclusions, and no draft text.
• The capture page produces a hash, a time, a province label and a hiding commitment for the coordinates, stamped on Midnight.
• The v3 binding circuit of § 2 is deployed on Preprod and Mainnet. One real customer order has travelled the whole path, and its referral id is on chain. TR-2026-015 carries the addresses and transactions.

Designed, not implemented:

• The printed insert of § 4, step 4.
• Every variant in § 7.

Disclosed openly — what this does not prove:

• That the handle belongs to the buyer. This is the sharpest limit and we state it first, as TR-2026-015 § 5 does. The v3 binding narrows it and does not close it: a personal connector URL can be shared or leaked, so what the record establishes is that the claim came from a connection holding the buyer’s referral id — not that the account is the buyer. One structural pressure works in our favour and has a hole worth naming: registering someone else’s handle sends the reward to that person, which removes the profit motive but does nothing against a claimant whose aim is impersonation.
• That an id stamped on chain is where rewards go. A referral id is permanent, but its active status is not. Payouts are computed from the operator’s records; reading an id off the chain and paying it is a mistake this record actively invites, and we name it here so that nobody makes it on our behalf.
• That a verified post is an honest post. Verification checks one thing: that the referral id appears in the fetched page. It does not read the text, judge the claims, or notice a post that breaks the prohibitions of § 5.3. A post that cannot be fetched is marked unverifiable, never rejected.
• That the photo in a post is the photo that was captured. Social networks re-encode; hashes will not match (§ 6). Nor does the record establish that an image is not AI-generated, or that the file came from the camera rather than the library.
• That a purchase physically occurred. Unchanged from TR-2026-015: the chain attests that GYOTAK recorded something and has not altered it. An operator determined to publish false records would produce chain data indistinguishable from honest records.
• That repeat bindings prove a repeat customer. They prove repeated payments confirmed by the operator against purchases whose lots resolved. A customer buying through a path that issues no commitment leaves no such trail, and absence of bindings is not absence of purchases.
• Verifiability by a plain chat AI. As in TR-2026-015 § 6, the indexer requires POST. An assistant restricted to URL fetching cannot read contract state and should say so.