Lower gas on every on-chain operation
DALP 3.0 optimizes the hot path: identity verification up to 40% cheaper, a supply-cap mint saves about 146,000 gas, and compliance checks run in constant time.
We re-cut the hot path across all digital assets: identity checks, compliance modules, supply caps, proxies, and yield accrual. The operations you run thousands of times now cost less gas, with no change to how they behave.
On a blockchain, gas is the unit of computational work. Every storage read, each conditional branch, each external call burns a metered amount of it. You pay that cost whether a transaction succeeds or fails, and the fee is proportional to how much work the EVM actually does. The design of a smart contract determines how much work that is.
Regulated token programs run more on-chain logic than ordinary ERC-20 tokens. A single transfer triggers identity verification, one or more compliance-module checks, supply-cap accounting, and proxy dispatch. Each piece of logic reads from contract storage. Those reads are the most expensive EVM operations by a wide margin: a cold storage slot costs 2,100 gas units, and a warm read 100. Multiply by the number of checks per transfer and the number of transfers per day, and the cost profile becomes clear.
Repeated checks add gas cost on every relevant transaction. The release removes redundant work from these paths.
DALP 3.0 cuts the gas cost of the most-run compliance checks without changing what they enforce
On a compliance platform, the expensive operations are the ones the chain enforces on every transfer: identity verification, compliance-module checks, and supply caps. Those costs compound with volume. A book that settles thousands of transfers a day pays them thousands of times. DALP 3.0 makes the most-run paths cheaper without touching what they do.
- Approach
- Hot-path
- Behavior
- Unchanged
- Supply caps
- Bounded history reads
- Identity checks
- Fewer storage reads
What got cheaper
The release reduces repeated storage reads and list scans in the paths described here.
These are not micro-savings on a rarely-touched path. Identity verification and compliance checks run on each transfer; proxy resolution runs on each call to each token. A reduction there is a reduction on the whole book: mints, redemptions, yield accruals, transfers past and future.
Why it compounds
The standard way to write compliance controls in Solidity is convenient and quietly expensive. An allowlist is often stored as an array. Checking membership means scanning the array from start to end: one storage read per entry, every time. With ten entries that is ten reads. With a hundred it is a hundred. The cost grows with the list, and the list grows as the program matures.
Supply-window enforcement follows the same pattern. A rolling cap on minted volume can be implemented by replaying the mint history for the relevant window on each new mint. Every check rewrites the same arithmetic from the beginning.
Proxy dispatch adds a fixed overhead to each call. A typed implementation proxy resolves the implementation contract through a chain of storage reads before it can delegatecall the actual logic. That overhead applied to each operation on each token, across the full holder set.
Each optimization below targets one of these patterns: it replaces a data structure or access pattern that grows proportionally with data size or history length with one that takes the same number of steps regardless. The logic, the outcomes, and the rule enforcement are identical. The chain just does less work to reach the same answer.
- 1Compliance in constant time
The six list-based compliance modules (jurisdiction, issuer, and address allow/block lists) now resolve membership in O(1) instead of scanning the full list on every transfer.
- 2Supply caps without the scan
The rolling-window supply check reads in constant storage rather than recomputing from history.
- 3Cheaper identity checks
Per-transfer identity verification and identity-proxy resolution were re-cut to remove redundant work on the hot path.
- 4Leaner proxies
Every call routed through a token or identity proxy carries less fixed overhead, so the saving lands on all of them.
Compliance in constant time
Six compliance modules enforce list-based rules: country and address allow/block lists, plus the identity allow and block list variants. Before this release, each resolved membership by decoding and scanning the list on each check. The new implementation stores each entry in a hash mapping. Checking whether an address or country code is present becomes a single storage read at a fixed key, regardless of list length. Cost no longer grows as the program adds jurisdictions or investors.
Supply caps without the scan
The rolling-window supply cap enforces a maximum mint volume over a trailing period. The previous implementation accumulated mint records and summed them on each new mint to compute the running total. We replaced that with a circular buffer indexed by calendar day. The buffer has a fixed number of slots; each mint writes to the slot for the current day using a modulo index. Reading the window total requires the same number of reads regardless of how long the program has been running or how many mints have occurred. The read count no longer grows with the total number of historical mints.
Faster identity checks
Each transfer on a regulated token triggers verification: the contract checks that the recipient has a registered identity and that any required claims are valid. The resolution chain previously reread storage across multiple hops to reach the implementation. We removed the redundant reads. Both verification and proxy resolution perform fewer repeated reads.
Leaner proxies
Each token operation routes through a proxy. It resolves to an implementation via a typed dispatch chain, and the overhead of that chain appeared on each call. We tightened the dispatch path. Calls through the changed proxy path use fewer repeated reads.
Compatibility
Review the implementation version and applicable audit before upgrading contracts. A gas improvement does not itself establish that a previous audit covers a new implementation.