# 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](https://eips.ethereum.org/EIPS/eip-7579)
* [ERC-4337 Specification](https://eips.ethereum.org/EIPS/eip-4337)
* [Biconomy Nexus Documentation](https://docs.biconomy.io/)
* [Biconomy Audit Reports](https://github.com/bcnmy/nexus/tree/main/audits)
* [Relay Protocol Documentation](https://docs.relay.link/)
* [Privy Documentation](https://docs.privy.io/)
* [Hyperliquid API Documentation](https://hyperliquid.gitbook.io/hyperliquid-docs)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://xio-docs.gitbook.io/xio-docs/appendix/tech-specs.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.