What changes when the asset is a tokenized RWA, not plain ETH
The custody question looks identical at first glance: you have a private key, you want to keep it safe, you want to sign transactions. Tokenized real-world assets (RWA) such as ONDO's OUSG, BlackRock's BUIDL, or Mantle's MNT-denominated treasury products do not change the cryptography. What they change is the workload sitting on top of it.
A tokenized money-market fund or treasury fund typically issues and redeems on a schedule. OUSG, for example, settles redemptions on T+1. BUIDL distributes yield continuously and supports token-level transfers plus redemption through the issuer. That cadence means a treasury team cannot sit on a single unsigned transaction for a week the way a long-term BTC holder can. The signer queue has to clear inside a business day, often inside an hour if a redemption window is closing.
The second change is auditability. With vanilla ETH, the on-chain record is usually enough for an internal finance team. With a regulated RWA, the off-chain side has auditors, transfer agents, and sometimes a regulator who will demand proof that a redemption was authorized by named humans under a documented policy. That requirement reshapes custody, because "who signed" matters as much as "the signature is valid."
The third change is that the operational key is rarely the only key. Most RWA products separate a policy key, a daily operations key, and a guardian key, and each lives under different controls. Treating them as a single signing problem is where a lot of treasury designs go wrong.
The operational latency versus attacker-cost tradeoff
Custody is not one decision, it is a tradeoff between two numbers. The first is how long it takes to produce a valid signature when the business needs one. The second is how much an attacker has to spend, or how many independent failures they have to trigger, before they can produce a fraudulent one.
Cold storage, in the strict sense, pushes the attacker-cost number very high and the latency number with it. The key lives on a device that has never touched the internet, ideally in a vault, and signing means physically retrieving it. That is wonderful for a long-term BTC treasury, and miserable for a fund that must redeem ONDO or BUIDL every business day. The cost of being slow is not abstract: missed redemption windows can trigger penalty fees, queue you into the next cycle, or, in extreme cases, lock the position until the issuer's next cut.
Multisig shifts the tradeoff by distributing trust across signers and devices. A 3-of-5 setup means an attacker needs to compromise three independent signers, which is meaningfully harder than compromising one, while the latency is the speed of your fastest three signers. The catch is that "independent" is doing a lot of work. If three of your signers are managed by the same person, on the same operating system, with the same backup scheme, the multisig has not bought you three attackers' worth of difficulty. It has bought you one.
MPC, meaning threshold signature schemes such as GG20, GG20+, Lindell17, or the newer FROST implementations, moves the attacker-cost calculation into the protocol itself. The signing key never exists in one place. Each participant holds a share, and a threshold of them jointly produces a signature without ever reconstructing the full key. The latency can be very low, comparable to a single-signer hot wallet, and the attacker has to compromise a threshold of participants within a narrow signing window.
What MPC also does, and this is the part that does not get enough airtime, is lower the cost of operational mistakes. With multisig, losing one signer is annoying but recoverable as long as you stay above threshold. With MPC, the recovery story depends entirely on how the shares were generated, who holds them, and whether the custodian still exists. If you wipe a laptop and the share was only on that laptop, the policy may simply be unrecoverable, and the asset is effectively frozen until the underlying key-share ceremony can be re-run with the remaining participants.
Why institutional RWA custodians use HSMs, not consumer hardware wallets
A consumer hardware wallet, whether Ledger, Trezor, GridPlus, or Keystone, is a small secure-element device that stores a seed and signs transactions offline. For a personal BTC stack or a five-figure ETH position, it is excellent. For a treasury operationally signing redemptions on an institutional RWA book, the gaps start to add up.
The first gap is key export and cloning. Hardware wallets are designed so that the user, not the device maker, controls the seed. From an institutional perspective, that is a liability: a departing employee with the seed phrase and a backup in a safe deposit box is a key-person risk you cannot easily remediate. Institutional custodians want keys they can rotate, escrow, or destroy according to a written policy, and they want that process to be auditable end-to-end.
That is what HSMs, hardware security modules, are for. Devices like AWS CloudHSM, Thales Luna, Utimaco, or YubiHSM 2 are FIPS-validated, support role-based access, and integrate with policy engines that record every signing attempt, who initiated it, and under which rule. The keys never leave the device in plaintext, key rotation is a documented workflow, and an auditor can see a clean trail.
The second gap is around what gets signed. A consumer hardware wallet shows you a transaction on a tiny screen and asks you to approve it. A treasury team operating against OUSG or BUIDL needs to enforce policy before the signer even sees the transaction: per-asset limits, allow-listed counterparties, redemption caps per day, dual-control on anything above a threshold. That logic belongs in a transaction-policy engine or a smart-account layer such as Safe (formerly Gnosis Safe) with modules, not in a human staring at a 128x64 pixel display.
The third gap is operational throughput. A hardware wallet is built for occasional use, not for the dozens of approvals a daily RWA flow can produce when you include yield sweeps, fee payments, oracle attestations, and reconciliation entries. The ergonomics break down long before the security does.
Multisig recovery pitfalls that look fine until they aren't
Multisig on ETH is most commonly deployed as a Safe (formerly Gnosis Safe) wallet, with signers held on hardware wallets, and a documented recovery story. In theory, it is robust. In practice, three pitfalls show up repeatedly.
The first is signer homogeneity. A 5-of-9 looks safe until you realize all nine signers run the same wallet software, the same firmware version, the same backup procedure, and three of them were set up by the same person on the same afternoon. Multisig's safety scales with signer independence. The number 9 is decorative. The number that matters is the count of truly independent compromise vectors.
The second is signer availability. A multisig only works if you can reach threshold. If your signers are a mix of contractors in three time zones, an executive who travels, and a wallet that lives in a vault that requires two days to access, you can find yourself unable to sign a time-sensitive ONDO redemption because three of your five fastest signers are on planes. The solution is usually a combination of cold and warm signers, with policy that says hot signers can only approve small amounts. That works, but it adds another multisig to manage, and you are back to the recursion problem.
The third is recovery key custody. Every Safe has a recovery story, usually a function of how the signers were generated. If the recovery relies on a seed phrase written on paper in a safe, you now have a single piece of paper whose compromise gives an attacker a working signer. If the recovery relies on social recovery through guardians, you have shifted the trust to the guardians, who may not be who you think they are in five years. None of these are show-stoppers, but each one is a place where the neat-looking 3-of-5 quietly becomes a 2-of-5 with one signer in a drawer.
MPC key-share disappearance risk, in plain terms
MPC's defining feature, that the full key never exists in one place, is also its defining risk. The signing policy lives in the participants, and the participants can disappear.
Vendor disappearance is the most cited risk. If you custody with Fireblocks, Anchorage, BitGo, Fordefi, or a similar MPC provider, your shares are split between you and them. If the vendor is acquired, exits the market, suffers a serious outage, or simply deprecates your service tier, you may be able to migrate your assets, but only if the migration tooling is available and you have time. In a worst case, you hold a share, the vendor holds a share, and the threshold is no longer reachable because the vendor side is offline or unwilling.
Participant device loss is the next risk. MPC shares are typically held in HSMs, dedicated signing nodes, or hardened laptops. Each device has its own key custody story, including how shares are backed up and where. Lose two of those devices and you have a recovery problem on your hands, not just an inconvenience. The mitigation is share backup, but share backup is itself a custody decision: where do the backup shares live, who can decrypt them, and how do you prove to an auditor that no single person can reconstitute the key from the backups?
Protocol and implementation risk is the third risk. Threshold signature schemes are complex cryptography, and the implementations have had bugs. The 2022 disclosure around a vulnerability in certain GG20 implementations, the more recent findings around threshold EdDSA, and a steady trickle of issues in wallet SDKs are reminders that "the key never exists" is a stronger claim than "the key never exists and the signing code is bug-free." For an RWA treasury operation, the right move is to require independent security audits of the MPC provider's stack and to keep the option of migrating to a different scheme, even if it is expensive.
One nuance worth naming: MPC's safety is per-signing-event. Once a threshold of participants signs, the signature is valid forever, even if the participants' shares are later destroyed. So the disappearance risk is about future signing capacity, not about past signatures. That is the right framing to take to a board: we are not at risk of a past transaction being forged, we are at risk of being unable to operate the position.
A practical custody stack for daily-redemption RWA
Given the workload, a workable setup for a fund or protocol treasury holding tokenized RWA looks layered rather than pure.
The base layer is an institutional custodian with FIPS-validated HSMs for the long-term reserve. This is where the bulk of the position sits, under policy-controlled signing with role separation. For an OUSG or BUIDL allocation that does not need to move often, this is the right home, because the latency cost of getting into a vault is paid rarely and the attacker-cost is very high.
The working layer is a multisig Safe or an MPC cluster used for routine operations: small redemptions, yield sweeps, fee payments, oracle attestations. The choice between multisig and MPC here depends on signing volume, signer distribution, and the team's tolerance for operational risk. Multisig is easier to audit and easier to recover from. MPC is faster and handles high signing volumes better. Many teams use both: a Safe for governance and a smaller MPC cluster for execution.
The policy layer sits above both. A transaction-policy engine enforces per-asset limits, allow-listed contracts, daily caps, and dual-control rules. The signers do not see raw transactions; they see pre-approved intents, and the engine constructs and submits the actual transactions. This is where most of the operational risk is actually controlled, and where consumer hardware wallets fall short for institutional use, since they cannot enforce that policy in front of the signer.
The cold reserve layer is an air-gapped multisig for governance and policy changes: changing signers, rotating keys, upgrading the policy engine, moving large amounts out of the working layer. The latency here is acceptable because these events are rare, and the attacker-cost is very high because the keys live in a vault.
The honest summary is that "cold storage vs multisig vs MPC" is the wrong frame for institutional RWA. The right frame is which workload goes on which layer, and what the recovery story is when a share, a signer, or a vendor goes away.
How to follow RWA custody developments the smart way
RWA custody moves quickly because the products, the custodians, and the regulators are all changing at once. Tracking OUSG redemptions, BUIDL distribution mechanics, MPC provider migrations, and HSM firmware advisories by hand is a losing game. Zippfeed surfaces tokenized RWA headlines with sentiment scoring (bullish, neutral, or bearish) and an importance rating, so you can focus on the events that actually affect your custody design instead of drowning in noise.
CryptoSlate
CoinDesk
TheBlock
