Skip to main content
FibX is a CLI-based DeFi execution layer that enables both developers and AI agents to perform on-chain operations — token swaps, transfers, balance checks, cross-chain portfolio inspection, and Aave V3 position management — across Base, Citrea, HyperEVM, and Monad. It combines Fibrous aggregation for optimal swap routing with flexible wallet authentication — use your own private key directly, or create a server-managed wallet via Privy.

​
Core Capabilities

Portfolio View

Consolidated cross-chain portfolio view with USD valuations, token balances, Aave collateral and debt, and total net worth across all supported chains.

Token Swaps

Optimal routing via Fibrous aggregation with configurable slippage (default: 0.5%). Supports the tokens and integrated DEX liquidity available through Fibrous on each chain.

Transfers

Send native tokens (ETH, cBTC, HYPE, MON) or ERC-20 tokens to an address, with command-specific preflight and preview support.

Aave V3

Supply, borrow, repay, withdraw, and browse active markets on Base. ETH supply and repay can auto-wrap, ETH withdraw can auto-unwrap, and borrowing the ETH market returns WETH.

Agent Skills

Ten pre-built skills that allow AI agents to check prices, authenticate, inspect balances and portfolios, trade, send, manage Aave positions, verify transactions, and configure RPC endpoints — all through natural language.

​
How It Works

FibX operates as a CLI tool (npx fibx@latest) that communicates with the Fibrous aggregation stack and, when needed, a backend server for Privy-managed wallet operations. Transaction paths use command-specific estimates or contract simulations where implemented, but those checks do not guarantee that an on-chain operation will succeed.

​
Supported Chains

​
Security Model

FibX moves real funds. Treat client confirmation, preview output, signing policy, and backend credentials as separate controls; none replaces reviewing the final transaction request.

Signing-Policy Scope

With the default configuration, new Privy wallets are attached to a default-deny policy whose transaction rules allowlist configured chain IDs and cap the native value field. Existing wallets retain the policy ID attached when they were created. The cap does not limit ERC-20 amounts encoded in calldata; those transactions, along with message and typed-data requests, also rely on fibx-server validation. A custom WALLET_POLICY_ID is checked for existence, not compared with the default rule set.

Client Confirmation Hints

Transactional MCP tools carry the destructiveHint annotation. MCP clients may use this metadata to request confirmation, depending on the client and its configuration.

Signing Modes

In Privy mode, transaction signing returns a signed transaction payload to the CLI; message and typed-data signing return signatures. The raw private key is not returned. The default policy includes a key-export denial rule, but administrators with policy-management credentials can change controls, so fibx-server and the Privy app secret remain trust boundaries. In private-key mode, FibX encrypts the imported key at rest with AES-256-GCM and signs locally.

Preview Limitations

--simulate and simulate=true provide no-broadcast previews for supported write paths, but the returned checks are command-specific. Gas estimates are included only where they can be calculated safely, and an Aave action preview does not perform on-chain validation. A preview does not guarantee that later execution will succeed.
The policy is defense in depth on the normal signing path, not a containment guarantee. The Privy app credentials authorize both signing and policy administration, so the backend that holds them is the administrative trust boundary.

​
Typical Workflow

A typical wallet workflow follows four steps:
1

Authenticate

Import your private key for direct usage, or log in via email OTP to create a Privy server wallet. Either method creates a session that persists across commands.
2

Check Funds

Query native and ERC-20 token balances on the target chain, or inspect the full cross-chain portfolio with USD valuations.
3

Execute

Review the amount, tokens, destination, chain, and any approval. Use the command-specific preview options where appropriate, then submit the operation on-chain.
4

Verify

Check the transaction status and obtain the block explorer link.

​
Quick Example

​
Two Ways to Use FibX

Run commands directly in your terminal. Ideal for developers who want programmatic access to DeFi operations or need to script workflows.

​
Telegram Bot

fibx-telegram-bot puts the same execution layer in a chat window. It drives the FibX MCP server, exposing capabilities such as quotes, swaps, transfers, portfolio, and Aave through natural language rather than CLI flags.
  • Bring your own model. Choose OpenAI, Claude or Gemini and supply your own API key. There is no shared key and no centralized inference billing; keys are encrypted at rest. /deletekey clears the provider configuration and encrypted key, FibX session/config/cache, pending authentication, and chat history; price alerts remain active.
  • Per-user runtime state. Every active user gets a dedicated MCP process and separate HOME/XDG paths. These processes still run under the same OS account, so this is application-level separation rather than an OS sandbox.
  • Price alerts. /alert ETH above 4000 notifies you once when the price is reached — no login or AI key required.

​
Resources

npm Package

fibx v0.8.2 — install and version history

Agent Skills

Ten pre-built skills for AI agent integration

MCP Configuration

Connect FibX to Cursor, Claude Desktop, VS Code, Windsurf, and Antigravity

Telegram Bot

Chat-based DeFi execution with your own AI model