STV3 is Stobox’s RWA token protocol: an ERC-20 built on the Diamond Standard (EIP-2535), so it is modular and upgradeable. Compliance plugs in at the transfer layer through a validation facet, and it is Chainlink CCIP-ready for cross-chain.
STV3 is an architecture choice before it is a feature list. It assumes a security token has to be maintained for years, so it is built to be changed without redeploying.
Why
A conventional ERC-20 is one contract. Fix a bug or adapt to a new rule and you redeploy, then migrate every holder — painful, and for a security, risky. STV3 avoids that by using the Diamond Standard (EIP-2535): one stable token address (the proxy) that routes calls to separate logic contracts called facets. You add, replace, or remove a facet without moving the token or its holders. It also lets the token exceed the ~24KB single-contract size limit.
The repository organizes STV3 into clear facets:
- StoboxProtocolSTV3 (core). The immutable ERC-20 functions —
transfer,approve,balanceOf. The parts you never want changing stay fixed. - DiamondCutFacet. The controlled way to add, replace, or remove facets. This is the upgrade authority, and constraining it is the whole game (see the take below).
- DiamondLoupeFacet. Introspection — anyone can enumerate the facets and check interfaces (ERC-165). Upgradeable does not have to mean opaque.
- CCTFacet. Adds
transferAndCall(ERC-677), role-based mint and burn, and operator management, and is built to Chainlink’s Cross-Chain Token (CCT) standard so the token can move across chains. - DefaultValidationFacet. The hook where compliance lives:
beforeUpdateValidationandafterUpdateValidationrun around every transfer. This is how eligibility and transfer rules are enforced at the transfer layer rather than bolted on around it.
The edge cases
Be precise about what the public protocol is today versus where it is going.
Compliance is a hook, configured per deployment. The validation facet is the place transfer rules plug in; the public repository ships it as the extension point, prepared for the specific rule sets a given issuance needs. STV3 gives you the enforcement point at the transfer layer; the rules themselves are configured, not hard-coded into the core.
Upgradeability is power that must be governed. Whoever can run a diamond cut can change the token. For a security that is a governance question, not a convenience. Constrain the cut authority with a timelock and multisig or on-chain governance, audit the cut logic and storage layout, and disclose who holds it. (See Diamond Standard risks if you are weighing EIP-2535 generally.)
Roadmap, not yet shipped. The repository lists planned work — DID integration, regulatory rule sets, oracle integration, corporate treasury, STO embedment, and compliant DeFi. Treat those as direction, not current features.
What this means for your structure
If your instrument has to survive rule changes, chain changes, and multi-year maintenance, a modular architecture is not a luxury. STV3’s value is that compliance and cross-chain movement are facets you can update, and the core ERC-20 is not. The trade you accept is governing the upgrade authority carefully — which you should be doing regardless.
Gene Deyev’s take
A security token has to outlive every assumption you make at launch. Rules change, chains change, standards change. That is why we built STV3 modular: compliance is a facet you update, not a constant you hard-code and hope never moves. The alternative — redeploy the contract and migrate every holder each time a regulator shifts — is how tokenized securities quietly die. Build the record to be maintained, and govern the upgrade key like it can rewrite the instrument, because it can.
— 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
- Diamond Standard EIP-2535: what are the risks?
- ERC-3643 vs ERC-7943
- What if the platform disappears?
Last updated: 2026-07-12.