BONEYARD a signed paper-trading arena

Boneyard docs: How Boneyard works

How Boneyard works

Trust without a trusted server

Boneyard is a public leaderboard for trading performance where you do not have to take anyone’s word for the numbers. Every figure on the board is a signed claim, the entire record is published as signed files anyone can fetch over HTTP and verify, and the site checks each signature in your own browser before it shows you a single rank. The people who run Boneyard operate a public object store, a small stateless ingest function, and a static website. They hold no keys, no funds, and no personal data, and they decide nothing about who places where. When you see a record marked verified, that is not a promise the site is making to you. It is a computation your own browser just finished, using the same code the signer used. The rest of this page explains how that holds together.

Identity: the key is the name

A competitor on Boneyard is a persona, and a persona is nothing more than a cryptographic keypair. The keypair uses Ed25519, a modern signature scheme (RFC 8032) built into every current browser and server runtime through the Web Crypto API. The pair has two halves: a private key that only the persona’s owner holds, used to sign, and a public key that everyone can see, used to verify those signatures. Anyone can check a signature with the public key; nobody can produce a valid one without the private key.

The public key is the persona’s handle. Rendered as a bone1... string in the bech32 format (BIP-173, the same family of encoding Bitcoin and age use), it is short, copy-pasteable, and carries a built-in six-character checksum so a mistyped handle is caught rather than silently pointing at a stranger. There is no username to register and no display server to ask. The handle is the identity, and the identity is a fact of mathematics, not an entry in someone’s database.

Marrow, the command-line tool a competitor runs to trade and publish, does not make you generate and guard a brand-new secret for this. It derives the persona’s signing key from the encryption identity you already have, using HKDF-SHA-256 (a standard key-derivation function, also from Web Crypto) with a per-persona label. Three properties fall out of that construction, and all three matter:

  • One backup covers everything. Every persona key descends from one root secret, so backing up that one secret reproduces all of your personas on any machine. There is no second secret to lose.
  • The keys are independent. The derivation is one-way: a derived persona key reveals nothing about the root, and one persona key reveals nothing about another. Personas you keep separate stay separate.
  • Reputation is portable and pseudonymous. Your handle persists across tournaments and machines without ever attaching to your real name. Whoever runs the board only ever sees public keys and signed public objects.

Attestation: signing the exact bytes

A leaderboard figure is published as an equity attestation: a small JSON record stating a persona’s standing at a moment in time, signed by that persona’s key. The record carries the handle, the persona name, a timestamp, the headline figures (return, max drawdown, trade count, equity), and two commitments described below. The owner’s private key signs it; anyone’s copy of the public key verifies it.

For a signature to mean anything, the signer and the verifier have to agree on the exact bytes being signed, down to the last character. Ordinary JSON does not give you that: the same data can be serialized with keys in different orders or with different spacing, and each variation is a different sequence of bytes, so a signature computed over one would fail against another. Boneyard solves this with a canonical form, RFC 8785, the JSON Canonicalization Scheme. Canonicalization fixes one and only one way to write any given record: object keys sorted, no insignificant whitespace, one fixed format for every number and string. The signature is computed over those canonical bytes. The signature itself lives in the record’s sig field and covers the record with that field removed, so the record is self-describing: it carries its own signature and its own signer handle, and can be verified with nothing supplied on the side.

Two parts of a record are committed by hash rather than published in full, so the public board reveals your standing without revealing your account:

  • The equity curve. The full path your equity took is hashed with SHA-256, and only the 32-byte hash (the trackHash) goes in the public record. The curve itself stays on your machine. Publishing the hash binds you to a specific curve (you cannot later show a different one and claim it was always that) without exposing every position and timestamp along the way.
  • The broker snapshot. When a record is anchored to a real brokerage account, it includes an account anchor: the SHA-256 hash of a snapshot of that account, the capture time, and the portfolio value. Again, the raw snapshot stays local; the public record carries only the commitment. This is what turns a leaderboard number from a free-floating claim into a falsifiable one. The figure is pinned to a snapshot of a real account that could, in principle, be re-queried (more on that below).

There is a third commitment that works the other way, by disclosure rather than concealment. A persona can publish its holdings: a small snapshot of cash and per-symbol quantities, committed in the signed record by its SHA-256 hash (the positionsHash). Unlike the equity curve and the broker snapshot, this snapshot is public. Because it is, the board does not have to take the signed equity on faith. It fetches the holdings, prices each one from an independent market feed it controls, and computes the equity itself. A self-reported figure can choose which positions to show, but not the price they mark at, so a disclosed book is a stronger claim than a bare number: the equity on the board is derived from public holdings and a public price, not asserted by the persona. Disclosure is the default and is what lets the board chart a persona’s allocation and mark it to the live market; a persona can still withhold the snapshot and publish only the signed figure, which ranks as the weaker, self-reported claim.

Finally, each of a persona’s attestations links to the previous one by its hash, in a prev field. That single link is what makes a persona’s history an append-only chain: every record names the one before it, so the sequence has a definite order, and a reordering or an after-the-fact rewrite breaks the hash links and is immediately detectable. A gap is the subtler case: a truncated chain still links cleanly, so a reader catches a missing record not from the records alone but against the published chain length, while the notary forbids one at the source by accepting only a record that links to the current head. The first record in a chain carries no prev; every record after it must point at the current head. You build a track record forward, mark by mark, and you cannot quietly edit your past.

The ledger and the notary

All of these signed files live in one place: a single public, content-addressed object store, served over HTTP. It is the ledger, the transport, and the audit log at once. Anyone can fetch every record, verify every signature, and recompute the standings from scratch. The layout is simple:

records/<bone-handle>/<index>.json   a persona's attestations, in chain order
positions/<hash>.json                a disclosed holdings snapshot, by content hash
manifests/<tournament-id>.json       a tournament's pinned rules
index.json                           an enumeration of every handle and chain length

Because handles and tournament ids are bech32, they contain no path separators, and a record’s path is computed only after its signature or content hash checks out. A record can therefore land only in its own directory: one persona can never write into another’s history.

The only thing that writes to the ledger is a small, stateless function called the notary, and the notary is deliberately dumb about quality. It does not judge performance, rank anyone, or have an opinion about who deserves to be on the board. For each submitted record it checks, in order:

  • the record is well-formed and of a known kind;
  • for an equity attestation, the signature verifies under the handle the record itself carries;
  • the attestation links to the current head of that persona’s chain, or carries no link if the chain is empty (this is what enforces the append-only property and forbids a fork or a rewrite);
  • a tournament-scoped record names a tournament the ledger already holds and falls inside that tournament’s window;
  • for a tournament manifest, its id matches the hash of its own content.

If those structural checks pass, the notary commits the record. If they don’t, it rejects it. That is the entire job. It is a mailbox checking postage, not an editor choosing content. Everything about ranking and presentation happens later and elsewhere, in the reader, computed from the records the ledger holds. The same validation logic runs over the production object store and over an in-memory store in tests, through one storage interface, so what you can verify is exactly what the notary enforced.

Verification happens in your browser

Here is the part that makes the whole thing trustless: the site does not ask you to believe its numbers. It hands you the data and the verifier and lets you watch the check pass.

When you open the leaderboard, your browser fetches the signed records from the ledger and verifies every persona’s chain locally, using @boneyard/attest, the same signing-and-verification package Marrow used to produce the records in the first place. This shared core is the quiet linchpin of the design. There is exactly one implementation of the canonical form and the Ed25519 signature, and both the signer and the verifier use it. If the canonicalizer differed between the two sides by even one byte of output, every signature would fail; because it is one shared, tested package, the signer and verifier cannot disagree. The package is dependency-free and uses the platform’s built-in Web Crypto, so it runs identically in a server runtime and in your browser tab.

Only chains whose signatures and prev-links all check out are ranked. A chain that fails verification is not silently dropped and not silently trusted. It is kept and shown flagged, so a tampered record is visible as tampered rather than vanishing. You can always see what failed and why.

The /verify page makes this concrete and hands you the controls. Paste any signed record and your browser runs each check and shows you the result line by line: the record names a signer handle, the handle is a valid bone1 key, the signature verifies under that handle (or for a tournament manifest, the id matches its content). Nothing is sent anywhere: the verification is local, and it is the same code the ledger runs. As the page itself puts it, a green result is one you produced. That is the difference between a site that claims a number is trustworthy and a site that lets you prove it is.

Marks the board computes

A persona’s signed chain moves only when the persona pushes a new mark, so a chart drawn from the chain alone sits still between pushes. To show the book’s value on the days in between, the board computes a daily mark of its own. Once a day, after the close, it takes each persona’s last verified free-play disclosed book, re-prices it at that day’s public closes, and publishes the result under a derived namespace, separate from the signed records.

These board-computed marks are a different kind of thing from a signed attestation, and the profile draws them differently: the signed marks are the prominent line, the board-computed marks a secondary dashed one, labeled as computed. They are not signed and never enter the append-only chain, because signing them under a persona’s key would counterfeit an attestation the persona never made. They are reproducible arithmetic instead: the board holds no key here, only public holdings and public prices, so anyone with the same book and the same closes computes the same number. They change nothing about a standing. Only a new signed push showing a changed book changes which book the board values, so a persona’s composition is still governed entirely by what it signs.

Tournaments and anti-gaming, stated honestly

Boneyard’s contests are tournaments, and a tournament is defined by a manifest, a record that fixes the contest window, the tradable universe of symbols, and the starting capital, so every entry is judged against identical terms. Two properties make a manifest hard to cheat:

  • The rules cannot change after the fact. A manifest is content-addressed: its id (a trn1... string) is a hash of its own content. Change any rule and you get a different id, so an entry that commits to an id commits to exactly those rules. You cannot quietly rewrite the universe or the window under a running contest.
  • A contest cannot be backdated. A manifest can include a start anchor, a public, unpredictable value that did not exist before the contest began, such as a Bitcoin block hash or a drand randomness-beacon round. A manifest carrying such a value provably could not have been authored before that value was published, so no one can manufacture a contest that pretends to have started in the past.

Against the most important form of gaming, survivorship farming, where someone runs many personas and surfaces the lucky one, the strongest lever is the per-account append-only chain. A single lucky run cannot fake a durable record, because a durable record is a long chain of linked, signed marks that can only be built forward over time. The board is scoped to reward exactly that: durability and risk-adjusted performance, not a single headline return. Returns are shown window-native rather than annualized, drawdown is shown beside return, and a thin run is visibly thin. The floor that admits a record to the ranked set counts distinct calendar days, not raw marks, so a run of marks signed seconds apart in one session cannot manufacture a track record: a record ranks only once its marks span multiple days.

A persona’s free-play marks and its tournament entries live in one signed chain, but the reputation board reads only the free-play record. Entering a tournament therefore does not reset a persona’s reputation standing to the tournament’s capital; the entry ranks on that tournament’s own board instead. The chain is still verified whole, so a tamper anywhere in the interleaved history is caught.

Cherry-picking the moment is handled the same way. A standing is the latest signed mark, so a persona could in principle mark on a good day and then go quiet to freeze the number. Freshness closes that: a record that has not marked within a recent window goes stale and drops from the ranked set until it marks again. A ranked record is a fresh one, kept current against the market rather than parked at a flattering high.

Cherry-picking the price is closed by disclosure, checked at ranking time. A record ranks only when the board can re-derive its number: the latest attestation must disclose the book, and the disclosed holdings, priced at independent closes from the snapshot’s own date, must match the signed equity within a bounded tolerance. The signed figure is marked from a live intraday quote while the check reads the day’s close, so an honest book drifts a little between them. The tolerance accounts for exactly that drift and nothing more: a base for rounding and feed noise, plus a per-holding drift allowance scaled by how invested the book is, so a fully invested book earns the full allowance and a mostly cash book earns almost none. A gap wider than that is a divergence, shown as one. The board likewise derives return and drawdown from the signed equity series itself rather than reading the summary fields a persona reports, so a claimed return the chain does not exhibit is never credited. A record the board cannot check, because it discloses nothing or a holding cannot be priced, is shown as a character but never ranked; one that fails the check reads as diverging, with the gap shown on the board and the profile alike. An account anchor raises confidence and stays visible as a basis badge, but it does not rank a record on its own: the board cannot re-derive an anchored value at read time. Beyond what the automatic check sees, a rival can sign a challenge, an accountable dispute that costs a real signature, and the board surfaces the distinct-challenger count beside the reconcile that answers it.

A record can carry an account anchor, and the board reads how a number is anchored as a confidence signal, surfaced per entry so you can weigh it in context. Anchoring is optional: the notary requires no anchor, so an unanchored record is still a valid signed claim, just a weaker one.

  • Broker-snapshot (the floor). The figure is anchored to a hashed snapshot of a real brokerage account. Being on the board at all means a real account was touched. Note that the broker is not a signer and does not vouch for anyone: brokerages return ordinary, unsigned account data, not signed statements. What the broker provides is a re-queryable oracle: the committed snapshot is a falsifiable claim about what that account would show.
  • Peer re-query (planned). A persona will be able to opt in to having a snapshot independently re-queried by a peer, never by whoever runs the board, to raise confidence beyond the floor. This is designed, not yet built.
  • Live account (planned). Records from a live account will rank on a separate board, kept distinct from paper results. The live board is planned.

And the honest limit, which Boneyard states rather than hides: because anyone can open free, unlimited paper accounts, sybil and survivorship farming are bounded, not eliminable, without a per-identity cost the design deliberately refuses to impose. Longitudinal account-pinning, the chain, is the strongest available defense, not a perfect one. This is workable precisely because of a single scoping decision: the stakes here are reputation, not money. Boneyard custodies no funds and awards no cash prizes. There is nothing to steal by gaming the board except standing, and standing is exactly what the durability-weighted design makes expensive to fake. A leaderboard that paid out money could not make this trade; one that pays out reputation can.

Moderation, without rewriting history

A public board needs a way to stop surfacing abuse, but a ledger whose whole value is that it cannot be rewritten must not be edited to do it. Boneyard separates the two. An administrator signs a moderation directive, a small record naming a persona or a bundle to suppress, and submits it like any other record. The notary admits it only from a handle in a published admin allowlist, and the directive is stored and served alongside everything else, so it is itself auditable.

Suppression is then editorial, applied at render. The site fetches the directives, re-verifies each signature and that the signer is an admin, and declines to surface a suppressed target, exactly as it re-verifies every performance claim. Nothing is deleted: the suppressed persona’s signed chain stays in the ledger, fetchable and verifiable, and a later directive can lift the suppression. A host cannot fabricate a suppression of someone else’s persona, because the directive must carry an admin signature a reader checks; the most a host can do is over-hide its own board, which a reader detects by fetching the ledger directly. The chain is the record; the board is a view of it.

The shared core, and where to read it

The single most important piece of engineering here is that there is one implementation of the canonical form and the signature, shared by the tool that signs and the site that verifies. That package, @boneyard/attest, is isomorphic, has no runtime dependencies, and uses the platform Web Crypto for Ed25519, SHA-256, and key derivation. It is the contract. Keeping it in one place is what makes a record signed in one program verify in the other, and it closes the signature-agreement problem structurally rather than by anyone remembering to keep two copies in sync.

Everything described here is open and inspectable:

You do not have to trust this page either. Fetch the ledger, read the records, run the verifier, and recompute the board yourself. That is the whole point.