ERC-7518, known as DyCIST (Dynamic Compliant Interoperable Security Token), is a proposed security-token standard built on ERC-1155. It uses ERC-1155 token IDs as partitions, so one contract can hold multiple share classes or tranches, and adds compliance, time-locks, payouts, forced transfers and wrapping for cross-chain interoperability. It reflects a different philosophy from ERC-3643: instead of one token per instrument with an on-chain identity registry, it keeps many classes in one semi-fungible contract and leans on off-chain compliance approvals.
Key takeaways
- Partitions as ERC-1155 IDs — classes, tranches or jurisdictions live side by side in one contract.
- Dynamic compliance — transfers can be approved using signed off-chain compliance data, so rules can change without redeploying.
- Issuer controls — freezing, forced transfers and time-based token locks.
- Payout functions for distributing dividends or coupons to holders.
- Interoperability via wrapping and unwrapping, aimed at moving security tokens across chains.
- It remains a proposal; check its status before committing, and consider ERC-7943, which aligns its naming with ERC-7518 for compatibility.
How DyCIST differs from other approaches
| ERC-7518 | ERC-3643 | ERC-1400 | |
|---|---|---|---|
| Base | ERC-1155 | ERC-20 | ERC-20-like |
| Classes / tranches | Token IDs | Separate tokens | Partitions (ERC-1410) |
| Compliance | Dynamic, often off-chain signed approvals | On-chain identity + modules | Off-chain certificates / whitelists |
| Agent controls | Freeze, force transfer, locks | Freeze, force transfer, recovery | Controller operations |
| Status | Proposal | Final | Never finalised |
Ideal use cases
- Funds with several share classes (e.g. accumulating vs distributing, different fee tiers) in one contract.
- Debt issuances with multiple tranches where each tranche needs its own lock-up and payout schedule.
- Programmes that span chains and want a defined wrapping path.
- Issuers whose rules change often and prefer off-chain approval logic that can be updated without contract changes.
Things to evaluate
- Ecosystem support — wallets, custodians and venues may support ERC-3643 or plain ERC-1155 more broadly today.
- Off-chain dependency — signed compliance approvals introduce a service your transfers depend on; design for availability and key security.
- Audit scope — ERC-1155 callbacks, batch operations and payout logic all need careful review.
- Regulatory comfort — be ready to explain how compliance is enforced to regulators and auditors.
How NUVZ approaches it
We start from the instrument and the investor base, not the standard. For multi-class instruments on ERC-1155 we often implement compliance hooks plus the ERC-7943 interface; where a client’s partners already support ERC-7518 or ERC-3643, we align with them. Our token standard decision guide explains the full process.
Mapping a multi-class fund to DyCIST-style partitions
| Token ID (partition) | Class | Rules |
|---|---|---|
| 1 | Class A — accumulating, USD | Professional investors; 12-month lock-up |
| 2 | Class B — distributing, USD | Professional investors; quarterly payouts |
| 3 | Class C — institutional, EUR | Institutions only; higher minimums |
| 4 | Founder / GP units | Non-transferable until exit |
Each ID carries its own lock and payout logic, while investor approvals, wallets and governance are shared. This is the main advantage of building securities on ERC-1155: one contract mirrors the full share-class structure.
Off-chain compliance approvals: how they work
A common pattern in dynamic-compliance designs:
- The investor requests a transfer through the platform.
- A compliance service evaluates the rules (eligibility, limits, sanctions) off-chain.
- If approved, the service signs a short-lived approval covering sender, receiver, ID, amount and expiry.
- The transfer transaction includes the signature; the contract verifies the signer and expiry before executing.
Benefits: rules can change without redeploying contracts; complex checks run off-chain. Risks: availability of the signing service, key compromise and replay — mitigated with nonces, expiries, HSM-held keys and monitoring.
Interoperability through wrapping
Moving a security token to another chain is not just a technical bridge; the compliance guarantees must travel too. Wrapping designs lock or burn the original and issue a representation elsewhere, ideally with the same eligibility enforcement on the destination chain. Evaluate custody of locked tokens, bridge security and how the legal register is updated.
Frequently asked questions
It is a proposal under discussion in the ERC process. Always check the current status at eips.ethereum.org.
ERC-1155 lets multiple classes or tranches live in one contract with batch operations, which suits instruments with many partitions.
Not directly, but naming alignment through ERC-7943 helps integrators support both with similar logic.
No. Compliance decisions can be made off-chain and supplied as signed approvals; personal data should stay off-chain.
The standard does not mandate a specific identity system; implementations can integrate claim-based identity if desired.
Payout functions distribute to holders of a specific token ID, so each class can follow its own schedule.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
