Tech Specs

This document provides implementation details for developers, technical partners, and investors conducting technical due diligence.

---

Smart Account Implementation

Standard: ERC-7579 (Minimal Modular Smart Accounts)

Provider: Biconomy Nexus

Deployment Chains: Arbitrum, Base

ERC-7579 defines four module types that extend smart account functionality:

Module Type	Purpose	XIO Usage
Validators	Determine transaction validity	Session key validation
Executors	Perform actions on behalf of account	Agent trade execution
Hooks	Pre/post-execution logic	Risk limit enforcement
Fallback Handlers	Extend account functionality	Future module compatibility

Related Standards:

• ERC-4337: Account abstraction via EntryPoint v0.7.0

• ERC-7739: Phishing-resistant signatures

• ERC-7484: Module registry for security attestations

Audits:

Auditor	Date	Scope
Spearbit/Cantina	Oct-Nov 2024	Full Nexus implementation
CodeHawks/Cyfrin	Sep 2024	Smart account core
Zenith	Mar 2025	Module system
Pashov	Mar 2025	Security review

DeFi Safety Score: 92%

---

Session Key Architecture

Session keys enable scoped, time-bound delegation without exposing the root private key.

How It Works:

1. User creates a session key with defined policies

2. Session key is authorized on-chain via the smart account

3. Agent uses session key to sign transactions

4. Smart account validates each transaction against session policies

5. Valid transactions execute; policy violations revert

Policy Types:

Policy	Function	Example
ActionPolicy	Restrict callable contracts	Only Hyperliquid contract
FunctionPolicy	Restrict callable functions	Only openPosition, closePosition
ValueLimitPolicy	Cap native token per tx	Max 0.1 ETH per transaction
SpendingLimitPolicy	Cumulative spend tracking	Max 2,000 USDC total
TimeRangePolicy	Active time window	Valid for 24 hours
UsageLimitPolicy	Operation count cap	Max 100 transactions

Policies are composable. Multiple policies apply simultaneously. A transaction must satisfy ALL active policies to execute.

Revocation: Session keys can be revoked instantly by the account owner. Revocation is on-chain and immediate.

Compromise Scenario: If a session key is compromised, the attacker can only:

• Call whitelisted contracts

• Execute whitelisted functions

• Spend up to the defined limits

• Operate until session expiry or revocation

They cannot: withdraw funds, change account ownership, or exceed policy boundaries.

---

Bridging Infrastructure

Provider: Relay Protocol

Model: Intent-based bridging with solver network

Settlement Time: 1-10 seconds

Supported Chains: 85+

How It Works:

1. User declares intent     → "Move 1,000 USDC from Arbitrum to Hyperliquid"
2. Solver quotes            → Solver commits to fulfill at destination
3. User signs               → Intent is signed and broadcast
4. Solver fronts capital    → User receives funds on destination chain
5. Settlement               → User's origin funds repay solver (~2 min)

User Experience: Instant usable liquidity. No waiting for finality. No manual bridging. No gas token management on destination chain.

Security Model: Solvers take fulfillment risk. Users receive funds before settlement completes. If settlement fails, solver absorbs loss, not user.

Production Deployments: OpenSea, Phantom, Alchemy

---

Execution Layer

Embedded Signer

Provider: Privy

Security Model: TEE (Trusted Execution Environment) + Shamir's Secret Sharing

Key Management:

• Keys generated inside secure enclave

• Immediately split into two shares:

  • Enclave share (hardware-secured)

  • Auth share (encrypted, requires user authentication)

• Full key exists only during signing, then wiped

• Neither Privy nor XIO can access user keys

Authentication Methods: Email, phone, social login (Google, Apple, X, Discord)

Production Stats:

Metric	Value
Accounts created	75M+
Monthly signatures	47M+
Monthly transactions	85M+
Signing latency	<5ms (on-device)
Compliance	SOC 2 Type II

Trade Execution

Venue: Hyperliquid

Integration: Direct API connection to matching engine

Hyperliquid Architecture:

Hyperliquid runs a purpose-built L1 optimized for trading. The API wallet model aligns with XIO's security architecture:

• API wallets can execute trades

• API wallets cannot withdraw funds (protocol-level constraint)

• Provides CEX-level execution with non-custodial security

Performance:

Metric	Value
Market share (perp DEX)	62%
Open interest	~$13.5B
Throughput	200,000 orders/sec
Finality	Sub-second
Maker fee	0.015%
Taker fee	0.045%

Order Types Supported: Market, Limit, GTC, Post-Only, IOC, FOK, TWAP, TP/SL

---

Transaction Flow

Complete lifecycle of an agent-initiated trade:

┌─────────────────────────────────────────────────────────────────┐
│ 1. SIGNAL                                                       │
│    Agent receives trading signal                                │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 2. VALIDATION                                                   │
│    Smart account validates session key against policies         │
│    • Contract whitelist    ✓                                    │
│    • Function whitelist    ✓                                    │
│    • Size within limits    ✓                                    │
│    • Session not expired   ✓                                    │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 3. ROUTING                                                      │
│    XIO Smart Order Router calculates optimal path               │
│    Net PnL = Price − Impact − Gas − Bridge Fees                 │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 4. BRIDGING (if required)                                       │
│    Relay solver fronts capital at destination                   │
│    Settlement: <10 seconds                                      │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 5. EXECUTION                                                    │
│    Privy embedded signer signs transaction                      │
│    Order submitted to Hyperliquid API                           │
└─────────────────────────────────────────────────────────────────┘
                              ↓
┌─────────────────────────────────────────────────────────────────┐
│ 6. SETTLEMENT                                                   │
│    Position opens on Hyperliquid                                │
│    User dashboard updates                                       │
└─────────────────────────────────────────────────────────────────┘

Total Latency: Seconds (excluding market conditions)

---

Security Model Summary

Layer	Component	Trust Assumption	Failure Mitigation
Custody	Biconomy Nexus	Smart contract correctness	4 audits, formal verification
Session Keys	ERC-7579 Validators	Policy enforcement	On-chain validation, bounded damage
Routing	XIO SOR	Router honesty	User can verify route before signing
Bridging	Relay Protocol	Solver solvency	Solver fronts capital; user pays after receipt
Signing	Privy TEE	Enclave integrity	Shamir splitting, no single point of compromise
Execution	Hyperliquid	Exchange liveness	Direct API, largest liquidity venue

Non-Custodial Guarantee: At no point does XIO hold custody of user funds. Assets remain in user-controlled smart accounts throughout the entire flow.

---

Contract Addresses

To be published upon mainnet deployment

---

Further Resources

• ERC-7579 Specification

• ERC-4337 Specification

• Biconomy Nexus Documentation

• Biconomy Audit Reports

• Relay Protocol Documentation

• Privy Documentation

• Hyperliquid API Documentation