---
title: "Who holds the keys"
author: Mariusz Szyma
date: 2026-09-15
lang: en
canonical: https://szyma.co/en/blog/rwa/who-holds-the-keys/
series: "RWA: Past, Present and Future"
series_part: 5/11
series_url: https://szyma.co/en/blog/rwa/
data_as_of: 4–10 Sep 2026
---

# Who holds the keys

A private key moves a plain ERC-20 token and nothing else is asked. In a regulated fund the same key moves nothing until the contract agrees, and the code that holds that veto can usually move a holder's balance without asking the holder at all. This chapter reads those powers out of four products, names the addresses that hold them, and separates the powers that exist from the ones that have been used.

## What you'll learn

- Read a permissioned token's administrative powers out of its own code and name who can call each one.
- Tell a forced transfer from a clawback, and say which of the two leaves something to give back.
- Name what binds when the transfer agent's register and the chain disagree.
- Separate a power that exists from a power that has been used, and say what the on-chain record can show about each.

## A backdoor is a legal requirement, not a defect

A plain ERC-20 has one transfer rule: the sender has the balance, so the balance moves. A security cannot run on that rule, because the law puts at least five conditions on its movement: who may hold it, when they may move it, how much they may hold, what happens after a court order, and who supervises all of that.

The last two are the awkward ones. The transfer agent, defined in [chapter 1](/en/blog/rwa/what-is-an-rwa/) as the licensed firm that keeps a fund's official shareholder list, carries a legal duty to execute court orders and to correct errors in the register. One that cannot technically move shares on an order cannot do the job it is registered for, so a product built to be legal has to carry a backdoor. Asking whether an RWA product has administrative keys answers itself.

**A forced transfer** moves a holder's tokens to another address without that holder's consent. In BUIDL, BlackRock's tokenized Treasury fund, which has run on Securitize's DS Protocol since 1 March 2024, the function that does this is called `seize`. **A clawback** takes the tokens away without sending them anywhere. On Stellar, where Franklin Templeton's BENJI has run since 2021, the operation of that name destroys the balance outright. Both powers are commonly summarized as an ability to freeze tokens, and that summary loses the difference that decides what a holder can get back.

The question worth asking has three parts: how narrowly the power is scoped, who holds it, and whether an outsider can check that it has not been used.

![Ten compliance powers across seven token standards: a forced transfer, a clawback or both sits in every standard written for securities, and bare ERC-20 is the only column with neither, per the author's knowledge base, Sep 2026.](https://szyma.co/blog/img/token-standards-powers.30c52961.svg)

## Six lines of code, one role, and one key above it

Securitize is the SEC-registered transfer agent and tokenization platform behind BUIDL, and DS Protocol is its own architecture rather than a public standard: the code carries an `UNLICENSED` header and belongs to no EIP, yet it is verified on-chain and readable. Its forced transfer is six lines of Solidity that move the balances and emit a `Seize` event next to the standard `Transfer`.

The modifier on `seize` is `onlyTransferAgentOrAbove`, not `onlyMaster`. DS Protocol numbers four roles, MASTER (1), ISSUER (2), EXCHANGE (4) and TRANSFER_AGENT (8), and the second-lowest of them is enough to take a holder's tokens. Burning from someone else's address runs through a different modifier, `onlyIssuerOrTransferAgentOrAbove`, and that circle is wider: the ISSUER role is enough to burn from any address and not enough to force a transfer. Reading the roles on-chain on 4 September 2026, eight entities in all held one of the roles that can burn from any address, two of them controlled by keys and six of them system contracts.

Two properties of `seize` point in opposite directions. The `_reason` recorded with a seizure is an arbitrary string with no reference to a document hash or an order registry, so the justification for taking someone's shares is a free-text field. The separate `Seize` event, though, means the operation cannot be hidden, because every use appears in indexers immediately.

**An externally owned account**, usually shortened to EOA, is an address controlled by a private key rather than by code, which is what distinguishes it from a contract or a multisig wallet. This is what held BUIDL's powers on the Trust Service contract `0x3a68756d0335e75c909ba1e8fefc1d4832c36c60` when I read it on 4 September 2026.

| Power | Role | Held by | Address |
|---|---|---|---|
| `seize`, `burn` | TRANSFER_AGENT | externally owned account | `0xA9994621F1c3EE59846Df756488229E8efDCB8bf` |
| `seize`, `burn` | TRANSFER_AGENT | `TokenReallocator` contract | `0xf33675685C8Ee774c7f5655C93AfEdC7B9818EcD` |
| everything, plus `setTarget` | MASTER and proxy owner | externally owned account | `0xE01605f6b6dc593b7d2917F4a0940dB2A625b09e` |

The last row carries the finding that outranks the rest. **A proxy** is a small contract that stores the address of another contract and forwards every call to it, so the logic can be replaced while the balances stay where they are. BUIDL's proxy `0x7712c34205737192402172409a8F7ccef8aA2AEc` is not the OpenZeppelin pattern but a forty-line contract of Securitize's own, whose `setTarget` assigns a new implementation in one call. **A timelock** is an enforced delay between ordering an administrative change and that change taking effect, which gives holders time to leave. This proxy has none, no separation between proxy administrator and logic owner, and no multisig. One private key can swap the whole implementation in one transaction, and `getRole()` returns 1 for that same key.

The deployment history shows the opposite habit. The contract went live in block 19,343,277 on 1 March 2024 at 22:20 UTC, and the deployer renounced the MASTER role 22 minutes later, handing it to the address above.

> **My take:** The strongest power in BUIDL is not the one with the frightening name. `seize` is scoped, logged and visible; `setTarget` is unscoped, instant and held by one key. The second invalidates any answer about the first, because if the implementation can be replaced in one transaction, then a finding that the code contains no such function describes today rather than guaranteeing tomorrow.

## The same power, built two other ways

### OUSG does not have the function at all

Ondo Finance is a crypto-native issuer without a transfer agent registration of its own, and OUSG is its tokenized Treasury product. Its implementation `0x1CEB44b6E515aBf009E0CCb6ddaFD723886cf3Ff` is a minimal extension of OpenZeppelin with a hook that checks the KYC status of the sender, the recipient and whoever submitted the transaction. Reading the full list of mutating functions from its ABI on 4 September 2026, there is no `seize`, no `forcedTransfer`, no `freeze`, no `setAddressFrozen` and no `recoveryAddress`. The contract cannot move a holder's tokens to another address, because nobody wrote a function that does it.

Burning from someone else's address is possible in principle, through `burn(address,uint256)` behind a `BURNER_ROLE`. That role has never been granted. Two methods agree: a scan of every `RoleGranted` event since the deployment block 16,234,210 shows not one grant of it, and `hasRole()` returns false for every address that has ever held any role at all.

That is a third state, and most analysis of these products knows only two. A power can be absent from the code, or present with nobody authorized, or present with authorized holders standing by. For OUSG the distance from the second state to the third is one `grantRole` call approved by a 4-of-7 multisig.

**A multisig** is a wallet that executes only when a set number of named signers approve, written as X of Y. Ondo split OUSG's powers across three of them at three thresholds: token administration on a 4-of-7 Safe, the identity registry on a 3-of-5 Safe, and the emergency pause on a 1-of-9 Safe. The lowest threshold is a design decision rather than an error, because any one of nine people can halt the token alone while destructive changes need four signatures.

Control over a holder runs through the KYC registry rather than any freeze function. The transfer hook requires a registry status for all three parties, so removing an address makes its `transfer` revert. That is a freeze in effect, and it is harder to spot from outside than an explicit flag: there is no event saying an address was frozen, only a registry removal that looks like routine compliance work.

### BENJI puts the rules in the network instead of the contract

Franklin Templeton took the oldest route of the three. BENJI has no compliance smart contract, only flags on a Stellar issuer account, enforced by the network rather than by the issuer's code. The account `GBHNGLLIE3KWGKCHIKMHJ5HVZHYIK7WTBE4QF5PLAKL4CJGSEU7HZIW5` verifies through its `home_domain` of `www.franklintempleton.com`, and on 4 September 2026 all three control flags were set: `auth_required`, so nobody holds BENJI without explicit authorization, `auth_revocable`, so authorization can be withdrawn and a balance frozen, and `auth_clawback_enabled`, so tokens can be taken from any account. The fourth flag, `auth_immutable`, is false, so the flags themselves can still be changed.

The signing model is where this gets interesting. The account's master key has weight 0 and cannot sign anything alone. Ten signers carry weight 3 and four carry weight 1, for a total weight of 34, against thresholds of 2 for low operations, 2 for medium and 6 for high. A clawback falls under the medium threshold, which a single weight-3 signer already clears, so one signer out of ten can take BENJI from any account or deauthorize it without consulting anyone. Changing the rules through `SetOptions` needs 6, which is two of those signers. Operations inside the rules are cheap and changes to the rules are expensive, the same asymmetry Ondo built with its 4-of-7 and 1-of-9 thresholds, expressed in a different system.

> **Example:** The allow-list is not decorative. Reading Horizon on 4 September 2026, BENJI had 1,357 authorized trustlines and 953 unauthorized ones. A trustline on Stellar is an account's declaration that it wants to hold a given asset, so 41% of the accounts that asked to hold this fund were refused at the protocol level.

![BUIDL, OUSG and BENJI hold the same legal power in three different shapes, and none of the three puts a timelock in front of any of it, on readings of Ethereum and Stellar taken 4 Sep 2026.](https://szyma.co/blog/img/admin-powers-three-products.b0546a28.svg)

## One share class, four chains, four mechanisms

Everything above rests on Ethereum, and for BUIDL that is the largest hole in the argument, because each deployment is a separate contract rather than a copy. I read BUIDL's powers on Ethereum on 4 September 2026 and then directly on Avalanche, Solana and Aptos on 5 September 2026. That is four of the eight or nine chains the sources give for this product; Arbitrum, Optimism, Polygon, BNB Chain and Tempo were not read. Addresses came from CoinGecko's platform mapping and each was then verified by calling `symbol()`, `name()` or reading metadata on the target chain, because an address from a third-party service is not yet evidence that the contract being read is the right one.

One result is the same everywhere: an equivalent of `seize` exists on every chain I read, and I found a multisig on none of them.

On Avalanche the token `0x53fc82f14f009009b440a706e31c9021e1196a2f` points at an implementation whose bytecode carries selectors for `seize(address,address,uint256,string)` and `omnibusSeize`, and none for `forcedTransfer`, `freeze`, `unfreeze`, `mint` or `setTarget`. This deployment does not repeat the Ethereum proxy pattern: it uses a standard ERC-1967 layout with an empty admin slot and upgrades through `upgradeToAndCall` in the implementation itself, and `owner()` returns an address with no code behind it.

On Solana the mint `GyWgeqpy5GueU2YbkE8xqUeVEokCMMCEeUrfbtMw6phr` runs on Token-2022 with the `permanentDelegate` extension enabled, which lets the named delegate move or burn tokens from any holder's account and cannot be revoked the way an ordinary approval can. The delegate `APm3MWbXfMMKAWgsDVnxcAGbLjvRxubPu1A8a5SA2kbJ` is not a private key: it holds 73 bytes of data and belongs to the program `7tXjmbkZVY3Gmg9kDBebcNXT1yC5pyoxxXVLwdbv9tvP`. That is one level better than Ethereum and only one, because the upgrade authority of both relevant programs is `8d36iv2YUD8yDChuVZchx1NqE4qkDWCAEgsUEEUqzbB6`, a plain system account with zero bytes of data. Whoever controls it cannot seize tokens with one signature, and can replace the code that does.

On Aptos the powers are expressed in a way no EVM chain offers. The fungible-asset object carries an `Untransferable` resource, which switches off ordinary transfers at the level of the standard itself, so the token moves only through the issuer's dispatch functions. The seizure function is named exactly as in Solidity, `ds_token::seize(&signer, address, address, u64, String)`, an entry function with the same free-text reason. The module account is an object account whose `sequence_number` is 0, meaning it has never signed a transaction itself, and its owner holds no multisig resource.

The supplies rearrange the picture as well. Of the four classes I read, Solana holds 51.1% against Ethereum's 11.1%, which makes the Solana class 4.6 times the size of the Ethereum one. Any statement about this product drawn only from Ethereum describes about a ninth of the supply it can see, including the statements earlier in this chapter.

![One BUIDL share class on four of its chains: a seize-equivalent exists on every chain read, no multisig appears on any of them, and zero use is confirmed for Ethereum only, on readings of 4 and 5 Sep 2026.](https://szyma.co/blog/img/buidl-admin-powers-four-chains.1edec61b.svg)

## When the register and the chain disagree, the register wins

Code is not the top of this stack. Steakhouse Financial, reading BUIDL's offering memorandum in April 2024, reports that ownership of class A shares is visible on Ethereum while legal title and beneficial ownership are reflected in a register of members kept by the transfer agent, that this register governs legal ownership in all circumstances, and that where the register and the blockchain disagree the register decides. That reading quotes a document the author of this series has not seen.

Securitize's own filings describe the same construction from the other side. Its Form S-1 and 424B3 for fiscal 2026 say it acts as an SEC-registered transfer agent for most clients and uses a public blockchain as the master securityholder file, holding wallet addresses, balances, share counts, purchase dates, transaction identifiers and investor status on-chain, and names, addresses and tax numbers off-chain. **A master securityholder file** is a defined regulatory term rather than a marketing one: Rule 17Ad-10(b) makes it the official list of individual securityholder accounts and allows it, for uncertificated shares of registered funds, to consist of several linked automated files. The chain is one of those files, not a replacement for the set.

The newer generation of filings words the same architecture the other way round. BlackRock's Form 485APOS of 8 May 2026 introduces an OnChain Shares class whose official record of ownership is kept on a public blockchain by the transfer agent, BNY Mellon Investment Servicing (US) Inc., and states that the blockchain records together with the off-chain register mapping wallets to shareholder identities conclusively govern record ownership, absent a technical failure of either system. A prospectus of the same date for the BlackRock Daily Reinvestment Stablecoin Reserve Vehicle puts that official record with Securitize Transfer Agent, LLC instead, across Ethereum, Tempo and Solana. One manager, two transfer agents, two register architectures.

Franklin Templeton's FOBXX shows what a regulator accepts and why. On 12 August 2026 the SEC's Division of Investment Management issued a no-action letter allowing Franklin's registered funds to hold FOBXX shares through the linked blockchain system without complying with paragraphs (b), (e) and (f) of Rule 17f-2, under 12 conditions covering account segregation and transaction controls. The staff's stated reason is that the transfer agent retains unilateral control over the official record of ownership. Permissioning is what makes that acceptance possible.

For a holder this reverses the instinct that the chain is the source of truth. If a contract shows a balance and the transfer agent's register does not, the register binds, and after a technical failure or a contract bug the reconstruction runs from the register. [Chapter 6](/en/blog/rwa/oracles-and-nav/) meets the same asymmetry in the data layer, where the authoritative number also lives off-chain and the on-chain copy is the thing that goes stale.

![Five architectures for who keeps the legally binding register, with what binds when the register and the chain disagree, from offering documents and SEC filings dated Apr 2024 to Aug 2026.](https://szyma.co/blog/img/who-keeps-the-legal-register.447ab1ba.svg)

## What the chain settles and what it leaves open

Three things are settled by reading. The first is the rule set, because the parameters that sit in an offering document for a traditional fund sit in a contract here, in BUIDL's case `ComplianceConfigurationService` at `0x1dc378568cefd4596c5f9f9a14256d8250b56369`.

| BUIDL compliance parameter | Value, read 4 Sep 2026 |
|---|---|
| `getTotalInvestorsLimit()` | 1,999 |
| `getTotalInvestorsCount()` | 89, which is 4.5% of the limit |
| `getUSAccreditedInvestorsCount()` | 32 |
| `getForceAccredited()` / `getForceAccreditedUS()` | 1 / 1 |
| `getUSLockPeriod()` / `getNonUSLockPeriod()` | 86,400 s, or 24 hours |
| `getBlockFlowbackEndTime()` | 1,703,980,800, being 31 Dec 2023 and expired |
| `getMaximumHoldingsPerInvestor()` | 0, no upper limit |
| `cap()` | 0, no supply cap |

Those readings contradict two common descriptions of these funds at once. The investor limit was used at 4.5% on 4 September 2026, so capacity is not what keeps retail out, and the lock-up is 24 hours rather than a year. This is a product locked to a narrow group, not locked for a long time.

The second settled thing is cost. BUIDL's checks run across eleven separate contracts on every transfer, among them `InvestorLockManager` and `ComplianceServiceRegulated`, and the median gas used by an identical `transfer` call on Ethereum mainnet on 4 September 2026 was 4.07 times that of USDC.

The third is whether the powers have been used here. Scanning BUIDL's logs by event topic from the deployment block 19,343,277 to 4 September 2026 returns the following.

| Event on BUIDL, Ethereum | Count |
|---|---|
| `Seize` | 0 |
| `OmnibusSeize` | 0 |
| `OmnibusBurn` | 0 |
| `Pause` and `Unpause` | 0 and 0 |
| `Burn` | 208 |
| `Issue` | over 1,000 |

The forced-transfer power has existed since 1 March 2024 and has not been used once on this chain, and the token has never been paused. On OUSG the role that burns from other addresses has never been granted to anyone.

What the chain leaves open is larger. The 208 `Burn` events cannot be split into redemptions and confiscations, because both emit the same event and the contents of the `_reason` strings were not read; reading them as redemptions is consistent with how this fund settles a withdrawal, and it is an interpretation rather than a measurement. On BENJI I found no clawback operation, in a sample of the issuer account's last 200 operations covering roughly 7.5 hours, which says nothing about the asset's history since 2021. Use of the seizure power on Avalanche, Solana and Aptos was not evaluated at all: a full log scan on Avalanche alone would take 20,451 requests at the public node's 2,048-block limit across 41,884,144 blocks of history.

> **Watch out:** Zero uses is not evidence of safety. It is evidence that the power has not been used, on one chain, up to one date. It does separate a risk that is potential from one that has materialized, and in these three products the administrative risk is still potential.

## Five ways these products have actually failed

Administrative powers are one risk among five, and the other four decide more outcomes. An underlying asset can default, and the loss lands in the NAV, which is how credit exposure is meant to behave. A contract can be hacked, and here the compliance machinery cuts the other way: an attacker in a whitelisted product ends up holding tokens the contract will not let him send to any address off the list, and the transfer agent can usually reverse the theft with the same forced transfer that makes the product uncomfortable to hold.

The issuer can go bankrupt, and whether the holder has a claim on segregated fund assets or a place in a creditor queue depends on the legal level rather than the code. The custodian can go bankrupt, and the question there is whether assets were segregated or sat on the custodian's balance sheet. The fifth is the one that keeps happening: the issuer decides to stop. USDM is the case that shows it, because nothing broke. From 22 August 2025 the token was no longer backed by Treasury bills or redeemable at 1 USD from the issuer, and its backing became another stablecoin in a Uniswap pool. The bills were sound throughout, and the issuer used a right it had held from the start.

![Five ways an RWA product ends, with what protects the holder and who takes the loss in each; the highlighted wind-down row is the most common of the five, and the smart-contract row has no case in this record, on evidence to Sep 2026.](https://szyma.co/blog/img/five-failure-modes.a15d8058.svg)

## Key takeaways

1. A legally compliant security token must carry a forced transfer or a clawback, because an SEC-registered transfer agent that cannot execute a court order cannot perform its function; bare ERC-20 is the only standard compared here with neither power.
2. BUIDL's `seize` is gated by `onlyTransferAgentOrAbove` and emits its own event, so every use is immediately visible, while its `_reason` field is free text with no link to any document or order.
3. The strongest power in BUIDL is `setTarget` on its own forty-line proxy, held on 4 September 2026 by a single externally owned account that also holds the MASTER role, with no timelock and no separation between proxy administrator and logic owner.
4. OUSG contains no function that can move a holder's balance, and its `BURNER_ROLE` had never been granted to any address as of 4 September 2026; control runs instead through a removable KYC registry spread over Safes at 4-of-7, 3-of-5 and 1-of-9.
5. BENJI's clawback sits behind Stellar's medium threshold of 2 against signers of weight 3, so one signer out of ten can take or freeze any balance, while changing the account's rules needs two of them.
6. The same BUIDL share class runs different enforcement machinery on each chain, and the Solana class was 4.6 times the Ethereum class on readings of 4 and 5 September 2026, so an Ethereum-only analysis covers 11.1% of the four classes read.
7. Where the transfer agent's register and the chain disagree, the register binds: BUIDL's offering memorandum says so directly, and the SEC's 12 August 2026 no-action letter for FOBXX rests on the transfer agent keeping unilateral control of the official record.
8. Zero `Seize`, `OmnibusSeize`, `OmnibusBurn`, `Pause` and `Unpause` events appear on BUIDL's Ethereum class between 1 March 2024 and 4 September 2026, and use on Avalanche, Solana and Aptos was not evaluated, so the finding covers one chain and not the product.

## Glossary

- **Forced transfer**: moving a holder's tokens to another address without that holder's consent. Named `seize` in DS Protocol, `forcedTransfer` in ERC-3643, and served by the permanent delegate extension on Solana.
- **Clawback**: taking tokens away without sending them to a chosen address. On Stellar the operation destroys the balance, so unlike a forced transfer there is nothing left to return.
- **Externally owned account (EOA)**: an address controlled by a private key rather than by code. On-chain it is indistinguishable from a single signer, even where an operator runs an internal approval procedure behind it.
- **Multisig**: a wallet that executes only when a stated number of named signers approve, written X of Y. Three Safes at 4-of-7, 3-of-5 and 1-of-9 hold OUSG's administrative powers.
- **Timelock**: an enforced delay between ordering an administrative change and that change taking effect. None of the three products compared here has one on any administrative function.
- **Proxy**: a contract that stores the address of another contract and forwards calls to it, so the logic can be replaced while balances stay in place. BUIDL uses a forty-line proxy of Securitize's own rather than a standard pattern.
- **Permanent delegate**: a Token-2022 extension naming an account that may move or burn tokens from any holder, and that cannot be revoked the way an ordinary approval can.
- **Trustline**: on Stellar, an account's declaration that it wishes to hold a given asset. With `auth_required` set, the issuer must authorize each one before the account can hold the token.
- **Master securityholder file**: the official list of individual securityholder accounts under Rule 17Ad-10(b), which for uncertificated shares of registered funds may consist of several linked automated files.

## Go deeper

- [What an RWA actually is](/en/blog/rwa/what-is-an-rwa/): the three-condition test there predicts, without reading a line of code, that a compliant RWA has to carry some form of forced transfer.
- [Oracles, NAV and proof of reserves](/en/blog/rwa/oracles-and-nav/): the register-versus-chain asymmetry resolved here is the same one behind a stale NAV on-chain.
- [Who's who: the RWA map by layer](/en/blog/rwa/whos-who/): Securitize, Ondo and Franklin Templeton return there with full company profiles beyond their token architecture.
- 🟢 Stellar Developers documentation: semantics of `auth_required`, `auth_revocable`, `auth_clawback_enabled` and `auth_immutable`, and the signer weight and threshold model.
- 🟢 17 CFR 240.17Ad-10(b): the definition of a master securityholder file and its allowance of multiple linked automated files.
- 🟢 Securitize press release on the BUIDL launch: roles of BlackRock Financial Management, BNY Mellon, Securitize and PwC, under Rule 506(c) and Section 3(c)(7).

## Sources

- 🟢 Author's on-chain readings, Ethereum mainnet via the public `eth.blockscout.com` endpoint, 4 September 2026: BUIDL proxy `0x7712c34205737192402172409a8F7ccef8aA2AEc` (full forty-line `Proxy` source, `owner()`, `target()`), implementation `0x603bB6909bE14F83282e03632280d91Be7Fb83B2` (`DSToken` v5 plus 36 dependency files), Trust Service `0x3a68756d0335e75c909ba1e8fefc1d4832c36c60` (all 20 role events, `getRole()` for 11 addresses), `ComplianceConfigurationService` `0x1dc378568cefd4596c5f9f9a14256d8250b56369` (40 parameter getters), `ComplianceServiceRegulated` `0x07a1ebfb9a9a421249ddc71bddb8860cc077e3a9`, `InvestorLockManager` `0x0a65a40a4b2f64d3445a628abcfc8128625483a4`, and an `eth_getLogs` scan by topic from block 19,343,277.
- 🟢 Author's on-chain readings, 4 September 2026: OUSG implementation `0x1CEB44b6E515aBf009E0CCb6ddaFD723886cf3Ff` (full ABI and source plus 22 dependency files), all 28 `RoleGranted` and 22 `RoleRevoked` events since block 16,234,210, `hasRole()` across five roles and six addresses, Safes `0xaed4caf2e535d964165b4392342f71bac77e8367` (4 of 7), `0x5ae21c99fc5f1584d8cb09a298cffd92b5d178ef` (3 of 5) and `0x2e55b738f5969eea10fb67e326bee5e2fa15a2cc` (1 of 9), `ProxyAdmin` `0xba80aa44cc25e85cc30359150dfb1c7d041cf6d5`, and `OndoIDRegistryView` `0x56a5d911052323d688c731d516530878557463e7`.
- 🟢 Author's on-chain readings, Stellar via `horizon.stellar.org`, 4 September 2026: account `GBHNGLLIE3KWGKCHIKMHJ5HVZHYIK7WTBE4QF5PLAKL4CJGSEU7HZIW5` (`home_domain`, flags, thresholds, signer weights), the BENJI asset record showing 1,357 authorized and 953 unauthorized trustlines, and the last 200 issuer operations covering about 7.5 hours.
- 🟢 Author's on-chain readings, 5 September 2026, raw results in `onchain_multichain_buidl.json`: Avalanche C-Chain token `0x53fc82f14f009009b440a706e31c9021e1196a2f` and implementation `0xf93667d01c7675e2667ee392aa69104df79c4ad0` (bytecode selector scan, ERC-1967 slots, `owner()`); Solana mint `GyWgeqpy5GueU2YbkE8xqUeVEokCMMCEeUrfbtMw6phr` with its Token-2022 extensions, delegate `APm3MWbXfMMKAWgsDVnxcAGbLjvRxubPu1A8a5SA2kbJ`, controller program `7tXjmbkZVY3Gmg9kDBebcNXT1yC5pyoxxXVLwdbv9tvP` and upgrade authority `8d36iv2YUD8yDChuVZchx1NqE4qkDWCAEgsUEEUqzbB6`; Aptos fungible-asset object `0x50038be55be5b964cfa32cf128b5cf05f123959f286b4cc02b86cafd48945f89` and module account `0x4de5876d8a8e2be7af6af9f3ca94d9e4fafb24b5f4a5848078d8eb08f08e808a`. Supplies: Solana 977,902,117.97, Avalanche 564,231,692.75, Ethereum 211,920,742.07, Aptos 161,340,739.89.
- 🟢 Author's gas measurement, Ethereum mainnet, 4 September 2026: median `gasUsed` for `transfer(address,uint256)` of 45,160 for USDC (n=40), 91,335 for OUSG (n=17) and 183,672 for BUIDL (n=46), which is 2.02× and 4.07×.
- 🟢 DS Protocol source code, read from the chain; header `SPDX-License-Identifier: UNLICENSED`, no public repository.
- 🟢 Stellar Developers documentation: account flag semantics and the signer weight and threshold model.
- 🟢 17 CFR 240.17Ad-10(b): master securityholder file, including the allowance of multiple linked automated files for uncertificated shares of registered funds.
- 🟢 Securitize, Form S-1 and Form 424B3, fiscal year 2026: use of a public blockchain as the master securityholder file, and the split between on-chain and off-chain data.
- 🟢 BlackRock, Form 485APOS of 8 May 2026 and the accompanying 485BPOS and 497K: the OnChain Shares class, BNY Mellon Investment Servicing (US) Inc. as transfer agent, the conclusive-governance wording and its technical-failure exception, permissioned ERC-20 issuance, and the amended declaration of trust.
- 🟢 BlackRock Daily Reinvestment Stablecoin Reserve Vehicle prospectus, 8 May 2026: official record of OnChain Shares kept by Securitize Transfer Agent, LLC across Ethereum, Tempo and Solana.
- 🟢 Securitize press release on the BUIDL launch: roles of BlackRock Financial Management, BNY Mellon, Securitize and PwC, under Rule 506(c) and Section 3(c)(7).
- 🟢 Securitize / PR Newswire, 25 March 2025: the Solana share class and its token address, used to corroborate the Solana address read here.
- 🟢 HSBC Hybrid Gold ETF, Form S-1 (EDGAR, February 2026): Traditional Shares in book-entry form with an option to hold a Creation Unit as Tokenized Shares represented by an instruction token on a permissioned blockchain run by the transfer agent's system.
- 🟢 SEC staff joint statement of 28 January 2026 and the DTC tokenization pilot under the staff no-action letter of 11 December 2025: the custodial-entitlement and synthetic branches in the register figure, with LedgerScan remaining the official book and Cede & Co. the record owner.
- 🟡 Steakhouse Financial, April 2024, reading BUIDL's offering memorandum: class A ownership visible on Ethereum, legal title and beneficial ownership reflected in the transfer agent's register of members, that register governing in all circumstances and prevailing over the chain in a discrepancy. The author of this series has not seen the underlying document.
- 🟡 The Defiant and Crowdfund Insider, August 2026: the SEC Division of Investment Management no-action letter of 12 August 2026 on FOBXX, relief from paragraphs (b), (e) and (f) of Rule 17f-2 under 12 conditions, granted on the basis of the transfer agent's unilateral control of the official ownership record.
- 🟡 CoinGecko `/coins` platform mapping, 5 September 2026: contract addresses across nine platforms, used only to locate addresses, each then verified by a read on the target chain.
- 🟡 Author's knowledge base, module 5 (token standards, the eleven compliance mechanisms and the standards comparison), module 6 (register architectures) and module 1 (the five failure modes and the USDM wind-down of 22 August 2025).
- 🟡 Spark, *Tokenized Private Credit*, around August 2026: Goldfinch's roughly 18 mn USD of defaults and its June 2026 wind-down vote, used as the asset-default case in the failure-modes figure.

## Caveats

Use of the forced-transfer power outside Ethereum is not established. The zero-event result covers BUIDL's Ethereum class between 1 March 2024 and 4 September 2026 and nothing else. A full scan on Avalanche would take 20,451 `eth_getLogs` requests at the public node's 2,048-block limit across 41,884,144 blocks; Solana would need a scan of the mint's transaction history, and the Aptos indexer was out of reach in this pass. Those cells in the four-chain figure say "not evaluated" rather than zero.

Four chains of eight or nine were read for BUIDL, and the chain count itself is disputed in the sources rather than settled. Arbitrum, Optimism, Polygon, BNB Chain and Tempo were not read. For OUSG only Ethereum was read and for BENJI only Stellar, so whether their powers look the same on other networks is unknown. The percentage shares in the four-chain figure are computed from the four readings rather than from the product's whole supply.

Who stands behind a key is not visible on-chain. The externally owned account holding BUIDL's MASTER role and proxy ownership could be a hardware security module with an internal approval procedure on Securitize's side, which is the likelier reading, and the chain cannot distinguish that from one person with one key. The identical address string for the Avalanche contract owner is a fact about an address, not proof of a single key.

The 208 `Burn` events on BUIDL were not classified. The contents of the `_reason` fields were not read, so redemptions and confiscations cannot be separated from the event log alone.

The BENJI clawback sample is small. It covers the issuer account's last 200 operations, roughly 7.5 hours, against an asset that has existed since 2021.

BUIDL's investor counters disagree with each other. `getTotalInvestorsCount()` returned 89 and `getUSAccreditedInvestorsCount()` 32, while `getAccreditedInvestorsCount()` returned 91, which is more than the total. Whether that is a different definition, a counter bug or a historical remnant was not established, and it is recorded here without interpretation.

Whether BUIDL's 1,999 investor limit follows from the 2,000 beneficial-owner threshold in Section 3(c)(7) was not verified against the fund's offering document. The numbers are consistent with that reading and the dependency is not confirmed.

The BUIDL offering memorandum was not read directly. The register-prevails clause comes from Steakhouse Financial's April 2024 analysis quoting the document, and the FOBXX no-action letter reaches this chapter through The Defiant and Crowdfund Insider rather than from the letter itself.

The register figure omits RealT and USDY, which the chapter brief lists among six products for it. No source read for this chapter states who keeps the legally binding register for either one, so the figure shows the five architectures that are documented and names a product only where a filing or an offering document supports it.

Everything on this page ages by one transaction. Roles, multisig thresholds and compliance parameters are the state on 4 September 2026 and can change in a single call; the ISSUER role on BUIDL has rotated every few months, most recently on 1 April 2026. Every number here can be read again at the addresses given.