ODNCA-verify

Don't trust us — recompute us.

Offline verification tooling for ODNCA Certificates of Ownership: prove that a web3 name (earthlog.web3) was held by a given wallet at a committed block height, against a merkle root anchored on the BSV blockchain — with no API, no account, and no trust in ODNCA required.

The genesis commitment of the SNS namespace is on-chain:

txid     b65b03f04fd20b97330fc7bbcaa2a706926f32e39f59716f40196368e60c6ec9
height   961546 · names 651,482
root     2e85f7a2c4a552901e21e644f56534d97dd5c3bc3515700691120d3855f80cbb
ruleset  e2e144006f97e99c18e6cfe55065896a2140dccdc1a8f0c3fc62e0f0d7d7c922

Read it from the chain rather than from this page — that is the whole point of the exercise. The full commitment chain, newest last:

curl -s https://odnca.org/commits

The same root is in the OP_RETURN of the transaction above, readable in any block explorer, and ruleset is the sha256 of the frozen ruleset/RULESET-SNS-COMMIT-1.md in this repository — check it yourself with sha256sum.

Every subsequent commit links to its predecessor (prev), so the commitment history is an auditable chain of its own — five commits so far, from height 961546 to 961919, every one signed with the same frozen ruleset. Full design: ODNCA-STD-004 §6 in ODNCA-standards.

Verify a certificate

node verify-cert.js <certificate.json> --root <64-hex root> [--key commit-key.pem]

--root is required and must come from outside the certificate — the commitment root as it appears in the on-chain commit inscription (cert.commit_txid), or from https://odnca.org/commits. A certificate carries its own leaf, path and root in one file, so a verifier that trusted the file's own root would "verify" any file its author cared to write. Pinning the root against the chain is what makes the proof mean something.

The exit code covers every check that ran: 0 only when the merkle path folds to the pinned root and, if --key is given, the API signature verifies. Any mismatch exits non-zero, so verify-cert.js … && accept is safe.

Get a certificate for any name at https://odnca.org/proof/<name>.<tld>, the committed roots at https://odnca.org/commits, and the current API signing key at https://odnca.org/commit-key.

Example, pinning the root straight from the chain-backed commits endpoint:

ROOT=$(curl -s https://odnca.org/commits | jq -r '.commits[-1].root')
node verify-cert.js cert.json --root "$ROOT" --key <(curl -s https://odnca.org/commit-key)

The verifier checks, fully offline:

1. Merkle path — the certificate's leaf folds through its path to the committed root (domain-separated SHA-256, 0x00 leaves / 0x01 nodes).
2. API signature — the certificate JSON is signed by the published proof-API key (when --key is given).

The final step is deliberately manual: confirm on any node or explorer that the commit inscription (commit_txid) exists on-chain and was posted by the published commitment wallet — or re-derive the root yourself by running the published ruleset against the chain at the certificate's height.

The frozen ruleset

Each commit inscription embeds the SHA-256 of the exact ruleset under which its state was computed (ruleset/RULESET-SNS-COMMIT-1.md — included in this repository, sha256 e2e144006f97e99c18e6cfe55065896a2140dccdc1a8f0c3fc62e0f0d7d7c922, byte-identical to the copy at https://odnca.org/transparency). A registry is its rules; change the rules and it is demonstrably a different namespace.

Reference implementation

reference-implementation/ contains the complete commitment service: state export, merkle tree builder, commit chain, proof/certificate server, and the reference verifier — 74 tests, zero dependencies, plain Node ≥ 18. Use it to run the pipeline yourself and reproduce the published roots from public chain data.

License

MIT © ORDnet / ODNCA