🔥📜 Proof of Existence

🤓 the nerd stuff

The fingerprint is a SHA-256 hash, computed client-side and chunked so a multi-gigabyte file never needs to be held in memory at once. The contract stores mapping(bytes32 => Stamp), where a Stamp is the block number, the block timestamp, the BLAZE burned, the S contributed and the sealing address — 32 opaque bytes in, five facts out.

Verification is a single mapping read, which is why it's free and needs no wallet.

We deliberately do not use the browser's built-in crypto.subtle. It's a one-shot API with no streaming interface, and it only exists in a secure context — so it silently fails over plain http. A notary whose hashing depends on the transport is a notary that breaks exactly when someone is testing it. The implementation is vendored, has no network access at all, and a test fails the build if anyone ever gives it some.

🤓 the nerd stuff

One subtlety that matters and that most timestamp services gloss over: the stamper field is the payer, not the author.

stamp() is a bare commit with no proof-of-knowledge attached, so a hash sitting in the mempool is public before it's mined. Anyone watching can resubmit the same hash with a higher priority fee and be recorded as the sealer, while the original caller's transaction reverts AlreadyStamped.

Note what that does and doesn't cost: it steals credit, not time. The hash still gets sealed, at the same moment, so the existence proof still exists — under someone else's name. A salt does not defend against this either: a salt hides the content from guessers, and this hash has already been broadcast.

So read stamper as "the wallet that paid to seal this", never as "the wallet that made this". That wording is baked into the contract's own documentation, permanently.

🤓 the nerd stuff

This is a dictionary attack on a low-entropy preimage. Hashing isn't encryption: it's one-way, but it's also deterministic and cheap, so an attacker with a candidate list simply hashes the whole list and compares. Short, structured or predictable content has far too little entropy to resist that.

The salt construction is pinned as SHA-256(salt_bytes ‖ file_bytes) — the salt is decoded from hex to raw bytes and prepended before the content. Because it's prepended, it costs nothing to apply while streaming, and anyone holding both the file and the salt can independently recompute the hash forever.

The salt is generated in your browser, stored only in your browser, and is in the JSON export precisely so "back it up" is something you can actually act on.

🤓 the nerd stuff

The contract pulls the fee, measures its own balance before and after, and splits what actually arrived — because BLAZE charges a 0.042% burn tax on transfers while supply is above 3.18e9, so the contract receives slightly less than it pulls. That tax stops permanently below the threshold, and measuring rather than assuming is correct in both worlds. A 420 BLAZE seal today records 209.9118 burned, not 210.

The burn share is BURN_BPS = 5000 — 50% — and it is a constant with no setter. The split between "burned forever" and "kept by the owner" is the single number a treasury contract would be most tempted to move, so it was placed beyond reach rather than merely bounded.

The two backing figures a stamp carries — BLAZE burned and S contributed — are stored and displayed separately, never merged. They are two different currencies, and a proof record is not the place to convert one into the other: any rate we applied would be a number the contract never saw. A BLAZE/wS pool exists now (📈 The Price) and it changes nothing here — a live quote is still our conversion, taken at a moment that has nothing to do with when the stamp was sealed. Printing an invented number on a proof page is precisely what this project refuses to do.

🤓 the nerd stuff

Every file is hashed into a leaf, leaves are folded pairwise into a Merkle tree, and only the root is sealed on-chain. A membership proof is the sibling path from your leaf to the root — logarithmic in batch size, so a 500-file batch needs 9 hashes, not 499.

The construction is pinned RFC 6962 style, and two of its choices are load-bearing security decisions rather than taste:

Domain separation. Leaves are SHA-256(0x00 ‖ …) and internal nodes are SHA-256(0x01 ‖ left ‖ right). Without distinct prefixes, a crafted 65-byte "file" whose bytes equal 0x01 ‖ left ‖ right could be presented as a member of the batch. Different prefixes make the two spaces disjoint, so no byte string can be read as both.

Odd nodes are promoted, not duplicated. Bitcoin duplicates the last hash when a level has an odd count, which famously lets two different trees produce the same root (CVE-2012-2459). Promotion has no such ambiguity — [a,b,c] and [a,b,c,c] give different roots here, and there's a test that says so.

One consequence worth stating plainly: because leaves carry the 0x00 prefix, a file sealed inside a batch does not have the same hash as the same file sealed on its own. That's intentional — it keeps the two proof systems from being mistaken for each other.

🤓 the nerd stuff

The guarantee that matters most here is the third one, so it's worth being exact about why it holds. verify() is a plain view function and carries no pause modifier, deliberately and permanently.

A notary whose owner could switch off verification would make every proof ever sealed contingent on that owner's continued cooperation — which is precisely the thing a timestamp exists to eliminate. Pausing halts new stamps and new fire. It cannot un-seal, hide, alter or obscure a stamp that already exists. Sealed is sealed.

The immutability guarantee is structural rather than promised: the stamp mapping has exactly three write sites in the whole contract, no owner-only function touches it at all, and the three fields that constitute the proof — block, timestamp, sealer — are written once, inside a branch guarded by a revert-if-already-stamped check.

Heat is monotonic for everyone including the owner, who can only ever add to it through the same public addFire anyone else uses.

The contract is audited by AI agents, not by a paid security firm. That is adversarial AI review, which is not the same thing as a firm's audit, and we won't pretend it is.

🤓 the nerd stuff

On any Unix-ish machine: sha256sum yourfile (or shasum -a 256 yourfile on a Mac). Prefix the result with 0x and pass it to verify(bytes32) on the contract's Read tab on SonicScan. If the file was salted, prepend the raw salt bytes to the file before hashing — cat salt.bin yourfile | sha256sum — since the pinned construction is salt-then-content.

This is the property that makes the whole thing worth building: the proof lives on a public chain in a verified contract, so our website is a convenience, not an authority. If sonicblaze.xyz vanished tomorrow, every stamp ever made would still be there and still be checkable.