Key terms in wallet infrastructure, blockchain APIs, and AI agent tooling.
Wallet Infrastructure
Wallet infrastructure is the backend layer of APIs, SDKs, and services that lets companies embed blockchain wallet functionality (key management, signing, balance queries, and transfers) into their own products without building it from scratch.
Traditional wallet development requires teams to run full nodes, manage private keys, handle nonce tracking, and normalize data across chains. Wallet infrastructure providers abstract this into a unified API surface, reducing integration time from months to days. The infrastructure typically includes transaction construction, fee estimation, multi-chain routing, and webhook-driven event notifications.
How WalletSuite implements this
WalletSuite provides wallet infrastructure as an SDK, REST API, and MCP Server covering 79+ blockchains with normalized data formats across all of them.
MCP Server (Model Context Protocol)
An MCP server is a lightweight process that exposes domain-specific tools to AI models via the Model Context Protocol, an open standard created by Anthropic for connecting LLMs to external data and actions. Tools can include querying balances, preparing transfers, and looking up token prices.
MCP follows a client-server architecture where AI hosts (Claude Desktop, IDEs, custom agents) connect to MCP servers over stdio or HTTP. Each server declares a set of typed tools that the model can invoke during a conversation. No SDK integration is required on the client side.
How WalletSuite implements this
WalletSuite's MCP Server exposes on-chain wallet operations across every supported blockchain, letting AI agents query balances, resolve tokens, prepare transfers, sign, and broadcast through natural-language prompts.
Explore MCP Server→AI Wallet Agent
An AI wallet agent is an autonomous or semi-autonomous software agent powered by a large language model that can interact with blockchain wallets on behalf of a user or another system. It checks balances, prepares transactions, and manages on-chain assets using natural-language instructions.
Unlike traditional wallet UIs, AI wallet agents accept natural-language instructions and translate them into wallet operations. They typically connect to wallet infrastructure via MCP or direct API calls. Key design constraints include transaction safety (agents prepare but do not sign by default), policy gates that restrict which operations an agent can perform, and multi-chain resolution so the agent handles chain selection automatically.
How WalletSuite implements this
WalletSuite's MCP Server turns any Claude, GPT, or custom LLM agent into a wallet agent with band-filtered permissions and policy-gated signing.
Build an AI wallet agent→Multi-Chain Wallet
A multi-chain wallet is a wallet that manages keys, balances, and transactions across multiple blockchains from a single interface or API, rather than requiring separate wallet software for each network.
Multi-chain wallets solve the fragmentation problem: without one, a business handling Ethereum, Solana, and Bitcoin needs three separate integrations with different data formats, signing schemes, and fee models. A unified multi-chain wallet normalizes these differences behind a consistent data model with standardized balance queries, transaction construction, and token resolution.
Wallet as a Service (WaaS)
Wallet as a Service is a cloud-hosted model where a provider manages the full wallet stack (key generation, custody, signing, and transaction submission) so that businesses can offer wallet functionality to their users without operating their own key infrastructure.
WaaS serves fintech apps, exchanges, and neobanks that want to add crypto features without the operational burden of key management and HSM provisioning. The service boundary typically sits between the application layer (UI, business logic) and the cryptographic layer (key derivation, signing). WaaS providers offer APIs for account creation, policy-based access controls, and audit-ready logging.
Transaction Construction
Transaction construction is the process of building an unsigned blockchain transaction before it is signed and broadcast to the network. It involves selecting inputs, encoding calldata, estimating gas or fees, and setting chain-specific parameters.
Each blockchain has its own transaction format: Ethereum uses RLP-encoded transactions with gas estimation, Bitcoin uses UTXO selection, and Solana uses instruction-based messages. A wallet infrastructure provider normalizes this complexity behind a single prepare_transfer or build_transaction call. The output is an unsigned payload that the caller signs with their own key, maintaining custody separation. Proper construction also includes nonce management, fee priority estimation, and token contract resolution.
Token Resolution
Token resolution is the process of mapping a human-readable token identifier (such as a symbol like USDC or a name like 'USD Coin') to the exact contract address and chain where that token is deployed, handling ambiguity when the same symbol exists on multiple chains.
Token symbols are not unique: USDC exists on Ethereum, Solana, Polygon, Arbitrum, and dozens of other chains, each at a different contract address. Token resolution verifies the asset against a curated registry, returns the canonical contract address for the target chain, and flags ambiguous matches so the caller can choose. This prevents misrouted transfers, one of the most common and costly errors in both programmatic and AI-driven wallet operations.
Policy Gate
A policy gate is a rule that restricts what an AI agent or API consumer can do with a wallet. Policies define allowed chains, spending caps, expiry windows, and required confirmations before a signing or broadcast operation proceeds.
Policy gates sit between the request and the key material. When an agent calls sign_transaction or send_transaction, the system checks the request against the policy bound to that wallet and agent token. If the request violates a rule (wrong chain, expired token, over budget), the operation is denied before the key is ever decrypted.
How WalletSuite implements this
In WalletSuite's OWS implementation, policies are JSON documents stored in the encrypted vault alongside the wallet they protect.
Band Filtering
Band filtering is a permission model that groups wallet operations into escalating tiers (read, prepare, sign, broadcast) and exposes only the tiers you enable. An agent configured with read and prepare bands cannot sign or broadcast, regardless of what it requests.
The four bands form a progression: read lets an agent query balances, prices, and transaction history. Prepare adds the ability to build unsigned transaction payloads. Sign unlocks local key decryption and signature generation. Broadcast allows submitting signed transactions to the network.
How WalletSuite implements this
WalletSuite's MCP Server resolves active bands at startup by intersecting the configured bands with the agent token's allowed bands, so neither side can escalate beyond what the other permits.
Non-Custodial Wallet
A non-custodial wallet is a wallet where the user holds their own private keys and no third party can access, move, or freeze the funds. The wallet software facilitates transactions but never takes possession of the key material.
Non-custodial wallets shift security responsibility to the user: if the key is lost, the funds are unrecoverable. This tradeoff is accepted because it eliminates counterparty risk. In an infrastructure context, non-custodial means the API or MCP server builds and returns unsigned transactions for the caller to sign with their own key.
How WalletSuite implements this
WalletSuite's default mode is non-custodial: prepare_transfer returns an unsigned payload and never touches the private key.
Wallet SDK
A wallet SDK is a client library that provides typed functions for wallet operations (key derivation, signing, balance queries, transaction building) so developers can integrate wallet functionality without making raw API calls or handling low-level cryptography.
A good wallet SDK abstracts chain differences behind a consistent interface: the same method signatures work whether the underlying chain uses ECDSA or Ed25519 signing, UTXO or account-based transactions.
How WalletSuite implements this
WalletSuite's SDK is a TypeScript package with full type coverage. It shares types with the MCP Server, so tool schemas and SDK method signatures stay in sync.
Gas Abstraction
Gas abstraction hides the complexity of blockchain transaction fees from the end user or calling application. Instead of requiring the caller to hold the native token, estimate gas limits, and set priority fees, the infrastructure handles fee calculation and payment behind the scenes.
Without gas abstraction, every transaction requires the sender to hold the chain's native token (ETH on Ethereum, SOL on Solana) in sufficient quantity to cover the fee. This creates onboarding friction and multi-token management overhead. Gas abstraction can take several forms: the infrastructure estimates and includes fees automatically, a paymaster contract sponsors the gas, or the fee is deducted from the transferred token via a meta-transaction.
How WalletSuite implements this
WalletSuite's API handles fee estimation and gas optimization as part of transaction construction.
Key Derivation
Key derivation is the process of generating multiple private keys from a single seed or mnemonic phrase using a deterministic algorithm. Each key maps to a unique blockchain address, and all keys can be recreated from the original seed.
The dominant standard is BIP-44, which defines a hierarchical path format: m/purpose'/coin_type'/account'/change/index. For example, m/44'/60'/0'/0/0 produces the first Ethereum address, while m/44'/195'/0'/0/0 produces the first Tron address from the same seed. This lets a single 12- or 24-word mnemonic back up wallets across many chains.
How WalletSuite implements this
WalletSuite's OWS vault uses BIP-39 mnemonics with BIP-44 derivation paths, generating chain-specific keys from one seed per wallet.
HD Wallet (Hierarchical Deterministic)
An HD wallet generates a tree of key pairs from a single root seed, following the BIP-32 standard. Any branch of the tree can derive child keys without exposing the parent key, and the entire tree can be restored from the original mnemonic.
The hierarchy enables organizational structure: one branch per blockchain, one sub-branch per account, one leaf per address. This is more practical than storing independent keys for every address, because a single backup (the mnemonic) covers all current and future addresses. HD wallets are the foundation of most modern wallet software.
How WalletSuite implements this
WalletSuite's OWS vault creates HD wallets with 12-word BIP-39 mnemonics and derives chain-specific keys using standard BIP-44 paths.
Custody Model
A custody model defines who holds the private keys that control a blockchain wallet. The three main models are self-custody (user holds keys), custodial (a third party holds keys), and hybrid (keys are split or co-managed between parties via MPC or multisig).
The choice of custody model affects security, compliance, and user experience. Self-custody eliminates counterparty risk but puts full responsibility on the user. Custodial solutions simplify the user experience but introduce trust requirements and regulatory obligations. Hybrid approaches like MPC (multi-party computation) split the key so no single party can sign alone.
How WalletSuite implements this
WalletSuite supports multiple custody models: non-custodial by default (prepare_transfer returns unsigned payloads), or self-custodial via OWS (keys encrypted in a local vault the user controls).
