permixaDocs

PERMIXA DOCUMENTATION

Payments & treasury

Routine purchases and movement of treasury funds have separate permissions.

A payment buys something

An agent submits a typed intent. Permixa checks policy and reserves budget before issuing a bounded payment authorization. The customer-local Signer independently verifies it before using a configured wallet.

The current hands-free pilot completes approved Base Sepolia USDC x402 purchases through a separately configured local worker. Direct USDC and L402 have historical adapters and test evidence, but remain disabled under the current local spending policy until bounded fees and final Signer checks are implemented. A merchant must support a configured route; Permixa is not a universal checkout for arbitrary websites.

A receipt reports what the Signer observed. Independent settlement evidence provides a separate check. A paid resource retry and a wallet payment are distinct steps; inspect the merchant result as well as payment evidence.

Treasury moves working capital

Treasury groups verified EVM, Solana and Bitcoin accounts alongside enrolled accounts with balance evidence. The manual allocation planner includes BTC, ETH, SOL and USDC. Opening Treasury reads Base Sepolia ETH/USDC and Solana devnet SOL/USDC for connected accounts, with observation time and a Refresh balances button. Bitcoin testnet4 address balances are confirmed-only provider observations; pending activity, Signet, Lightning and mainnet are excluded. These display-only observations expire after five minutes and do not become treasury accounting or USD allocation values; unknown balances remain unknown. Allocation targets and planning recommendations are informational until a separately approved execution occurs.

Choosing all payment networks does not authorize Permixa to sell BTC, bridge USDC, fund accounts or rebalance automatically. Automatic rebalancing remains disabled.

Human-approved execution

  1. Review exact economics. Source amount, fee bounds, minimum destination, provider, route, destination, refund terms and expiry must be explicit.
  2. Cloud approval. Use the required fresh authenticated approval for that immutable version.
  3. Local approval. The customer-local Signer separately approves the same economic hash and constraints.
  4. Short-lived authorization. It is issued only after the prerequisites are ready. The BTC conversion workflow uses 120 seconds, within the Signer's 300-second maximum.
  5. Verify and execute once. The Signer matches all bindings and its hard policy, journals execution and reconciles the resulting identity.

An expired quote cannot be revived. A new economic version needs fresh approval; never reuse approval for changed economics.

Know the testnet limits

Current rails are adapter-specific and have different readiness requirements. Base Sepolia, Solana devnet and Lightning Signet can be represented in agent policy; this does not mean every rail is enabled for execution. Cross-chain and BTC conversion demonstrations require separate operator setup and explicit authority.

BTC โ†’ USDC is not a guaranteed demo result.

The recorded September 2026 attempt reached a verified BTC refund after the provider could not complete the conversion. That is recovery evidence, not successful USDC delivery. A future attempt is a new governed economic decision.

Mainnet, real money and automatic rebalancing are disabled. Testnet fee tolerances are not production defaults.

For completed capabilities, assisted setup and remaining work, see the current roadmap.