ai16z is now a migration story, not an emission story

ai16z’s defining tokenomic event is that it stopped being “ai16z” in any meaningful forward-looking sense. The project migrated $ai16z into $elizaOS starting on November 6, 2025, with a 1 $ai16z → 6 $elizaOS holder conversion, and positioned the new token for multichain operation via Chainlink CCIP.

That matters because the project explicitly chose a hard-capped, no-emissions policy for $elizaOS, while simultaneously expanding the long-run supply ceiling materially versus the legacy $ai16z supply. If you want the framework behind this review, see our tokenomics methodology.

From a security-budget-maximalist lens, this forces a clean question: if you are not paying for security through ongoing issuance, where is the durable “budget” supposed to come from. In this design, the answer is not validators. It is capital coordination, liquidity operations, and treasury routines run by agents across chains. The mechanism might work, but it is not the same thing as predictable protocol-native security spending.

What the project is, and what the token is supposed to do

The core product surface is elizaOS, an agent framework and runtime that aims to let autonomous agents operate across interfaces and chains. The token story sits beside that: ai16z began as an agent-led DAO narrative, then evolved into elizaOS v2 with cross-chain messaging and token mobility as first-class requirements.

What is clearly documented today is the migration, supply policy, allocations, and vesting controls. What is not clearly documented in primary tokenomics docs is a concrete, enforceable fee schedule that forces value to accrue to token holders, or a protocol-level “tax” that scales with usage and can be forecast as a budget line. The official materials emphasize agent-run liquidity and treasury strategies as the economic engine instead.

Supply, redenomination, and emissions

On CoinGecko, the legacy ai16z (AI16Z) entry is explicitly flagged as rebranded to ElizaOS with a migration from an old contract to a new contract.

Before migration, the project states the current $ai16z supply totaled 1.1B tokens. CoinGecko reports the legacy token’s coded maximum supply as 1,099,999,958 and shows the Solana contract identifier for the old token.

The migration mechanics are unusually important because they effectively “print the runway” once, upfront, then commit to no further emissions. The migration mechanics describe the documented parameters as follows:

Migration window: November 6, 2025 through February 4, 2026.

Redenomination: described as a 1:10 “network redenomination.”

Holder swap: 1 $ai16z converts to 6 $elizaOS.

Supply policy: hard cap 11,000,000,000 and no emissions.

Supply trajectory at migration: the 1.1B legacy supply could convert into 6.6B $elizaOS, with a further immediate circulating increase of 882M (from 6.6B to about 7.4B) to support liquidity and POL needs.

Contract standards and multichain footprint are explicit: SPL on Solana, ERC-20 on Ethereum/Base, and BEP-20 on BSC, with CCIP enabled from day one and published addresses across SVM/EVM deployments.

Allocation + vesting (what gets sold, when, and under what controls)

The project publishes a top-level allocation split in official materials.

Allocations (presented at the 11B hard cap, where amounts are implied unless an explicit token count is published):

Vesting enforcement and transparency claims are specific: the project says vesting wallets will be publicly listed with explorer links, and that Streamflow contracts enforce cliffs and prevent discretionary early unlocks.

Fiscal flows: the “Generative Treasury” replaces emissions as the funding lever

The most important cashflow statement in the public materials is not a fee table. It is the migration math.

The project frames the redenomination as 10 new units for every 1 old unit, while allocating only 6 of those 10 to the holder. The remaining 4 are described as a direct contribution to a “Generative Treasury” intended to seed autonomous multichain agents that generate yield, deepen liquidity, and fund ecosystem growth.

In plain infrastructure terms, this is a one-time recapitalization event. It increases the system’s balance-sheet capacity without committing to perpetual inflation. That is good for holders who hate dilution. It is also a sharp trade. You are swapping the simplicity of a fixed supply meme/DAO token for an actively managed, cross-chain treasury and liquidity strategy footprint that has to perform under real adversarial conditions. For another case study, compare this with our Compound tokenomics analysis.

What I cannot verify from primary tokenomics documentation is a deterministic, protocol-enforced revenue stream that must route into buybacks, burns, or validator/security incentives. The docs focus on allocations, vesting, and multichain architecture.

Governance and control surfaces (where “security budget” actually lives here)

ai16z / elizaOS does not run its own base-layer validator set today, at least per the tokenomics documentation. That means the classic “issuance pays validators” security budget framework does not apply directly. The security budget question shifts to custody, execution permissions, and cross-chain controls.

The biggest explicit control surface is bridging. The project states that the mint and burn authority is given to a token pool through Chainlink CCIP for multichain bridging.

CCIP’s cross-chain token designs generally require the token pool to hold mint and burn permissions in burn/mint models. This is normal for canonical multichain tokens, but it makes the “infinite mint” failure mode the existential one. If the verification layer or privileged permissions are compromised, supply integrity can fail fast.

Vesting control is the other major surface. The docs describe a structured vesting regime with cliffs and linear release, plus Streamflow-based enforcement and publicly trackable vesting wallets. That helps. It does not eliminate sell-pressure risk. It does reduce discretionary unlock risk, which is the better threat model to prioritize.

If you want a single sentence version of governance here: the onchain “monetary policy” is fixed at a hard cap and no emissions, but the operational policy is executed through treasury and liquidity programs that will necessarily rely on privileged smart contract roles, multisigs, and bridge infrastructure. The system’s security budget is therefore mostly an operational security and controls problem, not an inflation tuning problem.

Risk analysis (dominant risk: cross-chain mint integrity)

Top 3 risks

  1. Bridge or privileged-role compromise becomes a supply-integrity event, Trigger: compromise or misconfiguration of CCIP-related token pool permissions, or a failure in cross-chain verification that results in unauthorized minting. Mechanism: the design explicitly routes mint/burn authority to a token pool for CCIP bridging, and burn/mint systems carry an “infinite mint” class failure if authorization fails. Who bears it: token holders and LPs first (price collapse), then any ecosystem integrations that treat the asset as reliable collateral. Measurable indicators: unexpected supply increases on destination chains, changes in privileged roles/mint authority, abnormal bridge transfer patterns, or CCIP pauses/curses in response to anomalies.
  2. Vesting and “supply expansion to cap” creates an overhang that can dominate price formation, Trigger: cliffs completing and linear vest streams meaningfully increasing liquid float, especially if market depth is thin. Mechanism: $elizaOS can expand from the initial post-swap base toward the 11B cap over time, and multiple allocations are explicitly vested. If recipients monetize tokens faster than organic demand grows, liquidity support becomes a treadmill. Who bears it: spot holders and liquidity providers through drawdowns and adverse selection. Measurable indicators: Streamflow vest wallets’ release schedules, increases in circulating supply, and sustained net outflows from known vesting addresses once published.
  3. No emissions means no automatic replenishment of incentives if fees are not real and enforceable, Trigger: treasury strategies fail to generate sufficient net yield after risk, or operating costs rise faster than treasury income. Mechanism: without ongoing issuance, the project’s ability to fund liquidity, security operations, and growth becomes dependent on finite allocations and treasury performance. If performance disappoints, the fallback is typically selling inventory, which transfers budget stress into token price stress. Who bears it: long-duration holders (slow bleed) and integrators (uncertain incentive continuity). Measurable indicators: depletion of liquidity/listing allocation balances, repeated liquidity pullbacks, and persistent sell pressure from treasury-associated wallets once disclosed.

Dominant risk: cross-chain mint integrity is the one that can end the token’s monetary credibility in a single incident.

This is not abstract bridge FUD. It is embedded in the architecture choice. The project explicitly states that mint and burn authority is granted to a token pool via CCIP to enable multichain bridging. That is a rational design if you want canonical supply across chains without liquidity pools. It is also the cleanest way to concentrate catastrophic risk into a narrow set of privileged paths.

Burn/mint bridging removes the honey-pot of a huge locked pool, but it replaces it with a different worst case: unauthorized minting. Chainlink’s own educational material calls out infinite mint risk as the critical consideration when the destination side can mint on demand, and the mitigation burden shifts to verification security and privileged key governance.

In a security-budget-maximalist framework, you want redundancy, monitoring, and credible rollback or containment processes. CCIP markets a defense-in-depth posture and a separate risk management network that can halt cross-chain activity when anomalies are detected. That helps reduce blast radius. It does not remove the reliance on correct configuration and secure operation of all the privileged components.

So the practical diligence question becomes operational: who controls the token pool permissions, what multisig and policy controls gate changes, how quickly can bridging be paused, and how transparently are incidents handled. The project’s tokenomics docs talk about vesting transparency and Streamflow enforcement, which is a good sign on the vesting axis. They are comparatively thin on the governance and control processes around the most dangerous permission set in the entire design.

If you are building around this token, treat bridge risk as a first-order integration constraint. Cap collateral factors. Prefer isolation. Monitor supply and privileged-role changes continuously. Assume “no emissions” will not save you if supply integrity is ever questioned. We also publish research reports that focus on monitoring and failure-mode analysis.

If you need a second set of eyes on these mechanisms in a neutral way, this is where a small amount of tokenomics consulting pays for itself. Focus the work on control surfaces and fiscal sustainability, not vibes.



This article is part of our Tokenomics Deep Dive series.