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.

Verify the verifier

A verification tool you cannot verify is just another thing to trust. Two properties make that unnecessary here:

sha256sum verify-cert.js
# v1.3.0 -> 03c2d593e8088fd1e79a2e78f0dd16bf873bc397c1737bd43aa75dd4ac0f0177

The hash of verify-cert.js is listed in the release notes of every release from v1.3.0 on, so the copy you run can be checked against the tag you took it from — and the file is short enough to read in full, which is the better check.

And it runs fully offline: no network call, no telemetry, nothing fetched. The only external input is the --root you pin from the chain. Copy verify-cert.js and a certificate to an air-gapped machine and the verdict is identical.

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:

node reference-implementation/test/run-tests.js
# -> RESULT: 74 passed, 0 failed
``` Use it to run the pipeline yourself and
reproduce the published roots from public chain data.

## License

MIT © ORDnet / ODNCA