Major update: the Bankhaus smart contracts are deployed. Everything is now live on Robinhood Chain. Smart Contract: 0x2025c6ee9f15b46ae8ed4b76bbd688e41948ca15, source verified, exact match. What went live is the onchain protocol: sealed balances, proofs checked on chain, mandates, letters, payroll, x402, multi-path. Connect a wallet and use it.

Update: we are eager to announce that Bankhaus is the first private banking house on chain where anyone can verify anything it writes, with a curl. Our compliance API is live: post a letter, a range letter, an audit file, a stream request or an x402 payment to bankhaus.app/api/verify and get the verdict. What it is, whether it holds, whether Robinhood Chain agrees. No key, no account, no software, nothing stored. The same code runs in the app, the terminal, the MCP tool and the SDK: one verdict everywhere. 0xefb57fd8fd62dbe2f7f486e56aa6f81fe83f43f9

How a letter proves “at least” without the figure. Commit to the difference between the figure and the threshold. Link that commitment to the ciphertext with a Σ-protocol, so it opens the same figure the chain holds. Prove the difference is not negative with a 32-bit Bulletproof. Below the threshold no such proof exists, so the letter cannot be written.

Bankhaus introduces stream requests. Ask for a stream, and they pay it in one tap. A subscription is a block of text: who, how much a month, for how long. Put it behind a link or a QR. Whoever opens it proves once, sets the year aside and the stream runs on your terms. Cancel any time, and the rest comes back sealed.

Tech note: what a stream reveals, and what it never does. Public: the payer, the recipient, the period, the count, how many periods were released, whether it is open. Sealed: the rate, the total, both balances, what each release moved. With a hidden recipient, who is being paid leaves the public column too. bankhaus.app/streams

New: range letters on streams. Prove you earn at least so much an hour, and keep the rate sealed. A range letter on a stream proves “at least 40.00 per hour” from the rate ciphertext the chain holds. No rate, no randomness in the letter; the reader verifies offline. Ask for more than the rate and no letter can be written. Streams also appear in audit files now, as the total set aside.

How a hidden recipient works. The recipient publishes two keys from one secret. The payer picks one ephemeral point, derives a one-time account and its view key from the shared secret, and announces the address, the point and a one-byte tag. The recipient checks the tag first, so 255 of every 256 announcements cost nothing, and recognises its own with one multiplication. Nothing links the address to the handle but the keys they hold.

Update: the board opens streams. A company account that pays salaries by the hour. One member proposes the stream, k members sign, and the board opens it with one proof under the view key they share. The treasury sets the total aside, sealed; each person releases what accrued. No admin key, no payroll run, no rate on chain. bankhaus.app/board

Improved privacy? Say no more. Introducing a salary nobody can trace. Not the amount, not the person. A sealed stream can now go to a hidden recipient: a one-time account announced at the counter, which only they recognise with their key. The chain sees a stream to an address with no handle, no history and no second use, and a rate that is two ciphertexts. They release from that account whenever they like. bankhaus.app/streams

Four days, nine updates. Passkey accounts, alerts and webhooks, range letters, multisig boards, audit export, sub-agents, sealed streams, metered x402 and payroll that pays itself. Two contracts redeployed, 132 checks on the real bytecode, 42 tools in bankhaus-mcp, and still not one figure on chain. All of it live on Robinhood Chain. More to come!

What a sealed stream costs. Opening one is 2,006,323 gas: one proof, 1,792 bytes. A release is 38,239 gas: two multiplications, two additions, by anyone. A month of hourly pay as 160 sealed transfers would be 293.6M gas; as one stream and 160 releases it is 8.1M. Thirty-six times less, measured on the real bytecode.

New: payroll that pays itself. One sealed stream per person, by the hour, opened once with one proof each. Everyone releases what accrued when they like, and next month there is nothing to run. The chain holds five streams, no rate and no total. The payslip is the letter that opens the rate to that person alone. bankhaus.app/payroll

Why a stream release needs no proof? ElGamal is homomorphic. Multiply both points of a ciphertext of the rate by k and you get a ciphertext of k × rate under the same key. The chain does that with the periods elapsed and adds the result to the recipient’s balance. The total was proven once at opening and the count is enforced, so nothing else needs proving.

We improved our x402: pay an API by the second, with one proof per session. The server’s 402 asks for a stream instead of a price: so much per second, for so long. Your agent opens the stream once and retries with a letter that opens the rate to the server; the server checks it against the stream on chain and serves while the meter runs. It releases what accrued whenever it likes; you stop paying by cancelling. The price never appears on chain. Live at bankhaus.app/api/metered

New sealed streams. Pay someone by the hour, by the day or by the month, and the chain never learns the amount. Sealed balances contract (not a token): 0x2ac72c1dbe9aa3d03d4af67996dc8a709f36d59f What it is: you open a stream once. The rate is sealed to your key and to theirs, you prove once that rate × duration fits in your balance, and that total is set aside. From then on the money accrues by itself: the recipient, or anyone, releases what has accrued at any time, with no signature from you and no proof from anyone, because the chain just multiplies the sealed rate by the time elapsed. Cancel and what is left comes back to you, still sealed. Salaries, rent, subscriptions. Live on Robinhood Chain.

No, nobody can, including us. Your balance is an ElGamal ciphertext on chain. The view key that opens it is derived on your device from one signature and never leaves it, the site has no server that holds keys. When you need to show a figure, you write a letter that opens one transfer to one reader, or an audit file for one period. The chain keeps a receipt that you answered, never the number. xitter.cf/Nuev9999/status/211224…

Thanks for reaching out. The chain never sees the figure, but it checks a proof with every transfer. Each sealed transfer carries a 1,792-byte proof: a Sigma protocol that links the encrypted deltas to the sender’s key, and a Bulletproof that shows the balance after the payment is still in range. No balance, no proof, no transfer. The verifier checks it in one multi-scalar multiplication, 1.83M gas. xitter.cf/0xHach1/status/2112239…

Update: sub-agents. An agent can hire an agent, and the mandate only shrinks. A sub-agent runs under the same owner with ceilings that fit inside its parent’s, and a recipient list the parent could pay. Every spend below counts against the day of every agent above, so a whole tree never exceeds the root mandate. Pause the top and the branch stops. Live on Robinhood Chain. bankhaus.app/agents#subagent… 0xefb57fd8fd62dbe2f7f486e56aa6f81fe83f43f9

Bankhaus team is proud to announce the audit export. Hand the auditor one period, proven line by line, and nothing else. An audit file holds every sealed transfer you sent between two dates, each as a letter the auditor checks against the chain, plus the total. The auditor also lists your transfers for the period on chain and matches them: a line left out shows as missing, one invented shows as extra. Nothing before, nothing after, never your balance. More details at bankhaus.app/audit

A sealed transfer’s proof is 1,792 bytes. Two commitments, one challenge and seven responses for the Sigma protocol. Then the Bulletproof: four points, three scalars, six folded rounds of L and R, and a, b. The rest is ABI framing. The chain checks it in one multi-scalar multiplication.

What a proof is tied to. The challenge of a sealed transfer is a keccak over twenty words: chain id, token, sender, recipient, both keys, the balance ciphertext and both deltas. Change one and it is a different proof. So nothing replays on another chain, to another recipient, or after the balance moved.