Light Speed Transfers

Free until it matters

Anchor transfers — moving a covenant without touching the chain. Seven attacks, four dissolved, and what is left.

Design: Ma An-Zuo. Written up and stress-tested the same day.

    ┌──────────────────────────────────────────────────────┐
    │  BSV — the ANCHOR POINT                              │
    │  a covenant UTXO holding sats, or a token / NFT       │
    └──────┬───────────────────────────────▲───────────────┘
       LOCK│                               │UNLOCK
           ▼                               │ (any current holder)
    ┌──────────────────────────────────────────────────────┐
    │  jetmora — the NON-FORKABLE LOG                      │
    │   A ──sign──▶ B ──sign──▶ C ──sign──▶ D ──sign──▶ E  │
    │   ZERO chain transactions · ZERO fees                │
    └──────────────────────────────────────────────────────┘

Where this came from — a game, not a payments thesis

This design was not reasoned down from first principles about money. It was forced by a game.

grafverse needs items that move: a painted object handed between players, an inventory that travels with a person from one world into another, an asset acquired on the far side of a gate. And the moment you write that requirement down, the chain-per-transfer model is already dead:

Three standing laws collide here, and the collision is the brief: play free, touch chain only when it matters — a game that charges to hand someone a sword is not free, whatever the download costs. Inventory is player state, and it travels — so it cannot live in any one world's database. Owned, not claimed — so it cannot be a row in a server either.

Which is also why this paper says what it says about scale. A billion players trading pennies-worth of paint is not a stress test invented to sound impressive — it is the ordinary load, and any design needing a global ledger to carry it has already lost.

The covenant is the token

Not "a covenant that holds a token". There is no token layer. The covenant is the asset. That deletes a whole tier:

And the asset becomes self-describing. The covenant's Script says what it is and what it may do — and because it compiled from BASIC, it reads back through unbasic. A buyer doesn't consult a registry or trust a metadata server. They decompile the thing they're buying.

The decomposition

It separates two things every other scheme welds together:

The real attack — stealing the tip onto a parallel log

The design above says "the log provides uniqueness." It never says which log. That is the whole attack.

                     ┌── log L1 ──▶ D ──▶ E     "I sold it to D"
 A ──▶ B ──▶ C ──────┤
                     └── log L2 ──▶ X ──▶ Y     "I sold it to X"
                                                 (a log C spun up, or
                                                  a different network)

Both branches are cryptographically perfect. Every signature verifies, both run back to genesis. The covenant can't tell them apart because nothing is wrong with either one.

Why nothing inside the system can fix it

Distributed parties cannot agree which of two valid histories came first without something outside themselves. That's not an engineering gap — it's the impossibility every consensus system exists to solve.

The fix, three parts

1 · The covenant names its anchor chain at genesis, immutably. A transfer anchored anywhere else isn't a transfer of this asset — which settles the different-network attack outright. The system stays chain-agnostic; each asset doesn't.

2 · First anchored wins, by the chain's own ordering. The strongest form makes the anchor a covenant UTXO that must be spent to advance — then uniqueness isn't a policy anyone enforces, it's the UTXO set. Bitcoin has prevented exactly this since 2009.

3 · The buyer waits for the anchor.

The hash-lock proposal

"Use a one-way hash so only jetmora can redeem." Works It kills the attack completely. But look at the price:

Keep the fix, keep the property: jetmora or timeout. Don't make jetmora necessary; make jetmora fast.

unlock =  jetmora co-signs the current head   ← fast path, minutes
       OR holder alone, after N blocks        ← escape hatch

The timeout is what makes it not custody: jetmora can delay you by N blocks, never take and never trap. But see B1 below — the escape hatch as written is broken.

Where the hash genuinely wins

1 · A hash chain makes ordering physically unforgeable. Commit H^n(s); reveal H^(n-k)(s) at sequence k. There's exactly one preimage per link — the log cannot produce two valid values for the same sequence. Not "is punished for it". Cannot.

2 · An HTLC solves the in-flight sale, atomically — and it's the single mechanism for both open problems:

buyer pays into an HTLC locked to H(x)
seller can ONLY claim it by revealing x
revealing x is WHAT COMMITS the transfer in the log

Why there is no ceiling

Asking "how many transactions per second?" imports a chain assumption: that some node validates everything. Here no such node exists or can. A participant verifies only the anchors they hold or are buying.

Say it structurally: "There is no throughput number, because there is no bottleneck to measure. Every participant verifies only what they own." That can't rot and can't be argued down to a benchmark. The chain bounds the doors, not the dancing.

Where it breaks

Adversarial pass, ordered by severity. B1 breaks a fix proposed earlier in this same document.

C signs to D  → goes in the log, legitimate
C signs to X  → parallel log, or no log at all

X waits N blocks, uses THE ESCAPE HATCH — which by
definition does not consult the log.
The covenant sees a flawless chain A→B→C→X and pays out.

The resolution — there is no log service

This isn't a deployment note. It removes the component that every break above attacks.

Four of seven gone, and the two hardest among them. The design got smaller and stronger at once.

What it costs, plainly

Lose your chain, lose your proof. That isn't a flaw to engineer away — it's exactly what "each user is responsible for the custody" means, and it's the same bargain as holding your own keys. The answer to "custody is hard" is better UX, never a custodian.

So: the seller must hand over full history before payment — bind it into the HTLC — and backup is a first-class feature, not an afterthought.

What it doesn't solve

C sells to D.  C also sells to X.
Both hold perfect chains. Neither is anchored.
⇒ Whoever anchors FIRST owns it.

Which means the buyer pays for one anchor when it matters, and nothing for the thousand transfers that don't. Finality is a thing you buy, per transfer, only when the value justifies it — and the scale claim survives because most transfers never anchor.

Is it "peer-to-peer electronic cash"?

Mostly. Say the precise version — it's stronger and can't be laughed off.

That is this design, line for line. A coin is the chain of signatures, held by its owner, passed forward by signing. "The covenant is the token" is that sentence said in Script — and in this one respect it's more faithful to §2 than the modern UTXO model.

But §2's very next paragraph is where it diverges: "the payee can't verify that one of the owners did not double-spend… The only way to confirm the absence of a transaction is to be aware of all transactions." Satoshi's answer was to announce every transaction to everybody.

Cash is denominated, not divisible

Cash has never been divisible — it is denominated. Nobody has ever cut a note in half. They make change.

pay 17:  hand over a 20-anchor
         receive back a 2-anchor and a 1-anchor
         ⇒ THREE independent transfers, each a linear chain

Exactly what the design already does well, three times, in parallel. No new mechanism at all.

"Keeping a copy" — the last problem

The reframe: there is no copy to keep

A secret cannot be handed over. It can only be shared. If transfer meant "give the recipient my key", the sender always keeps a copy and this would be unsolvable.

C does NOT give D anything secret.
D generates D's own keypair. D keeps the private key.
C never sees it. C merely SIGNS: "the next owner is D's pubkey."

The three layers

1 · Structural — nothing secret moves, so the whole problem reduces to double-signing.

2 · Settlement — the anchor UTXO is consumed when spent. Bitcoin has made that impossible to do twice since 2009. Absolute prevention, at the cost of one transaction. Paired with the HTLC, the buyer's money releases only on anchor — so they never pay into a race they haven't already won.

3 · Punishment — make signing twice mathematically self-destructive. This is real cryptography, not a policy:

C pre-commits a one-time nonce point R = k·G for this transfer.
The covenant honours only a transfer signed with THAT R.

sign once  → fine, nothing leaks
sign twice → both signatures share k
           → ANYONE holding both recovers C's private key
           → C's bond is claimable by anyone. Instantly.

You cannot stop C signing twice. You can make it cost C more than the asset is worth, with no trusted party anywhere in the mechanism.

The anchor chain is walkable

The anchors are not isolated dots. They are a linked list.

The anchor advances by spending the previous anchor UTXO — that is the entire uniqueness mechanism. And a spend chain is, by construction, a linked list:

genesis ──▶ anchor 1 ──▶ anchor 2 ──▶ anchor 3 ──▶ … ──▶ tip

each one SPENDS the last. Public. Permanent. Walkable by
anyone, in either direction, with nothing but a block explorer.

The mitigation — and it's cheap

Commit to a hash of the holder, not the holder's key.

anchor commits:  H(holder_pubkey ‖ salt)     ← not the pubkey itself

Why nobody built this

It isn't having a token that costs them. It's that a token forces a shared ledger, a shared ledger forces consensus, and consensus is the bottleneck.

A balance cannot be validated locally. To know whether Alice may spend 5 you need Alice's balance, which depends on every transaction she was ever party to. The moment your design has balances you've signed up for global state, and everything after that is damage control.

The honest — and more interesting — version

The mainstream went the shared-ledger route for a reason that was never technical. A sidechain needs a token to fund itself: to raise the money, reward validators, give the thing a price. And the moment you need a token to have a price, you need a ledger of balances — and you have rebuilt the bottleneck you launched to escape.

Authorship

Recorded precisely, because this document is going on chain for provenance — and because a night spent on unattributed code is a poor night to be vague about attribution.

Ma An-Zuo — the design. All of it.

Every idea here is his, and the sequence matters, because each one made the design smaller:

Claude (Opus 5) — the writing, and the adversarial pass

• Wrote the document — structure, prose, tables, diagrams, and this HTML edition.
• The decomposition — authority / uniqueness / exit as three separable properties.
• Found B1: the "jetmora OR timeout" escape hatch I had proposed an hour earlier was a universal double-spend — and supplied the fix.
• The one-time-nonce punishment mechanism — pre-committed R, so signing twice leaks the key by arithmetic. Verified numerically on real secp256k1 before being written down.
• Prior art — statechains, RGB, payment channels — and the whitepaper §2 framing.

Next step

1. B1 · the escape hatch — has a fix (exit to last anchored state). Apply it.
2. Denominations — pick the ladder (1·2·5·10·20·50·100) and the re-denomination path. No longer a research problem.
3. Finding the tip at scale — now on the critical path.
4. Model anchor frequency — after B1 it's a safety parameter, not a tuning knob.
5. BRC-226 mint for provenance, before any public mention.
6. Prototype in BASIC via compileState; measure by serializing a real spend.