Whitepaper

1. Abstract

Public blockchains made settlement programmable and verifiable. They also made financial activity permanently legible. Wallet graphs, size, and timing form a continuous record of intent, legible to bots, competitors, counterparties, and anyone with an explorer.

Stablecoins are becoming how businesses and AI agents pay each other, and every one of those payments is public. Gloam makes them private, and lets the payer prove exactly what someone needs to see. It is a self-custodial vault on Tempo and Robinhood Chain in which stablecoins, and on Robinhood Chain stock tokens, can be held, paid and proven with reduced public visibility. The thesis is one line: private by default, provable on demand.

Gloam is not new cryptography. A payment has one owner, so the owner proves it on their own device with zero-knowledge proofs from the Zcash lineage, and nobody else ever holds a key. What is new is the building block on top: private payments you can prove (section 7).

Privacy on a transparent chain is not the absence of transactions from explorers. It is the separation of settlement visibility from strategy visibility. Shield and unshield remain deliberate public edges. While assets remain inside the shielded set, amounts and internal transfer relationships are designed not to appear as a simple public balance sheet for a single address.

2. Problem

2.1 Transparent finance as confession

Open ledgers encode intent. A salary paid onchain is readable by every coworker. A supplier payment shows your margins. A treasury balance shows your runway. A large swap signals urgency. Address clustering tools turn a wallet into a public narrative. For teams, funds and agents this is not a feature. It is a cost priced into every interaction.

2.2 Stablecoin payments are public by default

Real stablecoin payments came to about $390B in 2025, double 2024, and 58% of that ($226B) was business to business. Every one of those payments, and the balance behind it, can be read by anyone with an explorer. AI agents that pay for tools over HTTP add a new payer with the same exposure: an agent's wallet shows what it buys and how it works.

2.3 Tokenized equities inherit the same exposure

Robinhood Chain positions itself as infrastructure for financial services and real-world assets, and tokenized stocks already trade there. Without application-layer privacy, a stock position is as public as a payment.

2.4 Why now

• New payment chains launched in 2026: Tempo mainnet on 18 March, Robinhood Chain on 1 July and Arc on 16 September. All are public by default.
• Stablecoins held privately in Railgun on Ethereum grew from $2.1M in January 2024 to $51M in October 2026. That is still under 0.1% of a $311B supply.
• FinCEN withdrew its proposed mixer rule on 5 October 2026. The GENIUS Act requires stablecoin issuers to be able to freeze, and Gloam's design never stops them.

3. Thesis and principles

Gloam asserts that private holding, private payment and selective proof are first-class requirements for onchain money, not optional skins on a public wallet.

• One owner, no key holder. A payment has one owner, so the owner proves it on their own device. No committee, operator or server holds a key or sees the secret inputs.
• Honesty over theater. No mock private success. Claims expand only as contracts, circuits, and audits support them.
• Battle-tested patterns. Commitments, nullifiers, Merkle membership, and zero-knowledge proofs, not novel cryptography invented for a launch tweet.
• Edges are real. Entering and leaving the vault is visible. Privacy tools reduce public visibility; they do not erase the physical world, legal process, or operator error.
• Testnet until ready. Production capital requires production ceremonies, reviews, and operational maturity.

4. What “privacy” means here

A common misconception is that private transactions leave no footprint on a block explorer. That is not how application-layer privacy on a public chain works.

• Visible by design:that the vault contract was used; shield (deposit) and unshield (withdrawal) events; proof verification transactions and the account that submits them (the Gloam relay can submit in the user's place).
• Hidden by design (goal): amounts while shielded; the internal transfer graph between notes; trade intent during private execution (roadmap).
• Degraded when the set is small: timing and size correlation; thin anonymity sets.

Private send does not mean “nothing on the explorer.” It means the public record does not present a simple Alice→Bob amount story for value that stays inside the vault.

5. System architecture

5.1 Placement

Gloam is an application-layer privacy system on a transparent L2 (Robinhood Chain), with the same contracts deployed on Tempo, a payments-first L1. Settlement finality remains with the chain. Privacy is constructed above it via a self-custodial shielded pool, a Merkle tree of note commitments, nullifiers to prevent double-spends, and on-chain verifiers for zero-knowledge proofs. The pool holds deposits, but only a valid proof from the note holder moves them: there is no admin withdraw, and rule changes are timelocked (5.5).

5.2 Core components

• Client application, wallet connection, note material generation, Merkle path reconstruction from on-chain events, browser-side proof generation, notes encrypted at rest, and product UX.
• ShieldPool (Poseidon), holds deposited assets, maintains the tree, accepts proof-bound shield deposits, and processes transfer and unshield with proof verification. It has no admin withdraw.
• Hash and tree, Poseidon-based commitments and a depth-20 Merkle structure aligned with circuit constraints.
• Circuits, shield (binds a deposit to its note), transfer (private send / split) and unshield (exit), with public-input layouts bound to the vault. A sealed-swap circuit for private trade is built but switched off. Three more circuits back the proofs in 6.1.
• Verifiers, Groth16 verifiers for each on-chain circuit. A dual verifier routes transfer and unshield by public-input count; deposits use a separate shield verifier.
• Memo board, an encrypted payment-message contract that lets a recipient find payments sent to them. It holds no funds.

5.3 Note scheme

A shielded note binds a secret, amount, and asset into a commitment. Nullifiers are derived so that spending a note can be recorded without reusing it. Exact field hashes and layouts are implemented in circuit source and client libraries and must stay aligned across releases.

5.4 Actions

• Shield, public assets enter the vault with a proof that the new commitment encodes exactly the amount and asset deposited; the commitment is inserted into the tree.
• Transfer (private send), spend one note, insert two new commitments (payment and change), conserve value for a single asset. The payment note is encrypted to the recipient's Gloam address (receive tag) and posted to the memo board, where the recipient's app finds it by scanning. A payment link covers people without a Gloam address.
• Unshield, prove ownership of a note and withdraw to a public address bound in the proof. Exit is a visible edge.
• Prove, show a named party a balance, a payment received, or a payroll total without opening the wallet (6.1).

5.5 Custody and rule changes

The pool is self-custodial. No function lets the owner, the team, or anyone else withdraw note-backed funds; value leaves only through an unshield proof, to the recipient bound in that proof. The owner's one transfer function returns native currency sent to the contract by mistake, above what notes back, and cannot reach note-backed funds.

The owner wallet can still change rules: swap verifiers, set rates, and set oracle feeds. Setup has ended on both live pools, so every such change must be queued on-chain and can only run after a public 3-day delay. Users see a pending change before it takes effect and can cash out first. On testnet the owner is a single wallet; moving it to a multisig is an open mainnet decision.

6. Cryptography and verification

Circuits are written in Circom 2.1.6, with Poseidon for circuit-friendly hashing and Merkle membership. Proofs are Groth16 on BN254, generated in the browser with snarkjs 0.7.5 and checked by on-chain verifiers. The trusted setup used on testnet is a single-contributor dev ceremony: its keys must not be treated as a production setup, and a multi-party ceremony is required before mainnet.

Public-input layouts are versioned. Shield binds commitment, amount, and asset. Unshield binds root, nullifier, asset, amount, and recipient. Transfer binds root, nullifier, and two new commitments. The dual verifier routes transfer and unshield by public-input count.

Sealed swap (private trade) binds root, nullifier, two new commitments, assets, a public min-out floor, and rate numerators. Its circuit, verifier, and oracle-bound rate checks are built and tested, but it is switched off: neither live pool has a sealed-swap verifier set, so every swap call reverts. Its first design could leave the pool owing an asset it does not hold (audit H1). It stays off while we build a new engine for private trading, and any re-enable goes through the 3-day timelock.

Earlier pools on both chains, including a keccak-based Robinhood Chain pool, remain on-chain for history only and are superseded. The product path is the Poseidon vault redeployed on 2026-09-29 with shield, transfer, and unshield verifiers enabled (dev keys).

6.1 Proofs shared with others

Three more circuits back proofs a holder hands to someone else: proof of funds (at least an amount across up to four unspent notes, balance hidden), proof of payment (a payment received, with the amount shown or only a minimum), and a payroll total (a run paid exactly a total in a given number of payments). These are verified off-chain, in the browser at gloam.trade/verify, against the live vault state. Each one (gloamfunds1, gloampay1, gloamroll1) carries a label naming who it is for and an expiry, both bound into the proof. The older gloamdisc1 balance disclosure reused the shield circuit and carried no recipient label or expiry. Every deposit publishes a valid proof of that statement on chain, so anyone could make one for any deposit. It is no longer made, and checkers never pass one; an exact balance is now a gloambal1 proof.

7. What is new in Gloam

Gloam is not new cryptography. It is a new building block for finance: private payments you can prove. This section draws the line exactly.

7.1 Not new

• The private pool design: notes, nullifiers and a Merkle tree, from the Zcash lineage starting in 2016, and used by Tornado, Railgun and Cloak.
• Selective disclosure as an idea: Zcash and Railgun viewing keys, Privacy Pools, and Zama decryption rights.

7.2 New, as far as our research found

1. Payroll total proof. The payroll_total circuit proves that a run of up to 32 payments adds up to exactly a total, all funded by the prover, without showing who got what. Its public inputs are [asset, total, count, paymentsHash, context]. Each slot opens both the payment note and the note it spent, so a payment the prover only received cannot be counted as one they made. We found nothing like it.
2. Proofs scoped to one reader. Who the proof is for (a label), its expiry, the chain and the pool are hashed into one public context input: keccak256(abi.encode("gloam.proof.v1", kind, chainId, pool, expiresAt, label)) mod p. The solvency, receipt and payroll_total circuits bind it into the proof, so changing the label breaks it. Anyone can check a proof in a browser with no wallet at /verify. Viewing keys, by contrast, show a holder's whole history and cannot be taken back.
3. Private payments for AI agents. A private payment method proposed for the Machine Payments Protocol from Tempo and Stripe (tempoxyz/mpp-specs#376; MPP had no private method), private x402 payments, and an MCP server that gives agents handles instead of secrets, with spending limits.

One honest limit: a reader can still forward a proof. It will say who it was made for and when it expires, but nothing stops the forwarding. A designated-verifier mode is next.

8. How Gloam compares

Privacy splits into two jobs. Shared secrets, such as sealed auctions, order books and lending pools, need someone to compute on many people's hidden data, so FHE and MPC networks (Zama, Arcium) use a committee that holds keys. A payment has one owner, so the owner proves it on their own device and nobody else ever holds a key.

The difference shows up in a breach. If a committee or an operator is breached, everyone who used it can be exposed, including past payments. If one owner's device is breached, one person is exposed. Gloam builds the payments product on proven zero-knowledge maths, the way Stripe built on card networks.

We found no other product on Tempo or Robinhood Chain that combines owner-only privacy, proofs for one reader, and payroll and agent rails. The full comparison, with what a breach exposes and where each one wins, is at /docs/compare.

9. Threat model

9.1 In scope (design goals)

• Observer reading a single address balance while assets are shielded
• Simple public reconstruction of internal note-to-note payment graphs (as anonymity set grows)
• Double-spend of the same note (nullifiers)

9.2 Edges and residual leakage

• Shield and unshield amounts and timing on the public chain
• RPC and network metadata if clients are careless
• The submitting wallet, when a user sends without the relay. On Robinhood Chain the deployed memo board also records who posted each memo, so the sender stays off that record only when the relay posts it; Tempo's board does not record the poster.
• Correlation attacks when few users participate or amounts are unique

9.3 Out of scope as “solved by crypto alone”

• Device malware, phishing, and coerced key disclosure
• Legal process and off-chain identity linkage
• User deletion of local note material without backup
• Absolute anonymity against nation-state adversaries

10. Product surface

The testnet application at gloam.trade/app provides:

• Wallet connection restricted to Robinhood Chain testnet and Tempo Moderato testnet
• Portfolio with wallet balances, shielded balances, and faucet stocks
• Stock tokens on Robinhood Chain held and sent privately, like any other asset in the vault
• Public send and stock token transfer paths
• Shield deposits into the privacy vault
• Private send (transfer) and cash-out (unshield) with browser proofs, optionally submitted by the Gloam relay so the user's wallet does not appear
• Receiving by Gloam address (encrypted memos) or payment link, plus note import
• Private payroll, scheduled payroll, and payment requests
• Proofs of funds, payment, and payroll totals, checked at /verify
• Private trade (sealedSwap): built, switched off while we build a new engine for private trading. A via-market path (cash out, public swap, re-shield) is available where a public pool exists, with the swap size public on that edge

Documentation and this whitepaper live on the same origin (/docs, /whitepaper). Marketing site and product share one brand: ink, paper, and a single green tint that marks what is private.

11. Roadmap

1. Live (testnet): public path, proof-bound shield, unshield, private send with encrypted memos, the Gloam relay, payroll, proofs of funds, payment, and payroll totals, private agent payments, stock tokens held and sent privately, the Tempo deployment, and pools with no admin withdraw and timelocked rule changes.
2. Underway:a new engine for private trading. The first sealed-swap path (circuit, verifier, oracle-bound rates) is built and tested but switched off. Trading mixes many people's orders, so it needs its own design rather than the payment one.
3. Near term: a designated-verifier mode for proofs; anonymity set growth; operational monitoring.
4. Mid term: issuer-scoped disclosure for regulated stablecoins on Tempo; private trading of stock tokens on the new engine.
5. Production gate: external review (audits so far are internal), a multi-party trusted setup, incident process, mainnet only after explicit readiness criteria.

12. Risks and limitations

• Smart contract and circuit bugs: audits so far are internal, with no external audit yet
• Development proving keys from a single-contributor dev ceremony
• Rule changes, including verifier swaps, by a single owner wallet, limited by a public 3-day delay
• Browser-local note storage and user operational error
• A payer can reclaim a direct payment until the payee moves it, because the payer created the note and knows its key; a fix is in progress
• A stablecoin issuer can freeze the vault contract; the answer is to screen deposits so flagged funds never enter
• A reader can forward a proof meant for them
• Regulatory and compliance uncertainty around privacy tools
• Thin anonymity sets in early usage
• L2 and bridge operational risk of the underlying chain

13. Explicit non-claims

Gloam does not claim mainnet readiness, an external audit, insurance of funds, legal immunity, or invisibility from investigation. Testnet assets have no real-world value. Nothing in this paper is investment advice.

14. Closing

Settlement will remain public. Salaries, suppliers and strategies need not. Gloam builds the sealed chamber beside the open book on Tempo and Robinhood Chain, so people, teams and agents can hold, pay and prove exactly what is needed, without printing every private calculation to the street.