> For the complete documentation index, see [llms.txt](https://docs.fast.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fast.xyz/faq.md). # FAQ Answers about Fast agent payments, SDK selection, networks, settlement, x402 integration, and protocol security assumptions. For implementation questions, use [Choose your Fast tool](/get-started/choose-your-tool.md). Assistants can retrieve the same guidance through [Markdown or the documentation MCP server](/get-started/agents.md). ### About Fast #### What is Fast? Fast is payment infrastructure for programmatic transactions. It enables agents, APIs, merchants, and services to request, authorize, send, and settle payments — fully programmatically, across both crypto and fiat rails. It processes payments, including agentic payments and micropayments, in a massively parallel manner. Fast delivers sub-second finality, near-zero fees, and uncapped throughput that scales with the rising agent economy. Fast needs no blocks, no miners, and no consensus protocol. Instead, all transactions are concurrently processed and settled. #### Is Fast a blockchain? No. Fast is fundamentally different from blockchains. Blockchains serialize all transactions into an ordered chain of blocks, even when those transactions have nothing to do with each other. This creates a bottleneck. Fast observes that most transactions are independent — Alice paying Bob has nothing to do with Carol paying Dave — and processes them in parallel. The result is orders of magnitude more throughput without sacrificing security or decentralization. #### How fast is Fast? Published performance figures are protocol benchmarks, not a latency or throughput guarantee for every deployment or cross-chain workflow. See the [FastSet whitepaper](https://arxiv.org/abs/2506.23395) for the benchmark setup and assumptions. For a cross-network movement, distinguish Fast-side settlement from EVM confirmation, relay, and destination execution. #### How does Fast prevent double-spending without ordering transactions? Each account has a nonce — a sequence number that increments with every transaction. Validators enforce per-account ordering: they will not sign a second transaction from the same account at the same nonce. This makes double-spending impossible without compromising a quorum of validators. Transactions from different accounts are processed in any order because they are weakly independent — the final state is the same regardless of ordering. #### Is Fast decentralized? Yes, but not at the cost of what a blockchain takes. Because Fast validators do not communicate with each other, adding more validators does not slow down the network. Every validator independently processes transactions and converges to the same state. Anyone can run a validator on commodity hardware. *** ### For Developers #### How do I get started? Install the SDK and send your first payment in under two minutes: ```bash npm install @fastxyz/sdk ``` The SDK provides `Signer`, `FastProvider`, and `TransactionBuilder` for building, signing, and submitting transactions. For complete setup instructions and runnable examples, see the [Fast SDK on GitHub](https://github.com/fastxyz/fast-sdk). No API keys. No account registration. No configuration files. #### What's the learning curve? For payments — minimal. Use the CLI for quick interactions (`fast account create`, `fast send`, `fast info balance`) or the SDK for programmatic access (`Signer`, `FastProvider`, `TransactionBuilder`). The SDK handles all the complexity of signing and network communication. If you can call a function, you can use Fast. See the [CLI README](https://github.com/fastxyz/fast-sdk/blob/main/app/cli/README.md) and [SDK README](https://github.com/fastxyz/fast-sdk/blob/main/packages/fast-sdk/README.md) for details. For advanced use cases — custom tokens, cross-network transfers, or direct JSON-RPC access — see the [SDK Reference](/sdk-references/overview.md). #### How do payments work for AI agents? An agent uses the SDK or CLI to create a signer, and starts sending and receiving payments immediately. The signer is created locally — no registration, no approval process. Agents can: * **Pay other agents** for services (data, compute, API access) * **Receive payments** from other agents or users * **Manage balances** autonomously Fast-native payments target low-latency settlement. Fees and completion times depend on the network and workflow; EVM, AllSet, x402, and hosted-provider steps may add costs or waiting time. If a submission outcome is unknown, reconcile it before paying again. *** ### Security and Trust #### What cryptographic guarantees does Fast provide? Fast uses Ed25519 digital signatures and a Byzantine fault-tolerant quorum model (3f+1 validators, at most f faulty). Four guarantees hold under this model: * **Safety:** Only one transaction can be settled per account per nonce — double-spending is impossible * **Determinism:** The order validators receive messages does not affect the final state * **Monotonicity:** Once a transaction becomes settleable, it stays settleable * **Liveness:** If any honest validator makes progress, all honest validators eventually do #### How is the protocol verified? The FastSet protocol has been mathematically proved correct in the [FastSet whitepaper](https://arxiv.org/abs/2506.23395). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## 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 following URL with the `ask` and `goal` query parameters: ``` GET https://docs.fast.xyz/faq.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `build a script that syncs our docs to a CMS` lets GitBook tailor the answer to that use case. 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.