VexBridge -- Vaultless Canonical Token Bridge
The Stateless/Limbo Resolution Model
Core Philosophy
Vexidus is an ultimate L1 blockchain: a native ecosystem where VSAs (Vexidus Smart Accounts) accept any token from any chain, making foreign tokens native-like on Vexidus without wormholes, vaults, or wrapped tokens.
The fundamental principle: Tokens are never locked in vaults. They are either burned on the source chain or rendered stateless (provably unspendable). Vexidus then mints a canonical equivalent -- not a wrapped representation, but a first-class native token.
Traditional bridges: User -> Vault (holds tokens) -> Mint wrapped token
Risk: Vault hack = total loss
Vexidus VexBridge: User -> Burn/Limbo (tokens destroyed) -> Mint canonical token
Risk: Nothing to hack (no vault exists)
Two Token Categories
1. Burnable Tokens (Easy Path)
Tokens with burn functions on their source chain (ERC-20 burn(), SPL burn(), etc.).
Flow:
- User burns token on source chain (Ethereum, Solana, etc.)
- ZK proof or light client verifies the burn transaction
- Vexidus mints canonical equivalent
Bridgeability: FullRoundTrip -- can bridge in AND out.
Bridge back: Burn on Vexidus -> proof submitted to source chain -> source contract mints new tokens (requires mintable contract on source chain).
Examples: USDC, USDT, DAI, WBTC, WETH, LINK, UNI
2. Non-Burnable Tokens -- The "Stateless/Limbo" Innovation
Native tokens that cannot be burned because no burn function exists (native SOL, native ETH, native BTC).
Flow:
- User sends tokens to their VSA address on the source chain
- Since VSAs exist on Vexidus, NOT on Solana/Ethereum, the destination address does not exist on the source chain
- The tokens become stateless -- sent but never landed anywhere
- They are in limbo: provably not in anyone's possession on the source chain
- ZK proof verifies: (a) the transaction happened, (b) the destination is a VSA that does not exist on the source chain -> tokens are provably unspendable
- Vexidus mints canonical equivalent
Bridgeability: LimboLocked -- can bridge in. Bridge out requires liquidity matching.
Bridge back limitation: Only possible if the source chain has a mintable program (e.g. ERC-20 with mint authority, SPL with mint authority). Native SOL and native ETH are one-way-in because nobody can mint native SOL or native ETH -- there is no program to call.
Examples: SOL, ETH, BTC, BNB, MATIC
Why This Works
The key insight: absence of arrival IS the proof of destruction.
On Solana, if you send SOL to a VSA-format address, the transaction executes successfully (Solana does not validate that the recipient has a program/account). The SOL leaves the sender's account but never arrives anywhere it can be spent from. It is not "locked" -- it is gone. Not in a vault. Not in escrow. Just... stateless.
This is cryptographically equivalent to burning, but works for tokens that have no burn function.
Wrong Address Resolution
What happens if someone accidentally sends tokens to a VSA address format on the wrong chain? The tokens land on Vexidus natively. Not lost -- just on Vexidus now. The bridge detects the VSA-format destination and auto-receives.
Three-Tier Verification Architecture
VexBridge uses a tiered system to verify that tokens were actually destroyed/made-stateless on the source chain. The tier determines the trust model for verification.
Tier 1: Multi-Chain Native (State Coordination)
For tokens you control issuance of on multiple chains.
- Vexidus controls the mint authority on both chains
- Atomic burn on source -> mint on destination via coordination signature
- No external trust assumptions
Current tokens: DGBT, VXS
Proof type: Ed25519 coordination signature.
Tier 2: Light Client Verification (Trustless)
For major chains with light client support.
- Vexidus runs a light client that tracks the source chain's state
- Verifies transaction inclusion in a finalized block via Merkle proof
- Trustless -- only trusts the source chain's own consensus/finality
Current chains:
| Chain | Finality Blocks | Light Client |
|---|---|---|
| Solana | 32 | Solana |
| Ethereum | 128 | Ethereum |
| Base | 128 | Base |
| Arbitrum | 128 | Arbitrum |
Proof type: Block number, Merkle proof, destruction verification.
Tier 3: Oracle Consensus (Distributed Trust)
For chains without light client support.
- Multiple independent oracles verify the transaction on the source chain
- Require threshold consensus (e.g. 7 of 10 must agree)
- Each oracle signs an Ed25519 attestation over (source_chain, tx_hash, amount)
Current chains: Bitcoin, Polygon, and any chain not in Tier 2.
Proof type: Multiple oracle attestations with Ed25519 signatures.
Oracle verification: Real Ed25519 signature verification against registered oracle public keys.
Security Model Comparison
| Vault Bridges | Vexidus VexBridge | |
|---|---|---|
| Single point of failure | Vault (hack = total loss) | None (nothing to hack) |
| Token type | Wrapped/synthetic | Canonical/native |
| Trust (Tier 1) | N/A | Zero (you control both sides) |
| Trust (Tier 2) | N/A | Minimal (source chain finality only) |
| Trust (Tier 3) | N/A | Distributed (7-of-10 oracles must lie) |
| Capital locked | All bridged tokens | Zero |
| Reversibility | Complex (needs vault access) | Honest -- depends on bridgeability |
Bridgeability Classification
VexBridge is honest by design -- it tells users upfront what they can and cannot do, BEFORE they act on the source chain.
Every token gets classified into one of three bridgeability levels:
| Level | Meaning | Examples |
|---|---|---|
| Full Round-Trip | Can bridge in AND out freely | USDC, USDT, DAI, WBTC, WETH, LINK, UNI, DGBT, VXS |
| Limbo-Locked | Can bridge in. Out requires liquidity matching. | SOL, ETH, BTC, BNB, MATIC |
| One-Way In | Can come in, no established path back. | Unknown/new tokens |
The vex_getExecutionPlan RPC includes bridgeability warnings so users know the limitations before sending.
Bridge Fee Model
Per-chain fee configuration:
| Chain | Fee (bps) | Minimum Fee | Notes |
|---|---|---|---|
| Ethereum | 30 (0.3%) | 1 unit | High gas, higher fee |
| Solana | 10 (0.1%) | 0.1 unit | Low cost chain |
| Bitcoin | 50 (0.5%) | 5 units | Complex verification |
| Default | 25 (0.25%) | 0.5 unit | Other chains |
Fees are credited to Foundation treasury (0x...01).
RPC Endpoints
| Endpoint | Purpose |
|---|---|
vex_bridgeToken | Submit bridge deposit with proof |
vex_bridgeWithdraw | Initiate bridge withdrawal |
vex_getBridgeStatus | Query bridge operation status |
vex_getBridgeHistory | List bridge operations for address |
vex_getBridgeFees | Get fee config for a chain |
vex_autobridge | Universal receive -- auto-detect and process |
vex_getPendingReceives | List pending auto-detected receives |
vex_getExecutionPlan | Preview bridge intent + bridgeability warnings |
ZK Proof Purpose
The ZK proof system serves two purposes:
-
Verify transaction execution: Prove that "User A sent 10 SOL to address X" actually happened on the source chain.
-
Verify statelessness (for non-burnable tokens): Prove that address X is a VSA-derived address that does not exist on the source chain, making the tokens provably unspendable there.
For burnable tokens, purpose (1) is sufficient -- the burn is the proof. For non-burnable tokens, both (1) and (2) are required -- the limbo is the proof.
Contract Safety Registry (VSC-SAFE)
VexBridge includes an on-chain safety registry that automatically scores bridge contracts using heuristic analysis. This protects users from interacting with malicious or impersonating tokens being bridged into Vexidus.
How Scoring Works
Every bridged contract receives a heuristic safety score (0-100) based on five factors:
| Factor | Effect | Description |
|---|---|---|
| Known whitelist | +30 | Contract is on the verified list (USDC, USDT, WETH, LINK, DAI, UNI, WBTC on Ethereum; USDC/USDT SPL on Solana; USDC on Base/Arbitrum) |
| Impersonation | -40 | Contract symbol matches a reserved stablecoin symbol (e.g., someone bridging a fake "USDC") |
| Launchpad origin | -20 | Contract originated from pump.fun, Raydium launchpad, Moonshot, or similar platforms |
| Deposit history | +10/+20 | 5+ deposits: +10, 50+ deposits: +20 (established usage pattern) |
| Source chain tier | +10 | Originated from a Tier 2 chain (Ethereum, Solana, Base, Arbitrum, Polygon, Avalanche, Optimism) |
Base score starts at 50. Final score is clamped to 0-100.
Safety Levels
| Level | Score Range | Behavior |
|---|---|---|
| Verified | 80-100 | Full bridge access, "verified_bridge" reputation badge |
| Standard | 50-79 | Normal bridge access |
| Warning | 25-49 | Bridge allowed with user warning, reduced reputation |
| Blocked | 0-24 | Bridge deposits rejected |
Governance Reclassification
Validators can propose to reclassify a contract's safety level via VSC-88 governance:
- ContractSafety proposal -- Reclassify a bridge contract (e.g., upgrade a legitimate project from Standard to Verified, or block a scam contract)
- CollectionSafety proposal -- Flag or freeze a bridged NFT collection
# Reclassify a contract to Verified
vexidus governance create-proposal \
--type contract-safety \
--title "Verify USDC on Base" \
--description "Circle's official USDC deployment on Base" \
--safety-chain base \
--safety-contract 0x833589fcd6edb6e08f4c7c32d4f71b54bda02913 \
--safety-level Verified
# Block a scam token
vexidus governance create-proposal \
--type contract-safety \
--title "Block fake USDC on unknown chain" \
--description "Impersonating USDC symbol, no liquidity" \
--safety-chain unknown \
--safety-contract 0xdeadbeef... \
--safety-level Blocked
RPC Endpoints
| Method | Description |
|---|---|
vex_getContractSafety | Get safety record for a specific contract. Params: [chain, contract_address] |
vex_listContractSafety | List all safety records (optional chain filter). Params: [chain?, limit] |
Reputation Integration
Contract safety levels feed into the token reputation system (VSC-REP):
- Verified contracts receive the
verified_bridgereputation badge - Warning contracts receive reduced reputation scores
- Blocked contracts cannot bridge at all
NFT Metadata Hardening (VSC-SAFE)
All NFT and token metadata submitted on-chain is sanitized to prevent XSS, injection, and phishing attacks.
URI Validation
All URI fields (metadata_uri, image, base_uri, icon_uri, banner_uri, external_url) are validated:
- Allowed schemes:
https://,ipfs://,ar://(Arweave) - Blocked:
data:URIs (prevents inline payload attacks),javascript:,http:// - Pattern scanning: Rejects URIs containing
<script,onerror=,onclick=,<iframe,eval(,document.cookie, and 17+ other dangerous patterns - Length limit: 512 characters for URIs, 256 for external URLs
Text Validation
All text fields (description, name, attribute values) are sanitized:
- Null byte rejection -- prevents string truncation attacks
- Dangerous pattern blocking -- same 17+ patterns as URI validation
- Length limits: 2,048 chars for descriptions, 64 chars for attribute keys, 256 chars for attribute values
- Attribute count limit: Max 50 attributes per token
Why This Matters
NFT metadata is displayed in wallets, explorers, and marketplaces. Without sanitization, a malicious NFT could inject JavaScript into VexScan, VexSpark, or any frontend that renders token metadata. VSC-SAFE ensures all on-chain metadata is safe to render in any context.
Implementation Status
Live on Testnet
- Three-tier verification architecture (Coordination, Light Client, Oracle)
- Bridgeability classification and user warnings
- Bridged token registry
- Per-chain fee model
- Ed25519 oracle signature verification
- Bridge deposit and withdrawal with tier-aware routing
- Auto-bridge (universal receive) endpoint
- IntentVM-atomic bridge operations
- Execution-time proof verification (every validator independently verifies bridge proofs)
- Oracle key registry (Ed25519 pubkeys in RocksDB)
--bridge-strictCLI flag (reject unverified proofs in production)- VSC-SAFE contract safety registry with heuristic auto-scoring
- VSC-SAFE NFT metadata hardening (URI/text sanitization)
- Governance reclassification (ContractSafety/CollectionSafety proposals)
Roadmap
- ZK-STARK proof verification (Winterfell integration)
- Real Solana/Ethereum light clients
- On-chain oracle registry with governance
- External chain relayers (Solana/BSC devnet)
- Circuit breaker for large transfers
Industry Context
How Others Solve This Problem
| Bridge | Model | Trust | Risk |
|---|---|---|---|
| Wormhole | Vault + guardian multisig | 13-of-19 guardians | $320M hack (Feb 2022) |
| Ronin | Vault + validator multisig | 5-of-9 validators | $625M hack (Mar 2022) |
| Chainlink CCIP | Oracle DON + burn/mint | 31+ oracle nodes | Oracle collusion |
| LayerZero | Relayer + oracle | 2-of-2 (relayer + oracle) | Single oracle compromise |
| Vexidus VexBridge | No vault. Burn/limbo + multi-tier proof | Tier 1: zero, Tier 2: finality, Tier 3: 7-of-10 | Nothing to hack |
Why Vaultless Matters
Every major bridge hack has targeted the vault -- the smart contract holding locked tokens:
- Wormhole ($320M): Attacker minted tokens without depositing to vault
- Ronin ($625M): Compromised validator keys controlling the vault
- Nomad ($190M): Faulty Merkle root allowed draining the vault
VexBridge eliminates this attack surface entirely. There is no vault. Tokens are either burned (verifiable destruction) or stateless (provably unspendable). The only attack vector is compromising the proof verification itself (ZK/light client/oracle), which is a fundamentally harder problem than stealing from a vault.
VexBridge is protected by pending patent applications covering the vaultless bridge architecture, stateless/limbo resolution model, and related innovations. See vexidus.io for details.