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).

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
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.

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.

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.

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.