How ₭ KRAY.NETWORK works

KRAY seals blocks every few seconds so the network feels instant, then compiles everything that happened into a single 32-byte number and commits it to Bitcoin. Verify that one number and you have verified the whole network — every balance, every star, every inscription, every vote.

It is the Lightning idea applied to accounting: thousands of actions live and final for their users, consolidated periodically into one settlement the strongest chain on earth witnesses. A backlog costs O(1), never O(n) — one anchor seals everything accumulated since the last.

What it is not: a contract virtual machine. KRAY seals what happened; it does not run programs as consensus. That is why it has no reentrancy, no gas attacks and no VM bugs — the three families that stole the most money in this industry. Inscriptions can still compose and render (see recursion), but that happens in your browser, never in the state.

1. Connect your KrayWallet. Your KRAY account is your Bitcoin taproot address — the same key you already hold. Nothing is created, nothing is registered.
2. Donate to mint ₭. Sacrifice real satoshis — destroyed forever at a burn address that belongs to nobody (provably: it is a hash of Bitcoin's own generator) — and mint one ₭ per satoshi, capped at the live deficit. The same donation output seals the whole network onto Bitcoin: your donation IS the anchor. This is the only way ₭ enters the world.
3. Write your stars. Burn one ₭ and a permanent, numbered star is born, carrying your inscription or baptism — text, art, images, audio, video, code — sealed byte-exact forever.
4. Prove it to anyone. Take a ~3 KB receipt for any action and verify it offline against the commitment on Bitcoin. No node, no RPC, no trust.
5. Be a guardian — if you want. Bitcoin and Ordinals make you sync for days before you may help. Here the first door is a browser tab. Pick light or a full node →

The canonical text lives in docs/AXIOMS.md in the repository, and it is the file to read before proposing any change.

There is no signup. Your taproot address is your identity, your balance, your inscriptions and your reputation. On mainnet it is byte-for-byte the same bc1p… address your Bitcoin wallet shows; on the development network it is the same key with a bcrt1p… prefix.

Every action you take is a BIP-340 Schnorr signature over a canonical message — the same curve and the same signature scheme Bitcoin taproot uses. The node verifies it and never sees a key. Each action type has its own domain-separated message, so a signature for one purpose can never be replayed as another.

Reading is public — the chain belongs to everyone. Only acting requires identity.

₭ is never printed on a clock, and nothing was ever pre-mined. The only way a single ₭ enters the world is proof-of-burn: sacrifice real satoshis — destroyed forever at an address whose private key exists for nobody — and mint one ₭ per satoshi, capped at the live deficit. The sats are the proof, so donating needs no signature at all. And the same output that destroys your sats seals the entire network state onto Bitcoin (pay-to-contract): your donation is the anchor, free, in the same transaction.

1. Open Donate and connect your KrayWallet — your taproot address is where the freshly minted ₭ lands.
2. Choose how many satoshis to sacrifice. Your wallet signs one ordinary Bitcoin transaction: the sats go to the burn address that carries the current network root; an OP_RETURN commits you as the donor.
3. Once it confirms, the node SPV-proves the transaction and mints — one ₭ per satoshi, capped at 10,000 per mint, credited once per outpoint, forever.

The burn address belongs to nobody — and you can prove it

The burn key is not a wallet anyone made. It is SHA-256 of Bitcoin's own generator point — the BIP-341 "nothing-up-my-sleeve" constant the whole taproot ecosystem relies on — tweaked by the network state your donation seals. Spending from it would require the discrete logarithm of a hash output, which no one has and no one ever will. Recompute the entire chain in your own browser at /burn — The Burn Proof, or from the repo: node apps/kray-net/burn-verify.mjs <block> <root>. Not one number in the chain was chosen by a human.

The 10,000-sat per-mint cap

The supply has no ceiling — ₭ grows only with real satoshis burned, and the star-inscription burn consumes it back, so the money supply breathes with actual use. What is capped is a single mint: one donation mints at most 10,000 ₭. This is not a supply limit — it is an anti-whale limit. To mint more you make more donations, and each is its own Bitcoin transaction (a real fee) and its own network anchor. Because the scarce resource is Bitcoin transactions, not addresses, splitting across a thousand identities buys nothing — a whale is throttled, taxed, and made to feed the network. Timeless in ₭ terms, and self-strengthening in real terms: as Bitcoin appreciates, burning 10,000 sats is a larger sacrifice, so the bar rises on its own. The cap is a hardcoded constant enforced in the consensus reducer — no node, not even its own operator writing straight to its journal, can mint more (proven in src/test/mint-cap.test.ts).

To inscribe is to burn: one ₭ is consumed and that pure ₭ becomes a permanent star, numbered by creation order, with your content tattooed onto it forever. Every act also pays the eternal 1-₭ fee in pure fungible ₭ — never from a star. Four kinds, all from the same studio on the explorer or in your profile:

Where each one lives

Three identities, and they are not the same thing

Confusing them is easy, so the explorer names each one wherever it appears.

So the same content can never be written twice anywhere, the same star can never be written twice at all, and the inscription id lets you point at one act of writing without pointing at the bytes or the place.

The rules that make it permanent

• The commitment is sha256 of the exact bytes. Re-hash the served file and it matches what the chain sealed. Nothing else is judged — any file type is welcome.
• No re-inscription. One star holds exactly one inscription, forever. A second attempt is refused (and, if forced into a journal, recorded as cursed — history, never a tattoo).
• Content is byte-unique universe-wide. Identical bytes can be inscribed once. First writer wins, settled by journal order.
• Lineage. An inscription may declare a parent — a written star you own — and constellations grow from it. The family tree is committed into the anchored root.
• A star is born from fire. Burning one ₭ creates it; it is non-fungible and can never be spent as money (A5).

An inscription can pull other inscriptions: a page can import a library inscribed on another star, an artwork can read the current block height, a collection can share one traits file. This happens when your browser renders the piece — the chain state never changes because of it.

The recursion rail

<!-- an artwork that imports a library inscribed on another star -->
<script type="module">
  const {palette} = await import("/content/<the library's sha256>")
  const height = await (await fetch("/r/blockheight")).text()
  const root   = await (await fetch("/r/cascaderoot")).text()
  // draw something that could only exist at this moment in this network
</script>

A baptism gives a star a name — unique in the whole universe, permanent, and never renameable, not even by its owner. Humanity writes the atlas; the network only records it.

This is enforced in two independent places: at the signed gate, and inside the reducer itself, so even an event forced directly into a journal arrives cursed instead of registering. Genuinely different letters remain free: José ≠ Jose, bôb ≠ bob.

The fee is always additional: sending N ₭ costs N + 1, and the 1 KRAY is a separate fee in pure fungible ₭ — a star never pays its own fee. It is never deducted from what you sent.

A rune lives on Bitcoin L1: its etch is its passport, a vault address holds its reserves. Its day-to-day accounting between users — credits, drops, claims, receipts — normally lives in a private database nobody can verify. Bridge it here and that accounting seals into the cascade root, while deposits and withdrawals settle through your own vault.

1. Open your profile at /u/<your address> and find Your rune · the bridge.
2. Enter the rune's spaced name (e.g. KRILL•FREE), its etch coordinates (block:tx), and the taproot vault holding your reserves.
3. Sign the link with the wallet that owns the address. One rune, one owner — the first linker holds it.

When a mainnet ord mirror is reachable, the etch is verified live against Bitcoin and the card shows verified; away from it, the card honestly says the passport is pending rather than inventing one. The solvency law is the same one KRAY•SPACE runs on: reserves ≥ Σ L2, provable forever.

Writes require a taproot address of the running network; anything else is refused with 401 before reaching a handler. Every client is rate-limited; the machine running the node is not throttled against itself.

Each subsystem compiles its whole state into one merkle root. Those roots are domain-separated — a hash from one can never be replayed as another's — ordered fixed, and merkled again into the single number Bitcoin seals.

Every node compiles the identical root from its own journal. Nothing the network mints stays outside it.

Fast blocks seal locally at their own pace. The consolidated cascade root — which already carries every fast block since the last seal — is then committed to Bitcoin. The commitment is 49 bytes, and it is human-readable on any Bitcoin explorer whether it rides a donation's own output or a standalone OP_RETURN:

OP_RETURN  PUSH(49)  "KRAY.NETWORK"  version  blockNumber  cascadeRoot
           0x31      12 bytes ASCII  1 byte   4 bytes BE  32 bytes

There are two shapes the fork-choice weighs identically — same Bitcoin proof-of-work, same refutation of a fabricated root. The default and common one is invisible: a burn donation pays a taproot output tweaked by the root (pay-to-contract), so the sats you destroy also seal the network, with no OP_RETURN and no separate transaction. The explorer just sees an ordinary taproot spend. The KRAY.NETWORK OP_RETURN above is the same commitment in its readable form, used by the guardian backstop.

Who pays for it

In the common case, nobody: every donation carries the anchor for free (§15b). For a quiet stretch with no donations, any address may register a signed standing offer of sats, and when a seal is due the payer is drawn with an unbiasable beacon — the triggering Bitcoin block hash itself, so anyone recomputes the draw and no one can rig it. If the pool is empty the chain keeps running and the seal stays pending: the instant a volunteer appears, one anchor seals everything accumulated. A drawn payer who fails is excluded and the job re-drawn; nothing is ever lost. Only a confirmed anchor with the right root earns the reward — paid from the fee pool, capped at what it holds — so a fake volunteer gains nothing. The privileged operator that used to write these seals is retired (opt-in only).

Ask the node for a receipt for any sealed action and you get a self-contained bundle that proves it all the way down:

The verifier is a pure function — no node, no network, no clock. It recomputes the event's hash from the event's own body first, so editing any field (an amount, a recipient, a timestamp) collapses the proof. Pass it the root you read from Bitcoin and the last link closes.

GET /api/kraynet/receipt/<seq>      → the bundle (save it anywhere)
verifyReceipt(receipt, onChainRoot)  → step-by-step verdict

This is the thing a high-throughput chain structurally cannot hand you: there, verifying one transaction means trusting an RPC provider or running a datacenter node. Here, mathematics answers.

First, the default: a burn donation seals the current network root inside its own output (pay-to-contract) — anchoring rides the sats the donor already sacrifices, costs nothing extra, and depends on no one. While donations flow, the network anchors itself.

Standalone OP_RETURN seals remain open to anyone as a backstop. Any address may register a standing offer of satoshis from its profile — a signed declaration, so nobody can enrol another address or inflate another's offer. When a seal is due, the payer is drawn from the triggering Bitcoin block hash: an unbiasable beacon that costs real proof-of-work to influence, through a pure function anyone recomputes. Offering more never buys influence — only a fair chance, and the ₭ reward that follows a confirmed anchor, proportional to the sats actually spent.

What a payer cannot do

• They cannot choose what is sealed. The cascade root is each node's own computation from its own journal. The payer never supplies it; the transaction is built around the root the network already agreed on.
• A wrong OP_RETURN is not an anchor. Garbage, a lookalike tag, or another version does not decode at all; a well-formed commitment carrying a fabricated root is compared against the root every node computed and simply does not match. It seals nothing and earns nothing — money spent for zero.
• They cannot claim a reward they did not earn. Zero or negative sats, a fabricated txid, a root that is not the pending one, or a second claim on a settled job are all refused.
• They cannot hurt the network by refusing. A drawn payer who does not pay is excluded and the job re-drawn. The seal waits, the chain keeps beating, and the backlog stays O(1) — one anchor still seals everything accumulated.

The auditor's rule: which anchor is canonical

Bitcoin accepts an OP_RETURN from anyone, so a stranger may publish a well-formed KRAY.NETWORK commitment carrying a fabricated root. That is not a weakness to be patched away — it is why verification never trusts a transaction handed to you. Two rules settle it, and both are things you check yourself:

1. Recompute, never accept. A root is only meaningful if your own replay of the journal produces it. A fabricated root cannot be reproduced from the real history, and a fabricated history cannot reproduce the roots already anchored before it.
2. Earliest confirmed wins. The canonical anchor for a height is the first one confirmed on Bitcoin whose root your replay reproduces. Nobody can back-date a Bitcoin confirmation, so a story invented later can never displace one Bitcoin already witnessed.

This is the same discipline that makes the node halt on a rewritten history: the promises already witnessed are fixed points, and everything must agree with them.

Tamper-evidence alone is not enough — a node whose operator rewrote history would happily serve the new story. So the node is held to its own promises.

Every anchor is recorded durably and hash-chained: at block H, the history was exactly this. A block's hash is a function of every event before it. So the check is exact and costs nothing: does block H still hash to the chain tip that went into the root Bitcoin sealed? If not, someone edited, inserted, removed or reordered the past — and the node halts at boot rather than serve a history Bitcoin contradicts. Anyone can ask for the verdict at GET /api/kraynet/audit.

Deleting that record proves nothing: the roots are on Bitcoin, where nobody can edit them, and a stranger replaying the database recomputes the same comparison.

Every Bitcoin L2 has to answer one question honestly: who can betray you? In a federated peg (Liquid, the FROST family) it is the committee holding a shared vault. In a statechain (Spark) it is a promise that an old key was deleted. In an indexer-L2 the truth is whatever the indexer says. KRAY's answer is nobody — and here is how each layer earns that word.

The anchor has no owner

Committing KRAY's state to Bitcoin used to need one privileged writer paying an OP_RETURN. That writer is now retired. Instead, every burn donation IS the anchor: the output that destroys your sats also seals the network's root, and the fork-choice weighs it with the exact Bitcoin proof-of-work of an operator seal — a fabricated one weighs nothing. In a quiet stretch, any guardian may anchor and be paid from the fee pool by an unbiasable draw off a Bitcoin block hash. And the rate of new ₭ is metered by Bitcoin's own heartbeat: one confirmed seal reopens exactly one mint, once per transaction, forever. Removing the operator removed a party, never a check — every anchor is still SPV-proven and replay-verified. This is the ordinals pattern (anyone commits their own bytes) applied to L2 anchoring; we know of no other L2 that does it.

The whole network re-derives itself — the second node

Because the one root on Bitcoin is a pure function of a single downloadable file (the journal), anyone can run the second node and re-derive everything — every balance, star, rune, the pot, the consumed seals — through the same consensus reducer, trusting this node for nothing. It then re-proves every anchor and every donation from its own bitcoind: a lying server cannot invent a satoshi Bitcoin never saw burned, and a single tampered byte refuses the whole boot. One command: node scripts/kray-follow.mjs --from <this node>. Every follower is a backup that can prove it is the real history, to anyone, with no operator alive.

It survives the death of any node

A read-only mirror serves only the last snapshot that survived every proof — kill the writer and it keeps answering, marked stale, never one unverified byte. And succession is proven, not promised: a new writer boots from a follower's verified copy, replays the inherited history to the byte-exact root, seals it onto Bitcoin as its first act, and the chain lives on. The network outlives the machine it was born on.

Proven by breaking it on purpose

Antifragile is not "it usually works." We murdered the node with kill -9 in the middle of a 500-request storm — the mathematics survived: nothing half-applied, nothing minted twice, every sacrifice still redeemable from Bitcoin. A thousand simultaneous requests with hostile duplicates minted each donation exactly once. A real rune crossed in and out through the vault, cenotaph-refused, credited-once. All of it re-runs as one command, node scripts/gauntlet.mjs --live — the ~861,000-check suite plus the live adversarial gauntlet plus the second node, 7 of 7 — so nothing we built can ever silently regress.

On Bitcoin you download hundreds of gigabytes and wait days. On Ordinals you add indexers on top. That was the tax for being a guardian. KRAY exists so that tax is gone. The heavy consensus lives in the node. Your job, if you want the easy door, is one SHA-256 loop and a signature that cannot move money. Same KrayWallet you already connected. Two roles — never two accounts. Mining is optional on a node; a node does not mine to exist.

How do I choose?

What the light door actually does

A beat is H = SHA-256("kray-core.beat.v1" ‖ beacon ‖ your address ‖ block ‖ nonce) with at least 8 leading zero bits. The Bitcoin block hash is the beacon (you cannot mine ahead), the address is bound into the hash (work cannot be sold), and the submit signature is kray.beat.submit.v1 — the reducer can never read it as a transfer. Payout is linear in proven work, Bitcoin's own hashrate-share rule: a thousand fake names earn exactly what one does. Reward: 1× presence, up to 3× with the atlas.

A phone can take door 1 when Chrome + KrayWallet can reach a node (Android). An iPhone cannot run the extension today. Someone else’s localhost is not yours — the wallet talks to a node on that device, or to a public URL.

This is not mining. The wallet and /validate are always clients. A node is the process that holds the journal (the truth) and the atlas (the bytes of every star), accepts signed acts, and anchors to Bitcoin. You only need this door if you want that database on your own disk.

A · Keep a verified copy of this network

Use this when you already see an explorer in the browser and you want the same history on your machine — to judge it, not to invent a new genesis. Replace the URL with this explorer if it is not localhost:

git clone -b kraynet-v2 https://github.com/tomkray/kray-net.git KRAY-NODE
cd KRAY-NODE
node scripts/kray-follow.mjs --from http://localhost:4477 --dir ./follower

The follower replays the journal through the same reducer and re-proves every anchor against your bitcoind, if you have one. A tampered journal is refused. If the writer dies, this copy can succeed at the byte-exact root.

B · Start a node on your computer (the easy command)

Use this to run the writer yourself. On a fresh machine this is a new chain unless you followed in A first. Install Node.js 24+. Bitcoin Core is optional.

git clone -b kraynet-v2 https://github.com/tomkray/kray-net.git KRAY-NODE
cd KRAY-NODE
node scripts/testnode.mjs          # → http://localhost:4477 — one command

Then: open that URL, install KrayWallet, turn DevNet on, open the KRAYNET tab (it talks to localhost:4477 on this computer). You can mine from /validate on top — optional. The database lives in a gitignored data folder; it never leaves the machine.

The same binary without the exam-bench shortcuts:

node apps/kray-net/server.mjs      # same explorer, same port

C · Also mine, headless (picks light vs master for you)

KRAY_MINER_SK=<your-64-hex-key> node scripts/guardian.mjs http://localhost:4477

It measures cores, RAM and free disk, asks the node how big the atlas is, and starts as light (1×) or master (up to 3×). Generate a key with openssl rand -hex 32 only for a bench identity — for real earning, use the key that matches your wallet.

The longer recipe (devnet + proofs)

# 1 · the mathematics needs no infrastructure at all
cd apps/kray-core && npm install
npm run test:fast              # the full hermetic suite
node ../../scripts/gauntlet.mjs# one command re-proves the whole idea

# 2 · the isolated Bitcoin devnet the anchors go to
node scripts/devnet.mjs

# 3 · the network itself
node apps/kray-net/server.mjs        # → http://localhost:4477
node apps/kray-net/btc-heartbeat.mjs # moored to real mainnet pacing

# 4 · public provenance (optional): anchors anyone can read
npm run signet
KRAY_ANCHOR_NET=signet node apps/kray-net/server.mjs

Everything degrades honestly when a piece is missing: no Bitcoin node and anchors show connecting while the chain keeps beating; no mainnet mirror and the passport panels say offline instead of inventing data.

For scale, Bitcoin's own chain is roughly 650 GB after sixteen years. In the expected scenario a KRAY node carries less than a Bitcoin full node.

Content is separable, and this is the structural advantage over inscriptions embedded in blocks: the chain seals a 32-byte commitment while the bytes live in a content-addressed store beside it. A node can verify the entire network holding zero content — the honest floor of participation, roughly 150–400 GB over twenty years. Each node holds whatever content it chooses; archivists hold everything and can prove they do.

What is honestly still open

State is ordered by a single writer today, but the network no longer depends on it: any number of second nodes re-derive the whole root and re-prove every anchor from their own bitcoind (§15b), a read-only mirror keeps serving the last verified truth if the writer dies, and succession to a new writer is proven to the byte-exact root. What is deliberately deferred — pending an external audit and a written design — is live multi-writer ordering, where two writers accept events at once; concurrent-write reordering is a full consensus problem we will not open casually. Until then the guarantee is this history is intact, re-derivable by anyone, and matches Bitcoin. The other named boundaries — ord as the rune/ordinal oracle, the yet-to-come external audit, no mainnet at value — are listed in full in docs/AUDIT-DOSSIER.md, because a system that hides its edges cannot be trusted at its center.

node scripts/gauntlet.mjs        # the whole idea, one command — the hermetic suite (~861,000 checks)
node scripts/gauntlet.mjs --live # + the live adversarial gauntlet + the second node — 7 of 7

npm test                         # the full consensus & unit suite (~861,000 checks)
npm run test:concurrency         # thousands in the same instant, one total order
npm run test:spv                 # SPV proofs re-derived from raw Bitcoin bytes
npm run test:anchor-payer        # the seal payer buys the postage, never the letter
node src/test/mint-cap.test.ts   # the 10,000 cap, every injection vector
node src/test/window-law.test.ts # one confirmed seal → one mint, once per txid, ever

Then read the anchor yourself: take any anchor transaction, extract the 98-hex OP_RETURN payload, decode it, replay the journal to that height, recompute the cascade root, and require byte equality. Bitcoin confirmations on that one transaction are confirmations of the whole KRAY state.

And prove the burn with your own eyes: open /burn — your browser recomputes the burn address from Bitcoin's generator point upward (SHA-256 of G → the BIP-341 NUMS key → the tweak that seals the root → the address), with zero trust in any server. Or from the repo: node apps/kray-net/burn-verify.mjs <block> <root> [network]. If it matches the address a donation paid, those sats are destroyed forever at a key that exists for nobody.

Or verify the whole network at /verify — Verify KRAY Yourself: three proofs your browser runs against independent sources — the keyless burn key from Bitcoin's own math, a donation confirmed directly against Bitcoin (mempool.space, not this node), and the entire journal rebuilt as a SHA-256 chain from the raw bytes. The complete, zero-trust verification is the second node: node scripts/kray-follow.mjs --from <this node>.