RecruiterLog

The Public Ledger

Every silence is on the record, and you can check it.

Once a hiring record settles, its fingerprint is published to Solana. After that nobody can quietly change it. Not the employer, and not us.

No account, and we never learn that you looked.

One seal a day

What went on chain

Every settled record from the day is folded into a single fingerprint, and that one line is published. This is the most recent one, read live from our own ledger.

Confirmed on Solana mainnet7 September 2026 at 21:00 UTC
Period
2026-09-07
Records
1 sealed under this root
Root
ee0885119c798d763c2930ba6df749aecbb19d25cb69c3c9e9ddbf2afd48ed4f
See it on the Solana explorer →

The mechanism

How one line covers thousands of records

Each record is hashed. Hashes are paired and hashed again, up to a single root. Publishing the root commits to every record underneath it, which is why the cost of sealing a day does not grow with the number of records in it.

01

A record settles

The employer replied, or the clock ran out and they did not. Either way the outcome stops changing.

02

It is hashed with a salt

A fingerprint of the facts, plus 32 random bytes stored beside that record and nowhere else.

03

The day is sealed

Every fingerprint from the day combines into one root, published in a single transaction.

04

Anyone can check

A proof is a handful of hashes. Walk them and you reach the root that is already on the chain.

The hard part

Permanent, and still erasable

A public ledger you cannot delete from sounds incompatible with the right to be forgotten. Here is the way out. Delete a record and watch what happens to everyone else.

Thandi M.proof valid

Junior Developer

Ghosted after 21 days

salt a1cbe50f29436d87

leaf 0f29436d87a1cbe50f29436d

Sipho N.proof valid

Warehouse Supervisor

Replied in 4 days

salt d87a1cbe50f29436

leaf 50f29436d87a1cbe50f29436

Fatima A.proof valid

Bookkeeper

Ghosted after 30 days

salt 0f29436d87a1cbe5

leaf a1cbe50f29436d87a1cbe50f

Johan K.proof valid

Field Technician

Replied in 11 days

salt 36d87a1cbe50f294

leaf f29436d87a1cbe50f29436d8

Four records, one seal. All four proofs check out.

The salt is what makes it work. Without it the leaf is a 32 byte number nobody can tie to a person, and there are more possible salts than there are atoms in the observable universe. The tree itself never changes, so everyone else's proof still holds. It is crypto shredding, borrowed from encrypted storage and pointed at a commitment.

Beyond hiring

The same problem exists wherever deletion and proof collide

Hiring is where we hit it. The pattern is general: any record that must be provably unaltered, about a person who can demand its removal. Open any of them, the collision underneath is always the same shape.

Must be provable

An auditor must be able to show the log was not edited after the fact, sometimes years later.

versus
Must be erasable

A data subject can require their transactions be removed, and the same regime that demands the audit grants that right.

What the seal does. The root stays published and the audit trail stays provable. Deleting one subject's records destroys their salts, so those entries stop referring to anybody, and every other entry still verifies.

Must be provable

An employer checking a qualification a decade later needs to know it is the original and not a later edit.

versus
Must be erasable

The holder may withdraw consent, or a record may be expunged by law.

What the seal does. Withdrawal orphans that one leaf. Every other graduate's credential still checks against the same unchanged root, so one person's erasure never devalues anyone else's proof.

Must be provable

A transparency report is worthless if the platform can quietly revise it once a decision becomes embarrassing.

versus
Must be erasable

The account on the other end of that decision belongs to a person with deletion rights.

What the seal does. Publish the commitment rather than the account. The count and the conduct stay honest without pinning an identity in public permanently.

Must be provable

A certification is only worth something if it cannot be backdated or amended after a failure.

versus
Must be erasable

A supplier who leaves the arrangement expects to take their commercial data with them.

What the seal does. The certification history remains checkable without holding a departed supplier's data hostage as the price of keeping the record intact.

Must be provable

An insurer or an ombudsman needs the history whole, because a claim history with gaps is a claim history with excuses.

versus
Must be erasable

Retention limits eventually require deletion, and the subject can ask sooner.

What the seal does. A retention policy can delete freely. Deletion removes the person from the record without putting a hole in the integrity of everything around it.

Must be provable

Proving a dataset was not altered after the analysis is most of what makes the analysis credible.

versus
Must be erasable

A participant may withdraw at any time, and that right is not negotiable.

What the seal does. Withdrawal removes the participant, not the proof that the remaining data is unaltered. The integrity claim and the consent regime stop being in tension.

Why a chain, and why this one. Anchoring only means something if publishing is cheap enough to do every day without thinking about it. A seal costs a fraction of a cent here, and the cost does not grow with the number of records in the batch. On a chain with real fees this pattern is a budget line. Here it is a rounding error, which is the difference between anchoring everything and anchoring the highlights.

We are not claiming deployments in any of the fields above. We are saying the construction is general, it is published under a licence that lets you take it, and we would rather it were used than admired.

Why we built it

A market where conduct leaves no trace is a market where conduct does not matter

Applying for work is the same everywhere. You send it, you wait, and most of the time you never hear anything again. Not a rejection, not an acknowledgement. Nothing. Multiply that by a few hundred applications and it stops being an inconvenience and starts being a reason to give up.

Employers are rated on culture, pay and perks. They are not rated on whether they reply, because until now nobody was counting. And into that same gap walk the people who are not employers at all: fake recruiters, data harvesters, and the ones who charge a fee for a job that never existed.

The common thread is that none of it leaves a record. So we made it leave one, and then we made the record impossible for us to quietly edit, because a reputation system whose operator can rewrite history is just a rumour with better typography.

For builders

Take it, port it, or try to break it

Everything needed to reimplement this in another language is public, including the fixed vectors to check yourself against.

1. Read the specification

Byte level, enough to reimplement without reading our code. It settles the two things that make Merkle implementations disagree: leaves are sorted by hash, and an odd node is paired with itself rather than promoted.

SPEC.md →CC BY 4.0, so you may quote and adapt it

2. Check your port against ours

Fixed vectors for canonical serialisation, leaf hashing, node hashing and whole trees at the sizes where the odd node rule actually bites. If your version reproduces these, it interoperates.

test/vectors.json →

3. Fetch a real proof

Public and unauthenticated, because a proof only we can pull is not a proof. It returns the exact object that was hashed, the salt, the sibling path, the root and the transaction, so nothing has to be guessed.

GET /api/ledger/proof/{id}

4. Attack the claims

Seven claims written to be falsifiable and six explicit non-claims, plus the three places we are least confident. An adverse finding gets published.

THREAT-MODEL.md →

What is deliberately not open. The hiring platform itself is a commercial product and stays closed. What is open is everything needed to check it, and the construction underneath, which is the part that is useful to anyone else.

Limits

What this does not prove

Anchoring shows that nothing was altered after publication. That is all it shows, and pretending otherwise would make every other claim on this page worth less.

  • Not completeness. Nothing on a chain can show that a record was never withheld from a batch before it was published.
  • Not truth. A record can be wrong and still be correctly sealed. This binds us to what we said, not to reality.
  • Not the identity of the employer. That is a separate check, and it has its own credential.

The full threat model, with seven claims written so they can be attacked, is in the open repository. An independent cryptography review is commissioned and will be published whatever it concludes.

Do not take our word for any of this

Pick any record from the ledger and check it. Every hash is recomputed in your own browser, and the root it is compared against is read from Solana rather than from us.

Verify a record yourself