Lower gas on every on-chain operation

We re-cut the hot path of every tokenized asset: 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, every conditional branch, every 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. Storage reads are the most expensive EVM operations by a wide margin: a cold storage slot read 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.

On a quiet book, none of this matters. On an active one, where transfers run continuously across a growing holder set, it becomes the dominant operating cost. We went into the contracts and removed the work the chain was doing that did not need to happen.

What got cheaper

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.

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. That change saves up to approximately 146,000 gas on a capped mint.

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. Per-transfer verification is up to 40% less expensive; proxy resolution is up to 42% less expensive.

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. The saving is 16% on each routed call, which means mints, transfers, redemptions, and compliance checks all inherit it automatically.

Compatibility

For audited and frozen contracts, the "same behavior" guarantee is not a convenience claim: it is the only way these savings can ship. Audited contracts carry a reviewed, signed-off set of rules. We do not touch what they enforce, only the implementation efficiency behind it. A frozen contract stays frozen; its audit remains valid; its behavior under compliance review is unchanged. The savings arrive through the infrastructure beneath, not through any change to the logic an auditor has already signed off.

Explore the asset contracts →