Sign in to the console
Digital asset custody for exchanges and businesses

A key is never whole in one place.

Each wallet's key is split into shares on separate nodes, and no withdrawal happens without several people approving it on their phones. Custody infrastructure for a team that holds its customers' money.

Sign in to the console
A split keyEach wallet lives on several separate nodes; two signatures of three are enough, and no node can sign alone.
Approval on the phoneApprovers see the full amount and address and sign with their own device's key.
Policy on every nodeLimits, allowed addresses and approvals are checked again on the nodes themselves, not only on the server.
An open threat modelWe keep a written threat model and share it with customers.

Why an MPC wallet

An ordinary wallet has one private key, and whoever reaches it takes everything. With MPC the key is never made: it is split into shares on separate nodes from the start, and signing happens without the shares ever coming together.

1The whole key is nowhere. The shares are made separately, and no server, not even Romu's, sees the key.
2Each share on its own node. In different places, with a backup encrypted under your own key. One node alone cannot sign.
3Two signatures of three are enough. Each node checks the policy and the approvals itself and signs only with its own share. The network sees one ordinary signature.
Ordinary walletOne key, one point of failure
On-chain multisigSeveral signatures, but tied to each network and costly
Romu MPCSeveral shares, one ordinary signature; shares replaced without changing the address

For whatever you do with digital assets

One infrastructure, three ways to use it. They differ only in policy and the number of approvers.

Exchange

A hot wallet with quick approval

Customer withdrawals come in through a signed API. A small one under the limit goes automatically; a large one waits for approval in the app.

  • API keys limited to your wallets and your networks
  • A signed webhook for every status change
Payments and settlement

Stablecoin settlement only to allowed addresses

Settlement with partners goes only to addresses added before, with approval. A new address becomes active after a delay you set.

  • An allowed-address list with an activation delay
  • Daily and per-transaction limits in USD
  • A unique id for each payment; a repeat never pays twice
Treasury

Long-term holding with a high threshold

A wallet with no API key, every withdrawal approved by all approvers, and the shares backed up under your own key.

  • No programmatic access; proposals from the console only
  • The number of approvers and the limits are yours to choose
  • A node restored from its backup, without moving any assets

Every major chain, one key, one policy

TRON today (TRX and any TRC-20 on request); the rest coming soon

Coming soonComing soonComing soonComing soonComing soonComing soon

How a withdrawal happens

The same path that is built into the product and checked by automated tests on every change.

1

Request

The exchange's system, with a signed API key, or an operator in the console proposes the withdrawal.

2

Policy

The allowed address, the USD limits and the approvals needed are checked. A small withdrawal goes automatically; a large one waits for approval.

3

Approval on the phone

Approvers see the full amount and address in the Romu app and sign with their own device's key.

4

Signing and sending

Each node signs with its own share, without the whole key being made anywhere, and the transaction goes to the network.

One withdrawal, start to finish

One example, step by step: from the request in the console to confirmation on chain. Sample 1,500.000000 TRX

  1. 1Request from the consoleAn operator proposes the withdrawal.
  2. 2Policy checkThe USD limits and the allowed address are checked.
  3. 3Approval on mobile2 of 3 approvers sign in the app.
  4. 4MPC signing on the nodesTwo nodes, each with its own share; the whole key is never made.
  5. 5Sent to the networkThe signed transaction goes to TRON.
  6. 6Confirmed on chainAfter the network's confirmations, the console shows it as confirmed.

Why Romu

What a technical and finance team needs on day one, not six months later.

  • We hold no secret of yoursYou make the API key yourself and give only its public key. Passwords are kept only as hashes, and the two-step code's secret in a key vault, not in the database.
  • Every change needs approvalAn allowed address, a policy, an API key, a wallet or a new node: each becomes a request and is applied only once several people sign. Not even an admin can do it alone.
  • USD values from a price you can trustThe market price is shown next to every amount; a sudden price jump asks for human approval instead of an automatic withdrawal.
  • Share backups before the first withdrawalUntil each share's backup is taken and verified, the wallet does not withdraw. Losing a node means a restore, not losing assets.
  • Persian and English from day oneThe console and the approval app in both languages; numbers, addresses and ids read the same in both.

Judge the security yourself

Romu's threat model and its architecture decisions are written down and available to customers: which attacks we close, with which control, and which risk remains.

Romu has not yet had an independent security audit. When it has, the result will be published here; until then we do not claim one.

Key
Split between separate nodes; never made in one place.
Approval
The approver's device signs the exact values, not a click on the web.
Nodes
They check the policy and the approvals again themselves.
Internal traffic
Every service is known by its own certificate, and certificates renew themselves.