Research notes

What was considered while designing Kasumi v1, and what was taken from each. Facts were checked against primary sources on 2026-10-02 unless marked unverified, which means the statement comes from memory or a secondary source.

Threshold and timelock encryption#

Shutter API#

Threshold encryption run by a keyper set, with an HTTP API on Gnosis (mainnet) and Chiado (testnet).

• Time-based triggers work end to end: register an identity with a decryption timestamp, encrypt to the eon key and identity, fetch the key after the timestamp. One identity can cover all orders of an epoch.
• Event-based trigger endpoints exist. The keypers watch the chain where the Shutter registry is deployed. There is no chain parameter. An event on an Arbitrum Orbit chain cannot trigger release. This is inferred from the keyper configuration; no document states it either way.
• Rate limits without an API key: 5 identity registrations per IP per day on mainnet. Premium is described as roughly one registration per minute.
• Keyper set size and threshold are not officially documented. A read of the keyper set contract showed a 12-member set with threshold 5, which may be stale. Unverified.
• The API README says the network is not fully decentralised.
• Key release latency after the timestamp was not measured.

Taken: the model (one identity per epoch, key released after a trigger) and the pluggable scheme interface. Not used in v1, for the reasons in PROTOCOL.md §3.

drand timelock (tlock)#

Timelock encryption to the drand quicknet beacon, operated by the League of Entropy. 3 second rounds. No registration, API key or rate limit. Time-based only; anyone can decrypt after the round.

Taken: this is the v1 sealing scheme. The public key and chain hash are pinned in the SDK. A seal or unseal takes about 65 ms in Node on the development machine; a round trip against the live beacon is part of the SDK test suite.

TEEs: SUAVE, BuilderNet#

BuilderNet runs block builders in TEEs that take encrypted order flow for Ethereum L1 block building. It is in production but is not a general sealed-order service. SUAVE remains a design and testnet. Unverified (from memory).

Taken: nothing in v1. A TEE matcher would let orders stay private from the operator after decryption as well, at the cost of a hardware trust assumption. It is a possible later step, not a replacement for the onchain checks.

Batch auctions and intent systems#

The descriptions of other protocols in this section are summaries from secondary sources and memory, not a review of their current code. Treat details as unverified.

CoW Protocol#

Batch auctions with uniform clearing prices and solver competition. Orders are signed offchain and are visible to solvers; there is no cryptographic pre-trade privacy. Settlement contract enforces signed limits regardless of the solver.

Taken: uniform clearing price per batch, "the solver proposes, the contract enforces", signed limit orders with sell/buy bounds checked onchain, and nonce invalidation as the user's escape hatch. Kasumi adds encryption before the batch closes and replaces solver competition with a fixed deterministic rule.

UniswapX#

Signed offchain Dutch-auction orders filled by competing fillers, kept out of the public mempool. No encryption; fillers see orders. Uses Permit2 for approvals.

Taken: the idea of signed orders plus allowances rather than custody. Permit2 is deployed on Robinhood Chain; integrating it is not implemented in v1.

0x RFQ#

Makers sign quotes for a specific taker; the taker fills onchain. Private in the sense that the quote is bilateral, with no batch and no uniform price. Unverified (from memory).

Taken: nothing in v1. Private RFQ is a natural second product on the same order and settlement contracts, since an RFQ fill is a two-order batch. Not implemented.

Frequent batch auctions#

The academic case (Budish, Cramton, Shim) is that discrete-time uniform-price auctions remove the speed race inside the batch.

Taken: the whole market design. Kasumi's allocation has no time priority at all; ties are pro-rata.

Private execution elsewhere#

Penumbra#

A separate chain with shielded batch swaps. The protocol documentation describes threshold "flow encryption" of swap amounts as a future upgrade. Not reusable on an EVM chain.

Taken: the framing that the batch, not the individual trade, is the unit of privacy.

Aztec#

A privacy L2 with client-side proofs and private notes. Private state rather than timed batch decryption; using it would mean building on that L2. Unverified (from memory).

Taken: nothing. Kasumi targets tokens that live on Robinhood Chain.

Robinhood Chain#

• Arbitrum Orbit chain, live on mainnet (chain id 4663) with a public testnet (46630). ETH gas.
• First-come sequencer ordering. The sequencer applies compliance-based transaction filtering.
• Stock Tokens: ERC-20, 18 decimals, raw balances fixed across corporate actions, display scaled by uiMultiplier, upgradeable beacon proxies. Issued by a Robinhood entity as tokenised debt securities and not offered to US persons.
• A blocklist checked on sender, recipient and caller, and a pause switch, are reported by a secondary source and are consistent with selectors in the bytecode. The issuer does not document them. Unverified.
• ERC-2612 permit appears present by selector but is not documented and was not exercised. Unverified.
• USDG has 6 decimals.
• Chainlink is the only documented oracle provider. Stock Token feeds have 8 decimals and price one raw token. They stop updating outside market hours.

Kasumi is not affiliated with Robinhood.

Smart accounts#

ERC-4337 EntryPoints documented on Robinhood Chain mainnet:

EIP-7702 is supported per the chain documentation.

Taken: KasumiSettlement accepts ERC-1271 signatures when the order owner has code, so a smart account can place orders. The offchain pipeline accepts a contract-signature check as an optional callback. A "Kasumi smart account" and user-operation flows are not implemented in v1.

Not built in v1#

Listed so the design leaves room for them: private RFQ, hidden stop orders, OTC blocks, external routing (the order already signs allowExternalRouting and maxSlippageBps), multi-relay aggregation, a Shutter or other event-triggered scheme, a TEE matcher, Permit2 funding.