Verifiable without disclosure: anchored ledgers for organisational spending and pre-incorporation equity

An expense management platform stores claims, approvals and its own audit log in one database under one administrator. That administrator — or anyone who obtains their credentials — can alter an amount, substitute an approver, or backdate a submission, and then alter the log that would have recorded the change. The log is not independent evidence. It is another table in the same database.

This is not a hypothetical failure. The Association of Certified Fraud Examiners consistently finds expense reimbursement and billing schemes among the most common categories of asset misappropriation, with internal control override among the most common enablers. The control that fails is rarely the rule. It is the record.

A structurally identical problem exists one layer earlier in a company’s life. Before incorporation there is no register of members. Founders agree a split verbally or in a chat thread, and that agreement carries no timestamp, no signature, and no independent custodian. When it is disputed — commonly two to three years later, after value has accrued — the available evidence is a screenshot.

Both problems share a shape: a record whose integrity depends on the good faith of whoever holds it. This paper asks what the minimum intervention is that removes that dependence, and argues that it is considerably smaller than “put it on a blockchain”.

The pattern this work builds on is anchoring: committing a cryptographic digest of off-chain data to a public ledger so that the data’s existence and state at a point in time become independently checkable, without the data itself being published.

Certificate Transparency (RFC 6962) established the template at scale, using append-only Merkle logs to make certificate issuance publicly auditable while keeping the log servers untrusted. OpenTimestamps applies the same idea to arbitrary documents over Bitcoin, aggregating many digests into one on-chain commitment to amortise cost. Solana Pay contributes a smaller but load-bearing technique used here: a “reference” public key attached to a transaction as a read-only, non-signer account purely so the transaction can later be located by address.

Where this work differs from existing blockchain accounting proposals is in what it declines to put on chain. Systems that record transactions themselves inherit the confidentiality problem and typically respond with permissioned chains, which reintroduces the trusted operator the design was meant to remove. By committing only a root, this design keeps a permissionless public chain and full confidentiality, at the cost of requiring the data holder to supply the entries for any verification.

The equity layer follows Y Combinator’s post-money SAFE, whose defining property is that an investor’s percentage is knowable on the day of signing, because dilution from other SAFEs is borne by founders rather than shared among investors.

The system was built to satisfy five requirements simultaneously:

1. Attributable. Every entry names who authorised it, provably rather than by assertion.
2. Tamper-evident. Any alteration is detectable by a third party who was not present when the record was made.
3. Independently verifiable. Without trusting the application, its authors, or its host.
4. Confidential. Commercially sensitive detail is never published.
5. Usable. By a four-person team with no compliance function.

Requirement 4 is the one most blockchain proposals fail, and requirements 3 and 4 are in apparent tension: independent verification normally implies disclosure. Resolving that tension is the technical contribution of this work.

The resolution is a division of labour. The requirement that genuinely needs a blockchain is a public, adversarial timestamp: a commitment that cannot be backdated, cannot be selectively withdrawn, and is witnessed by parties with no relationship to the organisation. Databases cannot provide this, and neither can a single trusted timestamping authority, which is one point of trust and one point of coercion.

What is not needed is on-chain storage, on-chain computation, or a token. Each adds cost, latency and disclosure without addressing the requirement.

interface LedgerEvent {
  seq: number;        // contiguous from 0
  ts: number;         // unix ms
  type: EventType;    // "expense.approved", "equity.granted", ...
  actor: string;      // Solana address, base58
  payload: object;    // type-specific
  prevHash: string;   // hash of event seq-1
  hash: string;       // SHA-256 over all of the above, canonicalised
  sig?: string;       // ed25519 over `hash`, by `actor`
  anchor?: AnchorRef; // set once covered by a published root
}

The system is a client-rendered Next.js application in TypeScript, with a Solana devnet deployment and Phantom as the wallet. Cryptography uses a synchronous SHA-256 implementation rather than crypto.subtle, because the audit view re-derives and verifies the entire chain during render and an asynchronous digest would force every reducer and every proof into a promise chain.

Two implementation decisions carry disproportionate weight. First, policy findings are evaluated at submission and frozen into the entry; re-evaluating historic expenses against current policy would silently erase findings that were real when made. Second, an expense stores the amount as incurred, its currency, the conversion rate and the provenance of that rate. Storing only a converted figure makes the number irreproducible; storing the rate without its source is barely better, since a later reader cannot tell whether it was a live quote, a reference table, or a typed override.

This matters far more for crypto than for fiat, and the reason is structural rather than merely practical. Because the ledger is hash-chained, a figure derived from a live price at read time could never participate in the hash: exclude it and the chain verifies a record omitting the amounts; include it and the hash breaks on the next price tick. There is no version of read-time pricing that survives a content-addressed ledger. Freezing the rate at write is what makes the chain verifiable at all.

/app/expensesdevnet

Expense · approved

Jared Dunn

IndiGo · Travel · 104 days ago

Approved

$311.75

from ₹26,000 INR

1 USD = 83.40 INR · frozen at submission

Signed off byDinesh · Richard

9f2c41a8…d695e7receipt hashed

/app/equitydevnet

Pied Piper · fully diluted

9,000,000 shares100.00%

• Richard Hendricks4,000,000 common44.44%

  Fully vested

• Bertram Gilfoyle2,500,000 common27.78%

  Fully vested

• Dinesh Chugtai1,500,000 common16.67%

  62% vested

• Option pool1,000,000 reserved · 190,000 granted11.11%

Jared holds 150,000 ISOs at $0.25. Pre-cliff, so nothing has vested yet.

Identity is the wallet, and nothing else. There is no account to create and no directory to consult, so a member is an address plus whatever name the ledger recorded when they were added. Faces are generated locally from the address rather than fetched from an avatar host, because requesting an image per member would disclose the organisation’s entire membership to a third party on every page load — a leak that would be invisible, permanent, and entirely gratuitous.

An MCP server ships alongside the application so that AI agents can audit a ledger. It operates on an exported bundle plus public chain data, because there is no API to call — and it deliberately re-implements the verification logic rather than importing the application’s own, since a checker that borrows the code it is checking would faithfully reproduce that code’s bugs and prove nothing.

The security argument reduces to one function. Re-derive every hash from the stored fields; if a row was edited, its recomputed digest diverges, and because each event commits to its predecessor, every later link breaks with it. An adversary must therefore rewrite the entire suffix — and any part of that suffix already covered by a published root is contradicted by a public commitment they cannot alter.

The final two rows are the honest boundary of the entire approach and of every integrity system: the design proves that a record was not altered after the fact. It cannot prove the record was true when written. A fabricated receipt hashes as cleanly as a real one.

The central claim — that tampering is detectable — is made falsifiable in the product itself. The audit view includes a tamper simulator that edits a stored amount while leaving the stored hash untouched, exactly as an adversary with storage access would. The integrity check then fails at that entry and at every entry after it, and a restore control reverses it. A demonstration a sceptic can run in ten seconds is stronger evidence than any assertion in this paper.

Verification is fully independent. Given an exported bundle, a third party can recompute every hash, confirm every predecessor link, rebuild each Merkle tree, fetch each anchoring transaction from any public RPC and compare roots, verify every signature against its actor’s address, and replay the log to re-derive the cap table and totals. Every export includes the raw log for exactly this purpose: a summary that cannot be recomputed is a claim, not an audit.

Cost is negligible. One anchoring transaction carries a base fee of 5,000 lamports regardless of how many entries the root covers, so ten thousand entries anchored in batches cost a fraction of a cent in aggregate. Read cost is one RPC call per thousand transactions, because the memo text is returned inline with the signature listing.

1. Anchoring frequency is a policy choice. Between anchors the ledger is only tamper-evident to a party holding a prior copy. Shorter intervals cost more transactions.
2. Availability is the user’s responsibility. No backend means no server-side backup. Encrypted export and folder sync mitigate this; they do not eliminate it.
3. Rate sources. Live rates are fetched from a public endpoint with a static table as an offline fallback. Production use should read an oracle at the instant of transfer and record the value used.
4. Single-signature treasury. Reimbursement is presently one signature; a real treasury belongs behind a multisig.
5. Same-slot ordering. Solana’s signature listing does not expose transaction index, so intra-slot ordering is not reliably readable from the RPC. The design does not depend on it, because ordering is carried by the sequence number and predecessor hash within the payload.
6. Integrity is not truth. The system proves a record was not altered. It cannot establish that it was accurate when created.

Four directions follow naturally. A multisig treasury would remove the single-signature reimbursement path. Zero-knowledge policy proofs would allow a company to prove that an expense satisfied policy without revealing the amount, enabling public compliance attestation over private figures. Encrypted on-chain messaging, using X25519 keys derived from wallet signatures, would let invitations and countersignatures deliver themselves over the chain already being used for anchoring, removing the last manually-carried step in the peer-to-peer flows. Finally, formal verification of the apportionment and SAFE conversion arithmetic would raise confidence in the two places where an error is silent and expensive.

The contribution here is not that a blockchain was used, but that it was used for exactly one thing: an unforgeable, non-disclosing, publicly witnessed timestamp. Ordering, attribution, policy enforcement and confidentiality are handled by considerably cheaper mechanisms that require no publication — hash chains, ed25519 signatures, and Merkle proofs.

That division is what makes the result deployable. A team obtains a spending record an outsider can verify and an ownership record that exists before the company does, without publishing their salaries, trusting a vendor, or running a server. The cost is that verification requires the data holder’s cooperation — they must supply the entries — which is a materially weaker property than a fully public ledger, and an honest account of this design must say so.