Conformance¶
Two implementations given the same inputs must give byte-identical output: the same hash, the same address, the same signature. vectors.json is that contract. A backend in Python, Rust, Go or Swift is compatible with Omxus when it reproduces every value in it.
Download it, compute each case with your own code, compare. Green on every case means a person who signs in on your backend gets the same address they get everywhere else.
What the vectors cover¶
Nine checks in four groups. Inputs and outputs are hex unless noted.
| Group | Cases | Input | Output |
|---|---|---|---|
keccak256 |
4 | bytes (empty, abc, omxus, 32 zero bytes) |
Keccak-256 digest |
identity |
2 | name, date of birth, words (plain text) | address, mnemonic, privateKey |
herHash |
1 | address + three voucher addresses | 0x + digest |
sign |
1 (2 checks) | private key + message | msgHash, then r, s, recovery |
What each one must do¶
keccak256. Ethereum's Keccak-256: pad byte 0x01, last byte | 0x80, rate 136 bytes. Not SHA3-256, whose pad byte is 0x06. Libraries: Rust tiny-keccak (Keccak::v256), Python eth-hash or pycryptodome (keccak.new(digest_bits=256)), Go sha3.NewLegacyKeccak256.
identity. Clean the inputs, join them with single spaces into the mnemonic string, then BIP-39 seed (PBKDF2-SHA512, 2048 rounds, salt mnemonic), then BIP-32 path m/44'/60'/0'/0/0, then the Ethereum address of that key (lowercase in the vectors). The cleaning rules are on How identity is derived: name and words are lowercased with spaces collapsed; the date is only trimmed, so 1815-12-10 and 10/12/1815 give different people.
herHash. Lowercase the address and the three vouchers, sort the vouchers, join as address|v1|v2|v3, SHA-256 the UTF-8 bytes. SHA-256, not Keccak. See Vouching.
sign. msgHash = keccak256 of the message bytes. Then secp256k1 over msgHash, deterministic nonce (RFC 6979), low-S. r and s are 64 hex characters, zero-padded; recovery is 0 or 1.
A check loop¶
Port this to your language. It reads the file and checks the keccak group, the one most implementations get wrong first; add the other three groups with your own identity, HER and signing code.
import json
from Crypto.Hash import keccak # pip install pycryptodome
cases = json.load(open("vectors.json"))["cases"]
for c in cases["keccak256"]:
got = keccak.new(digest_bits=256, data=bytes.fromhex(c["input"])).hexdigest()
print("PASS" if got == c["output"] else "FAIL", c["note"])
Tested 30 Oct 2026: 4 passed.
What the vectors prove, and what they don't¶
Our engine generated these vectors
On their own they prove an implementation agrees with ours, not that ours is right. No case in the file carries a verified mark. The outside check is the keccak group alone: the Keccak-256 of the empty string and of abc match the published constants, and a from-spec Keccak written separately matches ours at 135, 136, 137 and 500 bytes, where padding bugs show.
Checked 30 Oct 2026: the engine auth.omxus.com runs today reproduces all nine values (keccak 4, identity 2, HER 1, message hash 1, signature 1).
Where the file comes from¶
The vectors live in the Omxus protocol repository (protocol/vectors.json, version 1, last changed 25 Oct 2026). That repository is not public yet; the copy on this page is the same file. If the inputs or a scheme ever change, the version goes up and every implementation certifies again.