Holding RWAs in a Self-Custody Wallet: Approvals, Transferability, and Tax

Your Keys, Your Coins — With an Asterisk

"Not your keys, not your coins" is one of the cleanest truths in crypto. For BTC, ETH, or any native cryptoasset, holding the private key is the whole game. Lose the seed, lose the coins. Hold the seed, hold the coins. The chain doesn't care who you are.

Real-world assets break that symmetry. As we showed in Part 1 of this series, the token is just a pointer to a legal wrapper — an SPV, a trust, a regulated fund. The wrapper, not the token, is the asset. That means self-custody of RWAs requires three things working at once:

1. The keys. Same as always.
2. A live KYC binding. The issuer's compliance system must recognise your wallet address as belonging to a verified you.
3. A solvent issuer with a working redemption path. As we covered in Part 5, keys alone don't open the gate at the bank.

Lose any one of those and the token in your wallet is, at best, an illiquid claim. This article is the practical layer — what self-custody of RWAs actually looks like in 2026, the approval hygiene that protects you, the transfer rules you need to know, and an honest pass at tax treatment.

Permissioned vs Permissionless: Two Very Different ERC-20s

Not all RWA tokens behave the same way when you hit "send."

Permissioned tokens revert on transfer if the destination address isn't on a whitelist. BUIDL, OUSG, and Backed Finance's dShares all use this model — typically built on ERC-3643 (T-REX) or a similar standard. The compliance check happens in the smart contract before the transfer settles. If you airdrop a BUIDL token to a friend's fresh wallet, the transaction will fail on-chain. According to public T-REX adoption data, ERC-3643 now backs $32B+ in tokenised assets across 180+ jurisdictions, so this pattern is the dominant one for institutional issuance.

Allowlist + blocklist tokens sit in the middle. Per Ondo's documentation, USDY uses on-chain allowlists for primary issuance and a blocklist for sanctioned addresses, but secondary transfers between allowed wallets are relatively free.

Mostly-standard ERC-20s behave like normal tokens at the contract level. FOBXX, XAUT, and PAXG mostly fall here — transfers don't revert on compliance checks. The KYC gate is at issuance and redemption, not in motion. This is closer to the Tether/USDC model.

Why does this matter for self-custody? Because if you're holding a permissioned token, your address is bound to your identity. Move the token to an exchange address that isn't whitelisted and you've bricked your position until you sort it out with the issuer.

ONCHAINID and the Address-Identity Binding

ERC-3643 introduces an identity layer called ONCHAINID — an ERC-735-style identity contract that holds claims (KYC verified, accredited investor, jurisdiction code) issued by trusted parties like Securitize or Tokeny.

The useful property: ONCHAINID supports binding multiple wallets to the same identity. If you do KYC once, you can register a hardware wallet, a hot wallet, and a backup wallet to the same identity claim. Lose one, you can recover the position to another bound address without restarting KYC from scratch. Practically, you have to set this up before the loss — most issuers won't add a wallet to an existing identity unless the request comes signed from an already-bound address or you go through a manual recovery process.

If you're serious about holding RWAs long-term, register at least two wallets per identity. One signing wallet on a hardware device, one cold backup. It's the on-chain version of the safety deposit box.

Hardware Wallets, Multisigs, and the Signing Problem

For ERC-3643 tokens, the transfer call is just an ERC-20 call from the wallet's perspective — transfer(to, amount). The compliance logic runs inside the token contract. That means any hardware wallet that signs ERC-20 transfers will work — Ledger, Trezor, and others, paired with MetaMask or Zelcore's WalletConnect flow. Our hardware wallet pairing guide walks through the setup.

The risk to watch is blind signing. Some RWA flows — subscription, redemption, identity registration — use custom calldata that hardware wallets can't fully decode. Always verify the contract address against the issuer's official documentation before approving, and prefer issuers whose contracts are verified on Etherscan with readable function names.

Multisigs are trickier. A Safe (formerly Gnosis Safe) wallet has its own contract address — and that contract address is what the issuer whitelists, not the individual signer EOAs. A few practical consequences:

• Adding or removing signers doesn't break your KYC binding. The whitelist is on the Safe address.
• Some issuers explicitly refuse smart-contract addresses for whitelisting because of how compliance attestations are scoped. Always check the issuer's policy before sending RWAs to a multisig.
• If you migrate to a new Safe (different address), you have to re-register the new address with the issuer. There's no "transfer" of KYC binding between contracts.

For sizing the discussion, BUIDL has a $5M minimum subscription and $250K minimum redemption. At those numbers, a multisig is appropriate, but the operational complexity multiplies — every signer needs to understand the compliance wrapper, not just the token contract.

Approvals: Same Footguns, Higher Stakes

ERC-3643 and similar standards still use the standard ERC-20 approve and transferFrom pattern under the hood. That means every approval you give a DEX, an aggregator, or a redemption portal has the same risks we covered in the approvals fundamentals article: unlimited approvals can be drained if the spender contract is compromised, and approvals can outlive your KYC.

That last point is RWA-specific. If your KYC lapses, the issuer can disable transfers from your address — but an outstanding approval to a redemption contract from when you were verified might still be exploitable in edge cases. Treat RWA approvals as time-bounded by default.

Practical rule: revoke approvals after each session using Etherscan's token approval checker, revoke.cash, or your wallet's built-in revoke flow. The defensive stack we outlined in the DeFi security article — finite approvals, periodic audits, hardware-wallet signing — applies just as much to RWAs as to permissionless DeFi.

Forced Transfers and Why They Exist

Here's the part that breaks crypto-native intuition: ERC-3643 contracts have an admin/agent role that can execute transfers irrespective of the normal compliance and approval logic.

This exists for legitimate reasons — sanctions enforcement, court orders, recovery for users who genuinely lost their keys (with proof of identity). It's the wrapper layer reaching down through the chain. If a US court orders the seizure of tokenised treasuries held by a sanctioned entity, the issuer can execute that order on-chain.

Is this "real" self-custody? It's a real question. The honest answer: you have full operational custody day-to-day — no one can move your tokens in normal operations. But the wrapper retains a hard override for legal compliance. If that bothers you philosophically, RWAs probably aren't the right asset class for you. If it doesn't, just know it exists and it's documented in every serious issuer's prospectus.

Tax: Read Before Acting

Disclaimer: This is not tax advice. RWA tax treatment is unsettled in many jurisdictions, varies by where you live, and changes with each tax year. Talk to a qualified tax professional before filing. The notes below are general orientation, US-focused, and current as of early 2026.

Three categories of RWA, three different tax stories:

Tokenised treasuries (BUIDL, OUSG, BENJI, USDY). The yield is generally treated as ordinary interest income (US Topic 403), state-tax-exempt because the underlying is US Treasury debt. If the fund is US-registered and Securitize-administered, you'll typically receive a 1099-INT. The token transfer between your own wallets is not a taxable disposition; redemption back to USD or USDC at a different price than your basis is.

Tokenised equities (Backed, dShares, xStocks). These are tokenised securities. Starting with the 2026 tax year, expect Form 1099-DA reporting with a CUSIP and Box 1i flagging wash-sales-loss-disallowed where applicable. The big difference from native crypto: traditional securities wash-sale rules (§1091) apply because these are securities, not just property.

Tokenised gold (XAUT, PAXG). Under IRC §408(m), physical gold is a "collectible," capped at 28% long-term capital gains versus the 20% standard rate. The tokenisation wrapper doesn't change the underlying classification — if the IRS treats your XAUT as a claim on physical gold, the collectibles rate likely applies.

The wash-sale gap. Native crypto isn't currently covered by §1091 because the IRS treats it as property, not a security. Several legislative proposals (including from Senators Lummis and Wyden) would extend wash-sale rules to digital assets. Tokenised securities are already inside the rule. This is a real wedge — and a reason to keep clean transaction records regardless.

Inheritance. A BTC seed phrase in a sealed envelope is enough for your heirs to claim BTC. RWAs require a death certificate, often a court letter, and direct contact with the issuer to re-bind the position to the heir's KYC'd wallet. Document the issuer, the account number, the recovery process, and the contact, and store it with your estate paperwork.

Series Close: What Six Articles Built

This closes our six-part walk through real-world assets on chain. Here's the through-line:

Part 1 made the foundational point: the legal wrapper is the asset. The token is just a pointer. Without the SPV, trust, or fund structure off-chain, there's nothing on-chain worth holding.

Part 2 showed where the yield actually comes from: T-Bills sitting inside that SPV, paying coupons, getting passed through to token holders. BUIDL, OUSG, USDY, FOBXX, BENJI — different wrappers, same underlying machinery.

Part 3 extended the same compliance plumbing to institutional credit — Centrifuge, Maple, Goldfinch. The mechanics that move tokenised treasuries also move tokenised loan books. The yield is higher because the credit risk is higher.

Part 4 generalised the pattern to equities and commodities. The same hardware wallet that holds your BTC can hold a Backed AAPL share — with permissioned-transfer restrictions, KYC, and forced-transfer powers all bolted on.

Part 5 was the cold shower: self-custody perfectly does not insulate you from off-chain failure. If the issuer is insolvent, the custodian is fraudulent, or the redemption window closes, your token is a piece of paper.

This Part 6 closed the loop on the operational layer — approvals, KYC bindings, signing, tax. The unifying principle across all six parts: "Your keys, your coins" is necessary but not sufficient for RWAs. You need the keys, the live KYC binding, the solvent issuer, and the working redemption path. Drop any of the four and you're holding something less than you think you are.

If you take one checklist away, take this six-step one:

1. Verify the legal wrapper exists and is reputable.
2. Confirm your wallet is KYC'd and whitelisted.
3. Test redemption with a small amount before sizing up.
4. Revoke approvals after each session.
5. Document the issuer's recovery and estate process.
6. Keep complete transaction records for tax season.

RWAs are real, the rails are getting better, and the institutional flows are not slowing down. Go in with eyes open.