VIP -- Vexidus Intent Programs

The Problem: Traditional blockchains require developers to write, compile, and deploy smart contracts (Solidity on Ethereum, Rust on Solana) to create custom on-chain logic. This introduces bytecode verification headaches, compiler bugs, reentrancy exploits, and a steep learning curve.

The Solution: VIPs are declarative composition templates that sequence native Vexidus operations into reusable, parameterized programs. No bytecode. No compiler. No VM overhead. The program definition IS the source code -- written in JSON, readable by anyone, and statically analyzed for safety at registration time.

Developer writes:
  {
    "namespace": "defi",
    "name": "claim_and_stake",
    "steps": [
      { "op": "MintMultiToken", "args": { "recipient": "${sender}" } },
      { "op": "StakeToPool",    "args": { "amount": "${params.amount}" } }
    ]
  }

User invokes:
  "run defi/claim_and_stake with amount=1000"

Chain executes:
  1. MintMultiToken (reward tokens to user)
  2. StakeToPool (auto-stake rewards)
  Result: 1 signature, 2 operations, atomic execution

Why VIPs Instead of Smart Contracts

Vexidus has 104+ native operations -- token creation, NFT minting, AMM swaps, multi-sig custody, governance, staking, bridging, and more. These are not contract calls -- they are protocol-level primitives, already audited, gas-optimized, and battle-tested.

Smart contracts were invented because early blockchains had ~3 operations (send, receive, multisig). Developers needed a way to express complex logic. Vexidus already has the complex logic built in. What developers need is a way to compose existing operations into reusable sequences.

Dimension	EVM Smart Contracts	Solana Programs	Vexidus VIPs
Format	Compiled bytecode	Compiled BPF/SBF	Declarative JSON
Compilation	Solidity -> solc -> bytecode	Rust -> cargo-build-sbf	None required
Verification	Decompile bytecode, match source	Verify .so against source	Read the JSON -- it IS the source
Safety	Reentrancy, overflow, delegatecall	CPI confusion, PDA collision	Static analysis of known operation patterns
Gas model	Opcode-level metering	Compute unit budgets	Sum of constituent operation costs (predictable)
Attack surface	Massive (entire VM + compiler)	Large (loader + CPI)	Minimal (template expansion only)

How VIPs Work

1. Registration

A developer writes a JSON program definition and submits it via vex_registerProgram. The chain:

1. Validates the JSON structure (params, steps, returns)
2. Runs static safety analysis (9 rules -- see Safety Engine below)
3. Assigns a safety score (0-100) and level (Verified/Standard/Warning/Blocked)
4. Stores on-chain with version number and namespace ownership
5. Charges a registration fee (50 VXS)

If any critical safety rule fails, the registration is rejected -- the program never reaches the chain.

2. Invocation

A user invokes a VIP via IntentVM:

Goal::Program {
  namespace: "defi",
  name: "claim_and_stake",
  params: { "amount": "1000000000" }
}

The chain:

1. Loads the program definition
2. Checks safety level (Blocked programs cannot execute)
3. Validates required parameters are provided
4. Expands the template into native operations
5. Executes all operations atomically (all-or-nothing)

3. Simulation

Before signing, users can dry-run any VIP via vex_simulateProgram to see exactly what operations will execute, estimated gas costs, and any warnings. This is the DYOR tool built into the protocol.

Safety Engine

Every VIP is analyzed at registration time. The safety engine enforces these rules:

Rule	What It Checks	Result If Failed
No Hardcoded Recipients	Value-moving operations must use ${sender} or ${params.*} as recipient	REJECT
No Hidden Approvals	Approve operations must have spender as ${params.*} (user-provided)	REJECT
Allowed Operations Only	Only safe operations allowed in VIPs (no bridge admin, no key management)	REJECT
Expansion Limits	Max 50 expanded operations per invocation	REJECT
Gas Ceiling	Estimated gas must be below 5,000,000	Warning
Template Validation	All ${...} expressions must reference declared params or prior steps	REJECT
URI Sanitization	All URIs pass XSS/injection blocking (same as VSC-SAFE)	REJECT
Step ID Uniqueness	No duplicate step IDs, no forward references	REJECT
Namespace Rules	3-32 chars, alphanumeric + hyphens, reserved names require governance	REJECT

Safety Levels

Level	Score	Meaning
Verified	80-100	Passes all checks; author has strong reputation or governance audit
Standard	50-79	Passes all checks; normal author
Warning	25-49	Community-flagged or has suspicious patterns
Blocked	0-24	Failed analysis or governance-blocked; cannot be invoked

Community Flagging

Anyone can flag a VIP via vex_flagProgram. Each flag reduces the safety score. At 5+ flags, the score drops significantly. Governance can reclassify programs via proposals (same pattern as VSC-SAFE contract safety).

The safety registry is governance-managed -- new scam patterns, blocked addresses, and verified authors can be added over time via governance proposals. No binary upgrade required.

Template Expressions

VIPs use a restricted substitution syntax (NOT a programming language):

Expression	Meaning
${sender}	Address of the user invoking the VIP
${params.name}	User-supplied parameter value
${steps.id.result.field}	Output of a previous step
${item}	Current element in a loop iteration
${block.height}	Current block height
${block.timestamp}	Current block timestamp

What is NOT supported (by design): arithmetic, conditionals, string manipulation, external calls, variable mutation, nested expressions. This restriction IS the safety guarantee.

Universal Data Anchoring

Alongside VIPs, Vexidus introduces the Anchor operation -- a lightweight way to write a hash to the chain without token semantics:

Operation::Anchor {
  namespace: "vexalus",
  key: <shipment_id_bytes>,
  value_hash: <BLAKE3 hash of data>,
  metadata_uri: "ipfs://Qm..."
}

• 5,000 gas (10x cheaper than token mints)
• Namespace-isolated (partners cannot collide)
• Queryable via vex_getAnchors and vex_verifyAnchor
• Universal -- any application can use it for data attestation

Integration with IntentVM

VIPs extend IntentVM's Goal enum with Goal::Program. This means VIPs can be invoked via natural language:

"run vexalus/create_shipment with contents=Electronics origin=Shanghai destination=Rotterdam"

The IntentVM parser recognizes the run <namespace>/<name> pattern, extracts parameters, and creates a Goal::Program which the chain expands into native operations.

RPC Methods

Method	Purpose
vex_registerProgram	Register a new VIP
vex_getProgram	Get VIP definition (params, steps, safety score)
vex_listPrograms	Browse VIPs by namespace, author, or safety level
vex_simulateProgram	Dry-run expansion (see operations before signing)
vex_getProgramSafety	Full safety analysis with flag details
vex_flagProgram	Flag a VIP for community review
vex_anchor	Anchor a data hash on-chain
vex_getAnchors	Query anchored data
vex_verifyAnchor	Verify a hash matches an anchor

CLI Commands

vexidus vip register --program '{"namespace":"myapp",...}' --from <address>
vexidus vip show <namespace> <name>
vexidus vip list --namespace myapp
vexidus vip simulate <namespace> <name> --params '[["key","value"]]'
vexidus vip safety <namespace> <name>
vexidus vip flag --namespace myapp --name risky-prog --reason "suspicious transfers" --from <address>
vexidus vip anchor --namespace myapp --key <hex> --hash <Vxh...> --from <address>
vexidus vip get-anchors <namespace> <key>
vexidus vip verify <namespace> <key> <expected_hash>

Safety Philosophy

Vexidus implements multi-layered safety features for VIPs: static analysis at registration, runtime validation at execution, author reputation scoring, and community-driven governance oversight. These features are designed to detect and deter common attack patterns.

No automated system can guarantee the safety of every program. Users should always review the execution plan via vex_simulateProgram before signing, verify the program author's reputation, and exercise their own judgment. Always DYOR.

Safety features, not safety promises. We build the tools. We encourage DYOR. We make it harder for bad actors. We do not claim to make it impossible.