N-VM shared state

This page explains why a token issued on ACE is usable from multiple virtual machines at once — the idea behind "one ledger, many execution worlds."

The problem on most chains

A chain with several VMs (or several chains joined by bridges) usually fragments the same economic asset into wrappers: a token on chain A, a wrapped copy on chain B, each with its own balance sheet, liquidity, and bridge risk. Users juggle several representations of "the same" asset.

How ACE does it

ACE's VMs (Native, EVM, SVM, and others) do not own separate state. They execute above one shared state tree. A token is a single mint record stored once under the token-program account:

• mint:<id> — supply, decimals, authority
• balance:<mint>:<owner> — per-owner balance

Because there is one ledger, the same balance is reachable from every VM:

• SVM programs operate it through the SPL-style token program.
• EVM contracts operate it as a standard ERC-20 at an auto-registered synthetic contract address derived from the mint id.
• Native transactions operate it directly.

A transfer from a Solidity contract and a transfer from an SVM program move the same balance — not two synchronized copies.

Why it matters

• No bridge and no wrapper between VMs, so no extra cross-VM failure domain.
• Liquidity is not duplicated per VM.
• A token issued once (see Mint a token) is immediately usable across the whole application surface.

The honest caveat

"Same owner across VMs" depends on identity mapping: an EVM address, an SVM public key, and a native identity each resolve to an account id. They are the same owner only when they derive from the same underlying identity. ACE's identity layer exists to unify these; balances are keyed by the resolved account id.