The real risk is not the code, it is who can change it. EIP-2535 lets whoever controls a diamond cut rewrite the token’s rules. Constrain that authority with a timelock, multisig, or on-chain governance, and audit storage layout.
EIP-2535 is a good tool with a governance problem attached. Judge the problem, not the tool.
Why
EIP-2535, the Diamond Standard, splits a contract’s logic across separate contracts called facets, all sitting behind one proxy address. That buys you two things: the token can grow past the roughly 24KB contract size limit, and you can add, replace, or remove functions after deployment through a single function, the diamondCut.
For a security token, that upgradeability is the risk. Whoever can run a diamond cut can change what the token does. Transfer restrictions, compliance checks, the balance logic itself. For a normal utility contract that is a maintenance convenience. For a security, it is a governance question: can the terms of the instrument change under the holders after they buy in?
That is not a technical problem you audit away. It is a trust problem you have to constrain.
The edge cases
Three failure modes matter more than the rest.
Storage-layout collisions. Facets share the proxy’s storage. If two facets map their variables to the same storage slot, one silently overwrites the other. These bugs are subtle, they survive unit tests, and they can corrupt balances. This is the classic Diamond footgun. Ethereum’s smart-contract security guide treats upgradeable proxies as a category that demands independent audit for exactly this reason.
Verifiability. With one contract, a holder inspects one address. With a diamond, they have to enumerate every facet and read all of them to know what the token actually does today. Transparency does not disappear, but it gets harder, and harder-to-verify is a weaker assurance for a regulated instrument.
Unconstrained upgrade authority. A single admin key that can cut the diamond at will is the worst case. It means the token’s rules are whatever that key-holder decides on any given day.
What this means for your structure
Do not treat upgradeability as the enemy. You want the ability to fix a bug or adapt to a rule change; freezing a security token forever is its own risk. The answer is to constrain who holds the cut and how it fires.
Concretely: put the upgrade authority behind a timelock so changes are announced before they land, require a multisig or on-chain governance so no single party can act alone, and audit both the diamond cut logic and the storage layout, not just the facets in isolation. Then disclose the arrangement. Holders should know exactly who can change the terms and under what delay.
Diamond systems are used generally for upgradeable RWA tokens, and that is defensible. The design only earns trust when the upgrade path is a governed, disclosed, audited process rather than one wallet with a live edit button.
Gene Deyev’s take
A security has to live for years, and the rules around it will change — regulation, corporate actions, bug fixes. A token that can never be upgraded is not safer, it is just brittle. We built STV3 on the Diamond Standard for exactly that reason. The discipline is not avoiding upgradeability; it is governing the key that controls it. Put the cut behind a timelock and a multisig, disclose who holds it and under what delay, and keep the ownership record able to outlive any single operator. Do that and upgradeability becomes an asset, not a liability.
— Gene Deyev, CEO & Co-Founder, Stobox. Co-author of the Stobox Tokenization Framework and the STV3 protocol; ERC-7943 backer; SEC Crypto Task Force roundtable participant (2025).
Related questions
- ERC-3643 vs ERC-7943 for compliant tokens
- How to choose a tokenization platform
- What if the platform disappears?
Last updated: 2026-07-12.