VSC Standards -- Native Building Blocks
VSC (Vexidus Standard Contract) standards are native operations built directly into the Vexidus L1 chain. Unlike Ethereum where every token, staking pool, or governance system requires deploying custom smart contract bytecode, Vexidus bakes these capabilities into the protocol itself.
VSCs define what the chain can do. VIPs define what you build with it.
- VSC standards are the building blocks -- audited once, used by everyone, no deployment needed
- VIP programs are the compositions -- custom JSON templates that chain VSC operations into application-specific workflows
Think of VSCs as LEGO bricks and VIPs as instruction manuals. A brick is a token. Another brick is a staking pool. A VIP says "connect these bricks in this order to build a castle."
Standard Categories
Asset Standards
Define how digital assets work on Vexidus. Create them with a single RPC call.
| Standard | Type | Ethereum Equivalent | Status |
|---|---|---|---|
| VSC-7 | Fungible tokens | ERC-20 | Live |
| VSC-8 | Stablecoins (regulated, issuer-controlled) | FiatTokenV2 + protocol security | Live |
| VSC-21 | Non-fungible tokens (NFTs) | ERC-721 | Live |
| VSC-55 | Multi-token (fungible + NFT in one collection) | ERC-1155 | Live |
| VSC-71 | Synthetic assets (stocks, perps) | -- | Stub |
Protocol Standards
Define how applications and infrastructure work on Vexidus. Also native -- no contract deployment.
| Standard | Type | Ethereum Equivalent | Status |
|---|---|---|---|
| VSC-20 | Programmable staking pools | StakingRewards / Convex | Live |
| VSC-88 | Protocol governance + multi-sig | Governor + Gnosis Safe | Live |
| VSC-99 | DAO program (token-weighted governance) | Compound Governor | Live |
| VSC-LAUNCH | Presale with anti-rug escrow | -- | Live |
| VSC-REP | Token reputation scoring | -- | Live |
| VSC-SAFE | Bridge + NFT safety scoring | -- | Live |
Why Both Categories Are Native (Not VIPs)
On Ethereum, you deploy a separate smart contract for every staking pool, every DAO, every governance system. Each one needs its own audit, introduces its own bugs, and has its own gas costs.
On Vexidus, these are protocol primitives. Every staking pool works the same way because VSC-20 is baked into the chain. Every DAO uses the same battle-tested VSC-99 code. Every multi-sig uses the same VSC-88 implementation.
This is the same approach as Solana (SPL Token is a native program) and Cosmos (bank module, staking module are native). The standards that every ecosystem needs should be audited once and shared by everyone.
VIPs are for custom application logic -- the workflows unique to YOUR project. Launch a token + create a pool + lock LP in one atomic transaction? That's a VIP composing VSC-7, VexiDEX, and VSC-88 operations.
VSC vs VIP -- When to Use What
| I want to... | Use | Example |
|---|---|---|
| Create a token | VSC-7 (vex_createToken) | Single RPC call |
| Mint an NFT | VSC-21 (vex_mintNft) | Single RPC call |
| Create a staking pool | VSC-20 (vex_createStakingPool) | Single RPC call |
| Create a DAO | VSC-99 (vex_createDAO) | Single RPC call |
| Launch token + pool + lock LP atomically | VIP | Compose 3 VSC operations |
| Payment escrow with multi-sig release | VIP | Compose VSC-88 + Transfer |
| Clan staking with treasury governance | VIP | Compose VSC-20 + VSC-88 |
| Tracked shipment with custody chain | VIP | Compose VSC-21 + VSC-55 + VSC-88 + Anchor |
One operation? Use a VSC directly. Multiple operations that must execute atomically? Write a VIP.
EVM Comparison
| Feature | Vexidus (VSC + VIP) | Ethereum (ERC + Solidity) |
|---|---|---|
| Asset creation | Single RPC call (VSC-7/21/55) | Deploy Solidity contract |
| Staking pool | Single RPC call (VSC-20) | Deploy custom staking contract |
| Governance | Single RPC call (VSC-88/99) | Deploy Governor + Timelock contracts |
| Custom logic | Register VIP (JSON template) | Deploy compiled Solidity bytecode |
| Audit surface | Protocol-level (audited once) | Per-contract (each needs audit) |
| Gas cost | Minimal (no bytecode execution) | High (contract deployment + calls) |
| Composability | VIP template expansion | Contract-to-contract calls (delegatecall) |
| Readability | JSON source = audit source | Must decompile bytecode or trust verification |
VSC-20 enables any token to have staking pools with configurable reward rates, lock periods, and capacity limits. Two reward models: Treasury (creator-funded) and Mint (inflationary). Read more →
VSC-8 is a dedicated standard for regulated fiat-backed stablecoins with 6 protocol-enforced security layers and canonical cross-chain bridging. 18 stablecoins across 10 currencies pre-mapped at genesis. Read more →
VSC-88 adds protocol-level governance with stake-weighted validator voting, plus M-of-N multi-sig shared wallets. Protocol Governance → | Multi-Sig Wallets →
VSC-7: Fungible Tokens
VSC-7 tokens are fungible assets with configurable name, symbol, decimals, and supply. Created in a single RPC call, immediately tradeable.
Create a Token
curl -s https://testnet.vexidus.io \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"method": "vex_createToken",
"params": ["MyToken", "MTK", 9, "1000000", "OWNER_ADDRESS"],
"id": 1
}' | jq .
| Parameter | Description |
|---|---|
name | Token name (e.g. "MyToken") |
symbol | Ticker symbol (e.g. "MTK") |
decimals | Decimal places (typically 9 for Vexidus) |
supply | Total supply in human units (the chain adds decimals automatically) |
owner | Address to receive initial supply |
When creating a token with vex_createToken, supply is in human units. Creating 1,000,000 tokens with 9 decimals means the chain stores 1,000,000,000,000,000 internally. You don't add zeros manually.
When transferring or querying balances, amounts are in raw units (with decimals). 1 VXS = 1,000,000,000 raw units.
RPC Methods
| Method | Description |
|---|---|
vex_createToken | Create a new fungible token |
vex_getTokenInfo | Query token info by mint address or symbol |
vex_listTokens | List all tokens |
vex_transfer | Transfer tokens between addresses |
vex_getBalance | Query balance for address + token |
VSC-21: Non-Fungible Tokens (NFTs)
Each NFT is a unique asset identified by (collection_mint, token_id). Collections support metadata (icons, banners, royalties).
RPC Methods
| Method | Description |
|---|---|
vex_createNftCollection | Create a new NFT collection with metadata |
vex_mintNft | Mint an NFT within a collection |
vex_transferNft | Transfer an NFT to another address |
vex_burnNft | Burn an NFT (owner only) |
vex_getNft | Query NFT by collection + token ID |
vex_listNftsByOwner | List NFTs owned by an address |
vex_getNftCollection | Collection metadata and token count |
VSC-55: Multi-Token Standard
A single collection containing both fungible and non-fungible token types with batch operations. A game might have "Gold Coins" (fungible) and "Legendary Sword" (non-fungible, supply=1) in one collection.
RPC Methods
| Method | Description |
|---|---|
vex_createMultiTokenCollection | Create a multi-token collection |
vex_defineTokenType | Define a new token type |
vex_mintMultiToken | Mint tokens of a type |
vex_batchMintMultiToken | Batch mint |
vex_transferMultiToken | Transfer tokens |
vex_batchTransferMultiToken | Batch transfer |
vex_burnMultiToken | Burn tokens |
VexBridge v3: Cross-Chain Bridge
Vaultless canonical token bridge connecting Vexidus to external blockchains. Bridged tokens are minted as VSC-7 assets. See VexBridge documentation.
VexiDEX: On-Chain AMM
Constant-product AMM (x*y=k) built as a native protocol primitive. Pools created via RPC -- no contract deployment. 0.3% swap fee.
| Method | Description |
|---|---|
vex_createPool | Create a liquidity pool |
vex_addLiquidity | Add liquidity |
vex_removeLiquidity | Remove liquidity |
vex_swap | Swap tokens |
vex_getPool | Pool info by token pair |
vex_listPools | List all pools |
vex_quoteSwap | Get swap quote (read-only) |