$INCOME | Cross-Chain Architecture

01 / THE CONSTRAINT

Why This Architecture Exists

$INCOME launched on Solana with a fixed supply of 1,000,000,000 tokens. The mint authority is permanently revoked. No new $INCOME can ever be created on Solana. Through ongoing burns, the circulating supply has decreased and will continue to decrease.

As $INCOME expands to BNB Chain, TRON, TON, and Ethereum, the requirement is absolute: the on-chain totalSupply on every single chain must reflect the same global number. Not an off-chain aggregator. Not a dashboard estimate. The actual on-chain `totalSupply()` or `getTokenSupply` call must return the same value, verifiable by anyone on any block explorer.

Additionally, no minting can ever occur after initial deployment. Once a chain is deployed, its mint authority is permanently revoked. Supply can only go down through official, on-chain burns.

The Three Constraints

1. On-chain totalSupply must be identical across all chains at all times
2. No minting ever occurs after initial deployment on any chain
3. Burns must be official on-chain transactions, not "locked forever" tokens

02 / THE MODEL

Pre-Funded Vaults + Burn Propagation

The architecture combines two mechanisms: Pre-Funded Vaults for cross-chain movement, and Cross-Chain Burn Propagation for supply synchronization.

1

Pre-Funded Vaults

Each chain receives a one-time mint of the current total supply into a vault contract. Mint authority is then permanently revoked. The vault holds tokens that can be released for bridging or burned for propagation. No new tokens can ever be created.

2

Bridge via Lock/Release

Moving tokens between chains locks them in the source vault and releases from the target vault. No minting. No creation. Just movement between pre-funded reserves. The bridge can never release more than the vault holds.

3

Burn Propagation

When tokens are burned on ANY chain, the bridge relay triggers official on-chain burns of the same amount from every other chain's vault. This keeps totalSupply identical everywhere. Burns are permanent and verifiable.

Key Insight

The vault on each chain serves two purposes: (1) holding tokens available for bridge releases, and (2) acting as a "burn buffer" that can be burned when burns happen on other chains. This is what makes synchronized totalSupply possible without any minting.

03 / DEPLOYMENT PROCESS

One-Time Setup. Permanent Revocation.

Each target chain undergoes a single, irreversible deployment process. After this process completes, no chain can ever mint new tokens.

1

Pause Burns Temporarily

All burn mechanisms across the ecosystem are paused for a brief window (minutes). This ensures the supply number doesn't change between reading it and minting it on the new chain.

2

Read Exact Solana Supply

Query Solana's getTokenSupply to get the precise current circulating supply. This is the exact number that will be minted on the new chain.

3

Deploy Token Contract

Deploy the $INCOME token contract (ERC-20/TRC-20/Jetton) on the target chain with a temporary deployer mint authority.

4

Mint Exact Supply to Vault

Mint the exact supply (matching Solana) directly to the vault contract address. Zero tokens go to any wallet. Everything goes into the vault.

5

Permanently Revoke Mint Authority

In the same transaction (or atomic sequence), permanently revoke the mint authority. After this point, no new tokens can ever be created on this chain. This is irreversible.

6

Verify and Resume

Verify on block explorer that: totalSupply matches Solana, mint authority is null/revoked, all tokens are in vault. Resume burn mechanisms.

After deployment, the new chain's on-chain totalSupply() equals Solana's getTokenSupply. Zero tokens are circulating (all in vault). The chain is ready to receive bridge transfers and participate in burn propagation.

04 / BRIDGE FLOW

Lock/Release. Never Mint.

Cross-chain transfers move tokens between vaults. No minting. No creation. Tokens are locked on the source chain and an equal amount is released from the target chain's vault.

Source Chain

Where tokens leave

User's tokens lock into vault

Vault balance increases

User's balance decreases

totalSupply unchanged

Circulating decreases, vault increases

→

LOCK

---

RELEASE

←

Target Chain

Where tokens arrive

Vault releases tokens to user

Vault balance decreases

User's balance increases

totalSupply unchanged

Circulating increases, vault decreases

Critical point: totalSupply does not change during bridge transfers. Only the distribution between vault and circulating changes. The bridge can never release more than the vault holds. Rate limiting caps daily bridge volume to prevent rapid depletion.

Example: Bridge 50M from Solana to BNB

Before Bridge

Solana: 732M totalSupply (732M circulating, 0 in vault)
BNB: 732M totalSupply (0 circulating, 732M in vault)
Global circulating: 732M

After Bridge

Solana: 732M totalSupply (682M circulating, 50M in vault)
BNB: 732M totalSupply (50M circulating, 682M in vault)
Global circulating: 732M (unchanged)

05 / BURN PROPAGATION

Burns Everywhere. Officially. On-Chain.

This is the core innovation. When $INCOME is burned on any chain, the Burn Relay detects the event and triggers official on-chain burns on every other chain's vault. Not "locked." Not "frozen." Actually burned. Permanently removed from totalSupply on every chain.

How Burn Propagation Works

1

Burn Occurs on Chain A

A user, protocol, or agent burns X tokens on any chain. This is a standard on-chain burn transaction (burnChecked on Solana, burn() on EVM, burn_notification on TON). Chain A's totalSupply decreases by X immediately.

2

Burn Relay Detects the Event

The Burn Relay service (backed by Wormhole Guardians or generic messaging) detects the burn event on Chain A. It generates a signed attestation (VAA) proving the burn occurred.

3

Relay Sends Burn Commands to All Other Chains

The relay submits the burn attestation to every other chain's vault contract. The vault verifies the attestation signature and confirms the burn amount.

4

Each Vault Officially Burns X Tokens

Each vault contract executes an official on-chain burn of X tokens from its own holdings. On Solana: burnChecked via PDA CPI. On EVM: burnFrom() with pre-approved allowance. On TON: burn message from vault wallet. totalSupply decreases on every chain.

5

All Chains Now Show the Same totalSupply

Every chain's on-chain totalSupply is now reduced by X. Verifiable on any block explorer. No "locked" tokens. Official burns everywhere.

Example: 10M Burned on BNB

Before Burn

Solana: 732M totalSupply (682M circulating, 50M in vault)
BNB: 732M totalSupply (50M circulating, 682M in vault)
TRON: 732M totalSupply (0 circulating, 732M in vault)

10M Burned by User on BNB

BNB: 722M totalSupply (40M circulating, 682M in vault) [immediate]

Burn Propagation Completes

Solana: vault burns 10M → 722M totalSupply (682M circulating, 40M in vault)
BNB: 722M totalSupply (40M circulating, 682M in vault) [already done]
TRON: vault burns 10M → 722M totalSupply (0 circulating, 722M in vault)

All chains: 722M totalSupply. Official. Verifiable.

Technical Verification

The following has been verified as technically feasible:

✓

Solana PDA can burn its own tokens via burnChecked CPI, even with mint authority revoked. Burning only requires the token account owner (the PDA) to sign. Confirmed via Solana documentation.
✓

EVM vault can burn via burnFrom() using OpenZeppelin's ERC20Burnable. The vault grants the bridge contract an allowance, and the bridge calls burnFrom(vaultAddress, amount). Standard pattern.
✓

TON Jetton supports native burn via burn_notification message from the wallet owner contract. The vault contract can burn its own Jetton balance.
✓

Wormhole generic messaging can relay arbitrary instructions cross-chain via signed VAAs (Verified Action Approvals). Burns can be attested by 19 Guardian validators and verified on any chain.

06 / THE SUPPLY EQUATION

Always True. On Every Chain.

The Invariant

totalSupply(Solana) = totalSupply(BNB) = totalSupply(TRON) = totalSupply(TON) = totalSupply(ETH)

On Each Chain

totalSupply = vault_balance + circulating_on_this_chain

Global Circulating

GLOBAL CIRCULATING = solana_circ + bnb_circ + tron_circ + ton_circ + eth_circ

All Burns Are Official

GLOBAL BURNED = initial_supply - totalSupply (on any chain, since they are all equal)

Event-by-Event Accounting

Event	Source Chain	All Other Chains	totalSupply
Burn on Chain A	totalSupply decreases (burned from circulating)	totalSupply decreases (burned from vault via propagation)	Decreases everywhere
Bridge A to B	Locked in vault (totalSupply unchanged)	Released from vault (totalSupply unchanged)	No change
Revenue deposit burn	25% burned on chain where deposit occurs	Propagated burn on all other chains	Decreases everywhere
Agent buyback burn	Bought and burned on operating chain	Propagated burn on all other chains	Decreases everywhere

07 / EDGE CASE

The Vault-Balance Constraint

There is one edge case that must be handled honestly. A vault can only burn tokens it actually holds. If most tokens have been bridged OUT of a vault (i.e., they are circulating on that chain), and a large burn happens on another chain, the vault may not have enough to burn the full propagated amount.

Edge Case Scenario

BNB has 732M totalSupply: 682M circulating + 50M in vault.
100M is burned on Solana.
Burn propagation tells BNB vault to burn 100M.
BNB vault only holds 50M - cannot burn the full 100M.

Solution: Burn Debt Tracking

The vault contract implements a burn debt mechanism:

1

Burn what is available: The vault burns its full balance (50M in the example). This is an official on-chain burn.
2

Record the debt: The remaining 50M is stored as burnDebt in the vault contract. This is publicly visible on-chain.
3

Report accurately: The vault contract exposes effectiveTotalSupply() = totalSupply() - burnDebt. This is the canonical number used by the Global Supply Aggregator.
4

Settle on refill: When tokens are bridged back to that chain (refilling the vault), the incoming tokens are burned immediately to settle the debt before any are added to the vault. Debt decreases, until fully settled.
5

Eventually consistent: Once settled, effectiveTotalSupply() = totalSupply() and the on-chain number is fully accurate again.

Why This Is Rare in Practice

This edge case only occurs when 90%+ of supply has migrated to one chain AND a massive burn happens on another chain. Under normal distribution (e.g., 70% Solana, 15% BNB, 10% TRON, 5% TON), every vault has hundreds of millions in burn capacity. The scenario requires an extreme and unlikely concentration of tokens on a single chain.

Rate limiting on the bridge further prevents this by capping how quickly tokens can drain from any vault.

08 / GLOBAL AGGREGATOR

One Number. Everywhere.

The Global Supply Aggregator is a service that queries every chain and produces the canonical supply number. Every dashboard, API, bot, and frontend displays this number.

Aggregator Logic

canonical_supply = min(effectiveTotalSupply across all chains)

This ensures the displayed number is always the most conservative (most burned) value, even if one chain's propagation is temporarily delayed.

API Response: /api/global-supply

{
  "global_supply": 722,000,000,
  "global_burned": 278,000,000,
  "burn_pct": 27.80,
  "chains": {
    "solana": { "totalSupply": 722000000, "vault": 40000000, "circulating": 682000000, "debt": 0 },
    "bnb": { "totalSupply": 722000000, "vault": 672000000, "circulating": 50000000, "debt": 0 },
    "tron": { "totalSupply": 722000000, "vault": 722000000, "circulating": 0, "debt": 0 },
    "ton": { "totalSupply": 722000000, "vault": 722000000, "circulating": 0, "debt": 0 }
  },
  "propagation_healthy": true,
  "last_updated": "2026-04-29T08:00:00Z"
}

The aggregator reports propagation_healthy: true when all chains have zero burn debt and identical totalSupply. If any chain has outstanding debt, it reports the debt and the canonical supply accounts for it.

09 / INFRASTRUCTURE

Wormhole Integration

The architecture uses two Wormhole products:

Wormhole NTT

Token Transfers

Lock/Unlock between vaults

Rate-limited transfers

19 Guardian validation

Emergency pause capability

Solana + EVM + TON support

+

Wormhole Messaging

Burn Propagation

Relay burn events cross-chain

Signed VAA attestations

19 Guardian validation

Arbitrary instruction relay

Custom transceiver support

Why Wormhole over building custom: Bridge exploits are the #1 source of DeFi losses ($2.5B+ stolen historically). Wormhole has secured $25B+ in value, employs 19 independent Guardian validators, has been audited multiple times, and provides built-in rate limiting and pause mechanisms. Building a secure custom bridge from scratch takes 6-12 months and multiple audits.

Security Layers

1

19 Guardian Validators: Every cross-chain message (transfer or burn) must be signed by a supermajority of 19 independent validators before it can be executed on the destination chain.
2

Rate Limiting: Maximum bridge transfer volume per 24-hour period (e.g., 10M $INCOME/day initially). Prevents rapid vault depletion even if an exploit occurs.
3

Emergency Pause: Governance can pause all bridge operations instantly if anomalous activity is detected. No tokens can move while paused.
4

Burn Attestation: Burn propagation messages include the transaction signature of the original burn, verifiable on the source chain. No burn can be fabricated.

10 / TOKEN CONTRACTS

Per-Chain Specifications

Chain	Standard	Mint Authority	Burn Mechanism	Vault Type	Status
Solana	SPL Token	Revoked (permanent)	burnChecked via PDA CPI	Anchor program + PDA	LIVE
BNB Chain	BEP-20	Revoked after vault mint	ERC20Burnable.burnFrom()	Smart contract + allowance	TESTNET
TRON	TRC-20	Revoked after vault mint	TRC20Burnable.burnFrom()	Smart contract + allowance	TESTNET
TON	Jetton (TEP-74)	Revoked after vault mint	Native burn_notification	Jetton wallet contract	PLANNED
Ethereum	ERC-20	Revoked after vault mint	ERC20Burnable.burnFrom()	Smart contract + allowance	PLANNED

Every chain follows the same pattern: deploy, mint to vault, revoke permanently. After revocation, the only operations possible are transfer, burn, and bridge lock/release. No admin backdoors. No upgrade mechanisms for the mint function.

11 / TIMELINE

Phased Rollout

Phase 1

Foundation

Weeks 1-4

Modify IncomeToken contracts for vault + burn propagation. Deploy to BNB testnet. Build vault contract with burn debt tracking. Build Burn Relay service. Build Global Supply Aggregator. Full testnet integration testing.

Phase 2

Audit + Harden

Weeks 5-8

External security audit of vault contract, token contract, and bridge configuration. Penetration testing. Stress testing with high-volume burns and bridge transfers. Document emergency procedures.

Phase 3

BNB Mainnet

Weeks 9-10

Deploy IncomeToken on BNB mainnet. Mint exact supply to vault. Revoke mint permanently. Configure Wormhole NTT + messaging. Set conservative rate limits. Monitor 2-4 weeks.

Phase 4

Expansion

Weeks 12-18+

Repeat proven process for TRON, TON, and Ethereum. Each chain: deploy, mint, revoke, configure bridge, add to aggregator. Increase rate limits based on operational experience.

12 / CORE PRINCIPLES

Non-Negotiable Rules

1

No minting after deployment. Once a chain's vault is funded and mint authority is revoked, no new tokens can ever be created on that chain. This is irreversible and verifiable by anyone.
2

All burns are official on-chain transactions. No "locked forever" tokens. No counters pretending to be burns. Every burn is a real burn instruction that reduces totalSupply on-chain, visible on any block explorer.
3

totalSupply is identical on every chain. The on-chain totalSupply() or getTokenSupply must return the same number on every chain. Burns propagate to maintain this invariant.
4

Bridge transfers are supply-neutral. Moving tokens between chains locks on source, releases on target. totalSupply does not change. Only burns reduce supply.
5

One token, one identity, one supply. $INCOME on every chain is the same asset with the same name, symbol, 9 decimals, and totalSupply. It is not a wrapped token or synthetic. It is the native asset.
6

Transparent and auditable. Vault balances, burn debts, bridge transfers, and burn propagation events are all publicly visible on-chain. Anyone can verify the supply equation at any time on any chain.

One Token. Every Chain.