ERC-7518 is a Standards Track ERC in Review. The published EIP is the current source of truth and may change through peer review. The reference implementation is provided for testing and evaluation.
Join the discussion Read the EIP
Standards Track ERC · Review

Build regulated, partitioned assets on ERC-7518.

ERC-7518 defines a common interface for real-world and regulated assets that need multiple classes or partitions, transfer validation, locked balances, address controls, recovery, payouts, and token wrapping.

Each ERC-1155 tokenId is a partition with its own balances and rules. Keep familiar ERC-1155 accounting; add a standardized control surface for the whole asset lifecycle.

Read the specification Run the reference implementation

Reviewing the ERC? Discuss ERC-7518 on Ethereum Magicians

Understand

What ERC-7518 adds on top of ERC-1155

Multi-token accounting stays the same. ERC-7518 layers a policy-aware control surface for the lifecycle of a regulated or structured asset.

Partition-native modeling

Use a tokenId as the fundamental partition, a share class, series, jurisdiction, tranche, or property unit. Units are fungible within a partition and distinct across partitions.

balanceOf(account, id)

Transfer validation

Preflight a state-changing transfer against contract state, issuer policy, on-chain registries, oracle results, or an application-defined signed voucher supplied in data.

canTransfer(from, to, id, amount, data)

Locked & transferable balances

Read total balance alongside locked and transferable amounts. Apply holding periods, vesting, and time-based restrictions without leaving the ledger.

lockedBalanceOftransferableBalancelockTokensunlockToken

Administrative controls

Partition restrictions, address freezing, and authorized forced transfers for lifecycle events that general-purpose bearer tokens do not standardize.

restrictTransferfreezeAddressforceTransfer

Payout operations

Standardized distribution calls for interest, dividends, or rental income. Implementations define the payment asset, authorization, accounting, and failure behavior.

payout(to, amount)batchPayout(to[], amount[])

Wrapping & interoperability

Lock an original asset, mint an ERC-7518 representation, and reverse it. Cross-chain deployment still needs bridge, messaging, custody, and replay protection outside the core standard.

wrapTokenwrapTokenFromPartitionunwrapToken
Real-world assets

What it means to bring real-world assets on-chain

A real-world asset (RWA) is any off-chain instrument of value — private credit, a fund interest, a building, a treasury bill, an invoice, a carbon credit — represented on a blockchain as a token. Tokenizing it does not change what the asset is; it changes how ownership is issued, transferred, serviced, and settled.

Most of these assets are regulated. Who may hold them, how long they must be held, which jurisdictions they can move between, and who can force a recovery are not optional details — they are the asset. A plain bearer token cannot express any of that. ERC-7518 exists to give regulated RWAs a common on-chain control surface: partitions for share classes and series, transfer validation for eligibility, locked balances for holding periods, and administrative operations for the events that happen across an asset’s life. The commercial platform that implements this end to end is built by Zoniqx.

Why issuers tokenize

Fractional access

Represent a large, illiquid asset as many partitioned units, lowering minimums and opening distribution to a wider set of eligible investors.

partitionstokenId

Programmable compliance

Eligibility, lock-ups, and transfer rules are enforced by the contract at execution rather than tracked in a spreadsheet after the fact.

canTransferrestrictTransferlockTokens

Operational efficiency

Issuance, holder records, payouts, and reporting live in one system, reducing intermediaries and the reconciliation gaps between them.

payoutbatchPayout

Interoperability

A standardized interface lets the same asset be read, held, and moved across compliant wallets, custodians, indexers, and venues.

ERC-1155ERC-165wrapToken

The tokenization lifecycle

From structuring an asset to settling a trade, in four stages. Zoniqx spans the full path — z360 for issuance and lifecycle, zConnect for distribution.

1

Structure

Define the asset, terms, documents, eligibility rules, and jurisdiction. Each share class, series, or tranche is assigned its own partition before anything is minted.

2

Tokenize

Mint on-chain with ERC-7518 lifecycle rules: partitioned balances, transfer validation, locked and transferable amounts, and the events indexers rely on.

3

Distribute

Route the asset to eligible channels — broker-dealers, RIAs, wealth platforms, and vault strategies — where discovery stays open and compliance activates at execution.

4

Service & settle

Run payouts, notices, redemptions, freezes, recoveries, and corporate actions across the asset’s life, with settlement recorded on-chain.

Asset classes being tokenized today

Each maps cleanly onto ERC-7518 primitives. See how they run in production on the Zoniqx customer stories.

Private credit & debt

Note series, tranches, and maturities as partitions, with holding periods and scheduled payouts.

restrictionslockspayout

Tokenized treasuries

Short-duration government instruments and money-market strategies with eligibility-gated transfers.

partitionscanTransfer

Commercial real estate

One contract per property; floors, units, or offering series as separate partitions of fractional interest.

partitionsbatchPayout

Funds & private equity

Class A, Class B, and institutional share classes as distinct partitions in a single fund contract.

eligibilitylocks

Infrastructure & energy

Long-duration and project-finance assets with staged access and jurisdiction-aware distribution.

partition policyrecovery

Carbon credits & ESG

Registry-linked units where provenance, retirement, and transfer eligibility matter as much as balance.

canTransferevents
Explore Zoniqx solutions See live issuances Map assets to primitives
Architecture at a glance

Five ideas that describe the whole model

Read top to bottom. Each step builds on the one before it.

1

ERC-1155 is the balance layer

ERC-7518 requires ERC-1155 and ERC-165. Standard balances, approvals, transfers, and receiver checks remain the foundation.

2

Each token ID is a partition

The meaning and rights of a partition are defined by the issuer and its documentation. ERC-7518 provides the control interface, not a universal metadata schema for legal rights.

3

Transfers pass a policy gate

Before updating balances, the implementation evaluates whether sender, recipient, partition, amount, lock state, and supplied data satisfy its transfer policy.

4

Privileged operations model the lifecycle

Authorized roles may lock balances, restrict a partition, freeze an address, execute recovery transfers, or initiate payouts. The EIP requires the behavior; each implementation must define and secure its authorization model.

5

Events expose state to off-chain systems

Indexers and operations systems monitor lock, unlock, freeze, restriction, forced-transfer, payout, and wrapping events alongside ERC-1155 transfer events.

Specification

The interface, organized by developer task

The published ERC defines IERC7518 over ERC-1155 and ERC-165, plus IERC1155Wrapper. This page is an explanatory index. The EIP remains the normative source. Click any signature to copy it.

Read methods view / preflight
FunctionWhat developers use it for
transferableBalance(account, id)copyRead the amount currently available to transfer.
lockedBalanceOf(account, id)copyRead the locked amount for an account and partition.
canTransfer(from, to, id, amount, data)copyPreflight the current transfer policy before submitting.
Transfer & partition controls state-changing
FunctionWhat developers use it for
safeTransferFrom(from, to, id, value, data)copyTransfer ERC-1155 units after the ERC-7518 policy check.
restrictTransfer(id)copyRestrict transfers for a partition.
removeRestriction(id)copyRemove a previously applied partition restriction.
lockTokens(account, id, amount, releaseTime)copyLock a quantity until a defined release time.
unlockToken(account, id)copyRelease an eligible locked balance.
Account & recovery controls privileged
FunctionWhat developers use it for
freezeAddress(account, data)copyFreeze an account under the implementation's policy.
unFreeze(account, data)copyRemove the account freeze.
forceTransfer(from, to, id, amount, data)copyExecute an authorized transfer outside the ordinary holder-initiated path.
Distribution payout
payout(to, amount)copyDeliver one payout.
batchPayout(to[], amount[])copyDeliver multiple payouts in one operation.
Wrapper IERC1155Wrapper
setWrappedTokenAddress(token)copyConfigure the source token supported by the wrapper.
wrapToken(amount, data)copyLock a source token and mint its representation.
unwrapToken(wrappedTokenId, amount, data)copyBurn the wrapped representation and release the source.

Events, grouped for indexers

Balance & transfer

TransferSingleTransferBatch

The primary balance-change events from ERC-1155.

Lock state

TokensLockedTokenUnlocked

Signal changes to locked-balance state.

Enforcement

AddressFrozenAddressUnfrozenTransferRestrictedTransferRestrictionRemovedTokensForceTransferred

Expose administrative lifecycle actions.

Distribution & wrapper

PayoutDelivered

Supports payout reconciliation. Wrapper events expose source-token config and wrap/unwrap activity; reconcile with ERC-1155 mint and burn.

Normative vs. implementation-defined

Defined by the EIP

  • Required base interfaces
  • Public function signatures
  • Required / recommended behavior (RFC 2119 terms)
  • The partition model
  • The transfer-validation hook
  • Lifecycle operations
  • The wrapper flow

Defined by each implementation

  • Role names and authorization hierarchy
  • Partition metadata and legal-document links
  • Compliance-policy logic
  • Voucher format and signing rules
  • Revert errors and reason codes
  • Payout asset and funding model
  • Upgradeability, governance, pause procedures
  • Bridge / cross-chain design and key controls
Read the normative EIP Open the reference interface Review open questions
Transfer lifecycle

From transfer intent to final settlement

An ERC-7518 transfer is a policy decision followed by an ERC-1155 state transition. The key point: canTransfer is checked during execution, not only in the interface.

Application / Compliance service ERC-7518 contract / ERC-1155 ledger
step 01

Build the transfer request

Identify sender, recipient, partition ID, amount, and any application-defined data.

step 02

Obtain policy data when required

A compliance service evaluates current policy and returns signed data scoped to the intended transfer.

step 03 · policy gate

Preflight with canTransfer

Check current contract state and supplied data before asking the user to submit.

step 04

Submit safeTransferFrom

Same parties, partition, amount, and data. A previous read is not a guarantee: state may change before mining.

step 05 · re-checked

Validate, update balances, emit

Eligibility is evaluated again during execution. On success, balances update and the transfer event is emitted.

step 06

Reconcile off-chain state

Indexers, custodians, and issuer systems process the confirmed event. Treat reorgs and confirmation depth as integration concerns.

Build · Quickstart

Run the reference implementation locally

The public reference uses Solidity and Foundry. Use it to inspect contract flow, run experiments, and find gaps between the EIP and executable behavior.

terminal: clone, build, test
# requires git + Foundry (forge, cast, anvil)
git clone https://github.com/zoniqx/erc7518_reference.git
cd erc7518_reference
forge install
forge build
forge test -vvv

repository map

  • erc1155mod.sol: partition ledger; each tokenId carries balances, mint, burn, transfer.
  • erc7518.sol: control surface, pre-transfer logic, wrapping / unwrapping.
  • STObasev2.sol: example offering & settlement; app logic, not a required interface.

first implementation checklist

  • Route every transfer entry point through the same eligibility rules.
  • Keep total, locked, and transferable balances consistent.
  • Protect privileged operations with explicit access control.
  • Maintain wrapper backing through mint, burn, and release.
  • Add unit, fuzz, invariant, and integration tests.

Suggested evaluation sequence

1

Run the full test suite unmodified

Establish a baseline before changing anything.

2

Trace one mint and ordinary transfer

Follow a single partition through the ledger.

3

Lock, then compare balances

Lock part of a holder's balance and compare total, locked, and transferable amounts.

4

Restrict, freeze, and force

Restrict a partition and confirm the transfer path fails; freeze an account and test send, receive, forced-transfer, and payout behavior.

5

Wrap, unwrap, and diff the spec

Check reserve backing through wrap/unwrap, then compare observed behavior with the current EIP requirements.

Integrate by system role

Integrations are not all the same

A wallet needs safe transfer UX. A custodian needs controls and reconciliation. An indexer needs complete state reconstruction. A compliance service needs exact message binding and reliable authorization.

Show holders truthful, actionable balances, and never present total balance as fully spendable.

read

  • Partition balance
  • Locked balance
  • Transferable balance
  • Partition restriction state, if exposed
  • Eligibility via canTransfer

before submission

  • Collect required policy data / voucher
  • Call canTransfer with exact values
  • Show that preflight success can still fail
  • Estimate gas on final calldata
  • Explain locked balances plainly

after submission

  • Monitor the transfer event
  • Surface reverts in plain language
  • Refresh total, locked, transferable
  • Wait for required confirmation depth

Treat each partition as its own asset and keep legal authority outside the token UI.

asset keys

  • Identify every partition independently
  • Store contract address, chain ID, token ID

reconcile

  • Preflight deposits and withdrawals
  • Separate forced from holder-initiated transfers
  • Monitor freeze, restriction, lock, unlock events

procedure

  • Define privileged-action request flow
  • Keep legal authority & approval off-chain

Reconstruct complete state: never infer transferable balance from the ERC-1155 balance alone.

index the base layer

  • TransferSingle / TransferBatch for balances and supply

index the control layer

  • Lock, unlock, freeze, restriction
  • Forced-transfer, payout, wrapper events

reconciliation rules

  • Retain partition ID on every record
  • Label administrative transfers distinctly
  • Reconcile wrapper mint/burn with vault movement
  • Handle reorgs and event replay safely

Define what each partition means, then map it to narrowly scoped, auditable permissions.

define

  • Legal and technical meaning of each partition
  • Version policy and metadata

authorize

  • Map roles to scoped contract permissions
  • Require multi-party approval for high-risk ops
  • Record reason & authority for freezes and forced transfers

operate

  • Manage payout funding and reconciliation
  • Publish contract addresses and versions

Bind every signature to the exact intent, chain, and contract, and never fail open.

evaluate

  • Score the exact transfer intent, not a partial request
  • Log policy version and decision evidence

sign

  • Bind data to chain and contract
  • Use short, explicit validity windows
  • Prevent replay

operate

  • Support signer rotation and emergency revocation
  • Survive outages without an unsafe fail-open path
Security & conformance

Verify behavior before claiming compatibility

ERC-7518 includes operations that can move, restrict, or release regulated assets. Compatibility requires more than compiling the interface.

Privileged access

Force transfer, freeze, locks, restrictions, payouts, and wrapper config can materially affect holders. Use least-privilege roles, protect keys, emit complete events, and consider multisig or delayed governance.

Transfer-path consistency

Every relevant route must enforce the same policy. Test single and batch, operator transfers, mint, burn, forced transfers, wrapping, and settlement paths separately.

Lock accounting

Locked balances must never exceed total or drift after burns, forced transfers, merges, or wraps. Use invariant tests for total, locked, and transferable amounts.

Voucher security

Prevent replay across chains, contracts, users, partitions, amounts, and time. Validate signer authority at execution and document fail-open vs. fail-closed behavior.

Reentrancy & hooks

Safe transfers, payouts, and wrapper flows can call external contracts. Apply checks-effects-interactions and reentrancy protection where appropriate.

Wrapper backing

Wrapped supply must remain consistent with locked reserves. Test fee-on-transfer tokens, callbacks, decimal conversion, partial unwraps, and recovery assumptions.

Core conformance checklist

  • Supports required ERC-1155 and ERC-165 behavior
  • Exposes the current published ERC-7518 interface
  • Calculates transferable balance consistently with locked
  • Rejects ordinary transfers that fail canTransfer
  • Enforces partition restrictions
  • Enforces address freeze behavior as documented
  • Applies lock and unlock rules correctly
  • Restricts forced transfer and privileged operations
  • Emits the required lifecycle events
  • Implements payout calls with documented semantics
  • Preserves wrapper backing if the wrapper is claimed
  • Identifies the exact EIP revision and commit tested

Compatibility labels: be precise

Interface implemented

Identifies the revision and supported interface.

Reference derived

States that code is based on the public reference repository.

Test vectors passed

Links to the exact suite, version, and results.

Audited   Production

Audited links to a public report, scope, commit, and unresolved findings. Production links to verified addresses and the implementation version. Never use "compliant," "secure," or "audited" without defined scope and evidence.

Use cases

Map asset requirements to ERC-7518 primitives

Technical modeling patterns, not legal structures, and no guarantee that a given issuance satisfies regulation.

Commercial real estate

One contract per property. Each floor, unit, class, or series is a separate tokenId; units are fractional interests.

partitionslockscanTransferpayout

Reg S / Reg D issuance

Separate partition IDs represent different exemptions or holder categories, with explicit conversion into later partitions.

partition policyrestrictTransferlocks

Multi-class funds

Class A, Class B, and institutional share classes as separate partitions in one contract.

partitionseligibilitybatchPayout

Private credit & debt

Note series, tranches, maturities, or closing cohorts map to partition IDs.

restrictionsholding periodspayoutrecovery

Recovery & enforcement

An authorized role freezes an affected address and moves assets to an approved control address.

freezeAddressforceTransferunFreeze

Cross-standard representation

A source token is locked and represented as an ERC-7518 partition, then burned when released.

wrapTokenwrapTokenFromPartitionunwrapToken

Where ERC-7518 fits among standards

StandardPrimary modelRelationship to ERC-7518
ERC-165Interface detectionRequired. Use it to detect supported interfaces.
ERC-1155Multi-token balancesRequired base. ERC-7518 uses each token ID as a partition.
ERC-20Single fungible tokenA source or destination representation handled through the wrapper.
ERC-721Non-fungible tokenA source may be wrapped, subject to explicit mapping and backing.
ERC-1400 / 1410Security-token partitionsDesign lineage; behavior is not automatically identical.
ERC-3643Permissioned token, identity-ledComplementary; the wrapper can reference another security-token contract.
ERC-7943Minimal universal RWA controlsComplementary. Claim only when the relevant interface is implemented and detected.
Status & contribute

Review ERC-7518 in the open

ERC-7518 is a Standards Track ERC in Review. The published EIP is the current source of truth; review can lead to clarifications or interface changes, so identify the exact revision you follow.

Review the interface

Look for ambiguous signatures, missing state transitions, inconsistent event semantics, and behavior that cannot be implemented safely.

Run the code

Build the reference repository and reduce any unexpected behavior to a reproducible test.

Test an integration

Try wallet preflight, custody reconciliation, indexer state reconstruction, compliance authorization, or wrapping. Document where the interface lacks information.

Submit focused feedback

The EIP section or function · observed vs. expected behavior · a minimal example or test · integration or security impact · a concrete proposed clarification.

Join Ethereum Magicians Open GitHub issues View EIP history
FAQ

Developer questions, answered plainly

ERC-7518, also called DyCIST, is a proposed Ethereum standard for regulated and structured assets. It extends ERC-1155 with partition-aware transfer validation, locked-balance queries, address and partition controls, forced transfer, payout operations, and a wrapper interface.
A Standards Track ERC in Review, not Final. Use the published EIP as the source of truth and identify the revision you implement.
ERC-1155 supports multiple token IDs and amount-based balances in one contract. ERC-7518 uses each tokenId as a partition, which fits assets with multiple classes, series, tranches, jurisdictions, or fractional units.
Related, but ERC-7518 expresses partitions through ERC-1155 token IDs. Follow ERC-7518's published interface and don't assume one-to-one behavior with another partitioned-token standard.
No. The EIP permits signed off-chain vouchers, on-chain rules, oracle results, or combinations. The voucher schema and policy content are application-defined in the current EIP.
No. State can change between a read call and execution. The implementation must validate eligibility again in the state-changing transfer path.
No. It defines a transfer-validation hook and lifecycle controls. An implementation can connect those to an on-chain registry, allowlist, compliance service, or other policy system.
No. It provides technical primitives for a compliance architecture. Legal classification, eligibility, disclosures, licensing, recordkeeping, and jurisdictional obligations remain outside the standard.
No. The wrapper interface converts between token representations. A cross-chain system also needs secure messaging, bridge or custody design, replay protection, and operational controls.
Use ERC-165 against the interface ID for the exact revision you support. Publish verified, versioned interface IDs rather than a single unversioned constant while the ERC is in Review.
Treat it as a reference and evaluation tool. Before production, review its license, dependencies, access controls, upgrade assumptions, tests, deployment config, and audit status; and obtain independent review of your exact code.
The team behind the standard

ERC-7518 was authored by Zoniqx

Zoniqx is a Silicon Valley tokenization-infrastructure company. Its contributors authored ERC-7518 (DyCIST) and released it to the Ethereum community under CC0. This site documents the open standard; Zoniqx builds the commercial platform that implements it end to end.

$5.1B
Assets on infrastructure
reported by Zoniqx
20+
Live issuances
reported by Zoniqx
14+
Live blockchains
reported by Zoniqx
7
Jurisdictions
reported by Zoniqx

Two products, one network

z360 — issuance & lifecycle

For issuers structuring real-world assets for compliant tokenization and ongoing operations.

  • Templates for private credit, funds, real estate, and yield products
  • Structuring, documents, compliance checks, and approvals in one place
  • Lifecycle operations: payouts, notices, redemptions, holder records
  • Configurable across ERC-3643 and ERC-7518 standards
Explore z360

zConnect — unified distribution

The aggregation layer connecting tokenized supply to institutional distribution channels.

  • Discovery across broker-dealers, RIAs, wealth platforms, and vaults
  • Singular KYC/KYB: authenticate once, accepted network-wide
  • Compliance routing activates at execution; discovery stays open
  • Non-custodial settlement via participant-controlled wallets
Explore zConnect

Ecosystem & recognition

Ecosystem partners

Networks, infrastructure providers, and platforms connected across the Zoniqx ecosystem.

PwCPwC
RubixRubix
AWSAWS
CoinbaseCoinbase
VeriffVeriff
RippleRipple
XRP LedgerXRP Ledger
HederaHedera
ChainlinkChainlink
MidnightMidnight
PolygonPolygon
CardanoCardano
InjectiveInjective
LACChainLACChain
StabilityStability
NexeraNexera
SerproSerpro
KimaKima
HifiHifi
ChangellyChangelly
ZodiaZodia
PalisadePalisade
DFNSDFNS
RimarkRimark
Explore the Zoniqx platform Tokenize an asset Meet the team

Figures, partnerships, and recognitions in this section are Zoniqx’s own and are point-in-time. ERC7518.org is an independent technical home for the open standard and does not endorse any commercial implementation. See zoniqx.com for current details.

Resources

Source material for implementers and reviewers

Use these in order: the published EIP first, then active review, then the reference implementation, then this site.

specification · normative

EIP-7518

Motivation, interfaces, required behavior, rationale, compatibility, and security considerations.

eips.ethereum.org
review · discussion

Ethereum Magicians

The public forum for design questions and review feedback.

ethereum-magicians.org
code · Solidity + Foundry

Reference implementation

Executable reference maintained by Zoniqx. An implementation aid, not a substitute for the EIP or an audit.

github.com/zoniqx
community · contributing

Contribution guide

Repository instructions for issues, changes, testing, and responsible disclosure.

CONTRIBUTING.md
commercial · platform

Zoniqx platform

The commercial TPaaS that implements ERC-7518 end to end — z360 for issuance and lifecycle, zConnect for distribution.

zoniqx.com
commercial · issuance

z360 & zConnect

Structure, tokenize, distribute, and service real-world assets across compliant institutional channels.

zoniqx.com/z-360

Read it. Run it. Review it.

ERC-7518 is being developed in public. The most useful contribution is reproducible technical feedback: an interface ambiguity, a failing test, an integration edge case, or a security concern.

Read EIP-7518 Run the tests Join the discussion
Learn Real-World Assets Specification Build Integrate Security Use Cases Built by Zoniqx Resources Zoniqx.com Discuss the Standard