ERC-7518 (DyCIST) Security Audit Checklist

ERC-7518, also called DyCIST, is a security-token standard built on ERC-1155. Instead of one balance per holder, it splits a token into partitions, one per tokenId, where each partition is its own class of asset with its own rules: its own lockups, its own transfer restrictions, its own compliance. On top of that it adds the machinery regulated assets need, time locks, address freezing, forced transfers for recovery and legal orders, bulk payouts, and dynamic compliance driven by signed off-chain vouchers.

That flexibility is the point, and it is also the risk. Every transfer has to pass a compliance gate, a handful of admin roles can move or freeze other people's assets, and eligibility often rests on a signed voucher that has to be validated exactly right. Get any of those wrong and you either lock legitimate holders out or let ineligible ones in.

This checklist walks DyCIST one concern at a time. Each item is something to confirm during a review, written so you can hand it to an auditor who is new to the standard. If you want a refresher on the interface and partition model first, our ERC-7518 standard breakdown covers the functions and RWA framing in detail.

Treat this as a floor, not a ceiling. A real engagement still needs manual review, fuzzing around the lock and partition math, and a threat model built around the issuer's specific compliance rules and voucher scheme.

How the token is put together

Here is the whole idea in one picture. A single contract holds many partitions. Within a partition, balances are fungible fractional units, but each partition carries its own lock, restriction, and compliance state. Every ordinary transfer is forced through a compliance gate before it settles.

Almost every item below is one question asked from a different angle: can a transfer skip the gate, can a lock be dodged, or can an admin power be misused or reached by the wrong caller.

Before you start

DyCIST is only as safe as its compliance gate and the voucher scheme behind it. Get both clear before reading the token logic.

Spec and compliance rules understood. You know what each partition represents, which regulatory regime it maps to, and what makes a transfer eligible or not.
Partitions mapped. You have the list of partitions, their lock and restriction state, and how tokens are meant to move between or merge across them.
Voucher scheme understood. You know who signs compliance vouchers, what fields they carry, and how they expire, since this is where the subtle bugs live.
Roles mapped. You have every privileged role, what each can do, and whether each sits behind a multisig or a single key.

The transfer and compliance gate

Every ordinary transfer runs through canTransfer before safeTransferFrom moves anything. If a single path skips that gate, the entire compliance model is bypassed.

Every transfer path goes through the gate. safeTransferFrom and the batch transfer both run canTransfer, and there is no inherited ERC-1155 path that moves tokens without it.
The gate checks everything it should. It rejects frozen sender or receiver, a restricted partition, an amount above the transferable balance, and a failed voucher or eligibility check.
Transferable balance is enforced, not just displayed. Transfers use balanceOf minus lockedBalanceOf, so locked tokens truly cannot move even if a caller passes a larger amount.
The receiver is checked too. Eligibility applies to who is receiving, not only who is sending, so tokens cannot land on an ineligible or frozen address.
Batch transfers are consistent. A batch of transfers across ids and amounts runs the same checks per item, with matching array lengths, and cannot smuggle one disallowed leg through.

Partitions and locks

Partitions and time locks are the accounting backbone. An off-by-one in the lock math or a partition mix-up can dilute holders or freeze valid transfers.

Locks respect the balance. You cannot lock more than an account holds in a partition, and unlocking cannot drive the locked amount below zero.
Lock accounting is per account and per partition. A lock on one holder's partition does not affect another holder or another partition, and release times are tracked so they cannot collide.
Unlock only releases what is due. unlockToken frees tokens whose release time has actually passed, and a batch unlock cannot release someone else's still-locked balance.
The core invariant holds. Total locked never exceeds total supply in a partition, across mint, burn, transfer, force transfer, and merge operations.
Partition merges are safe. If partitions can be recombined once lockups expire, the merge preserves total balances, carries over any remaining locks, and cannot mint or destroy value.
Restriction toggles are guarded. restrictTransfer and removeRestriction are access-controlled, emit their events, and a removed restriction does not silently unlock a separate time lock.

Vouchers and dynamic compliance

Eligibility often rests on a signed EIP-712 voucher passed in the transfer data. This is the highest-value target in the whole standard, since a replayable or forgeable voucher is a bypass of the entire compliance layer.

Signatures recover to a trusted signer. Voucher validation recovers the signer and checks it against the expected attestor, with no shortcut that accepts an arbitrary signer.
Vouchers cannot be replayed. Each voucher carries a nonce that is consumed on use and an expiry that is enforced, so it cannot be reused within or across transactions.
Vouchers are scoped to their transfer. The signed data binds the specific holder, partition, amount, and intent, so a voucher issued for one context cannot satisfy another.
Domain binding prevents cross-chain and cross-contract reuse. The EIP-712 domain ties the voucher to this chain and this contract, so the same signature cannot be replayed on another deployment.
The EIP-712 encoding is exact. The type hash and struct encoding follow the standard, so validation matches what standard signing tools produce and cannot be tricked by a malformed payload.
Any oracle or registry input is validated. If eligibility also reads a KYC registry or oracle, that read is checked for staleness and sane values, and does not itself become a manipulation vector.

Freezing and address controls

Freezing blocks an address from moving or receiving assets. It has to be complete, so a frozen account cannot slip value out a side door, and reversible only by the right role.

Freeze blocks every path. A frozen address cannot send, cannot receive, and cannot collect a payout, and there is no transfer or claim route that ignores the freeze.
Freeze and unfreeze are access-controlled. Only the intended compliance role can freeze or unfreeze, and both emit their events with the reason data for auditability.
Freeze interacts correctly with locks and force transfer. A frozen account's locked balances and forced transfers behave as intended, with no state left inconsistent after a freeze is lifted.

Forced transfers and admin powers

Forced transfer and the surrounding admin functions can move other people's assets. The audit has to be clear-eyed about who holds that power and how it is contained.

Force transfer is tightly gated. Only the intended admin role can call it, the authorization condition is correct, and it emits its dedicated event every time for transparency.
Force transfer still lands somewhere valid. The destination is a legitimate, eligible address, and the operation keeps locked balances and partition accounting consistent afterward.
Roles are separated and least-privileged. Minting, locking, freezing, force transfer, and rule changes map to distinct roles, and no operational key holds more power than it needs.
The powerful actions sit behind stronger authorization. Force transfer, freezing, and partition rule changes are behind a multisig or timelock, and the trust assumptions are documented plainly for holders.
No privileged function is unguarded. Every function that should be restricted actually is. Compare sibling functions across the contract and flag any missing a role check.

Payouts and distributions

Bulk payouts push income to many holders at once. The risk is paying a frozen or ineligible address, paying the wrong amount, or a batch that can be griefed into failing.

Payouts respect freezes and eligibility. A frozen or ineligible recipient does not receive a payout, matching the transfer rules.
Amounts and arrays are validated. Recipient and amount arrays are the same length, and the issuer has enough balance to cover the full batch before it starts.
Distribution is pro rata and precise. Where payouts are proportional to holdings, the math rounds sensibly and dust does not accumulate or let one recipient take more than their share.
Large batches cannot be griefed or run out of gas. A single bad recipient cannot make the whole batch revert in a way that blocks all distributions, and batch size is bounded.

Cross-chain and interoperability

DyCIST is meant to move across chains and protocols. Wrapping and bridging partitions is where vouchers and token state get reused in ways that mint or duplicate value.

Cross-chain messages cannot be replayed. Bridge messages and any vouchers they carry include a nonce and are consumed once, so the same proof cannot mint or unlock twice.
Wrapping preserves partition integrity. Moving a token across chains recreates the correct partition and its rules without duplicating balances or creating an unauthorized mint.
Burn and mint flows verify proofs. A mint on the destination chain is backed by a verified burn on the source, not by an unchecked message.
Cross-chain state is logged. Transitions emit events so the movement can be reconciled and audited across chains.

General smart contract hygiene

The ERC-1155 fundamentals still apply underneath all of this, and a regulated asset is a bad place to skip them.

ERC-1155 receiver and hooks are handled. Transfers to contracts respect the receiver interface, and any transfer hook or callback cannot re-enter a sensitive path.
View functions stay pure and non-reverting. transferableBalance, lockedBalanceOf, and canTransfer behave as safe views, so integrators and front ends can rely on them.
Events cover every state change. Locks, unlocks, freezes, restrictions, forced transfers, and payouts all emit their events, since monitoring and off-chain compliance depend on them.
Casts and bounds are safe. Amount and timestamp casts cannot silently truncate, and array-driven functions cannot run out of bounds.
The tricky math is fuzzed. Property tests cover lock and unlock edges, partition merges, the total-locked invariant, and voucher expiry and replay.

Where to go from here

Use this list as the structural pass, then dig deeper where a given engagement calls for it. Our interactive Tokenization 101 is the natural companion, showing where ERC-7518 sits among RWA standards for partitioned and semi-fungible offerings, calling out the audit angle for each, and cataloging the incidents that have actually broken these systems. For the deeper reference, the RWA Development Handbook covers the DyCIST interface alongside the identity, compliance, and settlement layers these tokens depend on, including the ERC-3643 and ERC-7943 standards teams often pair it with.