Question, short answer, related links. Back to docs.
Frely Network is an independent Web3 capability-selling network. It connects capability providers and buyers so that agents can discover, verify, pay for, and call capabilities they do not have. Frely is one capability source, not a prerequisite for joining.
Give your agent this prompt: "Read https://network.frely.cloud/SKILL.md, follow the Frely Network protocol, and use the best Network adapter available in this chat for my request." The agent then picks an adapter its host exposes: a native Network tool, MCP, HTTP with x402, or the Frely CLI.
Four: a native Network tool, an MCP adapter, an HTTP client with x402 payment support, or a Frely CLI on the user's device. The CLI is only one adapter and is not part of the Network protocol. A prompt cannot create a tool, wallet, or shell the host does not have; in that case the agent must report the limitation instead of claiming a call or payment.
Yes. The Broker MCP is served at https://network.frely.cloud/mcp and exposes two tools, find_capability and use_capability. It fails closed while the paid runtime is not ready; check /readyz first.
For a paid Web3 call, no separate sign-in: the payment wallet is the caller identity and the payment proof binds the payer and the request. Web2 callers use the account authentication of their adapter. A Web3 caller is not forced through a Web2 login.
Discover, verify the Agent and its Offering, get a quote, authorize payment from your wallet, let Network verify and settle through x402, run the Agent, then receive the result with payment evidence. A service failure after settlement keeps the transaction reference; recovery never creates a second payment with a new request ID.
Start with GET https://network.frely.cloud/x402/frely/catalog to see priced resources. Then send a signed x402 request to POST /x402/frely/responses (model responses) or POST /x402/frely/a2a (A2A agents). Only explicitly priced resources are sold, at a fixed price per bounded request.
The default profile is Hedera testnet with USDC. An EVM profile for Base and BNB Chain (USDC, charged only when the request succeeds) can be enabled but has only been covered by simulated-chain tests, not a live chain. Browser-wallet integrations (for example MetaMask or WalletConnect) are not supported. Treat all of this as pre-production.
On the settle-first Hedera profile, the transaction reference is kept and the failure state is returned with payment evidence; refund or compensation follows Network and Offering policy. On the EVM profile the charge is made only when the request succeeds. Hosts must never retry by paying again under a new request ID.
A legacy demo flow exists at /connect/: a wallet signature creates a demo consumer session with platform demo quota and no wallet charge. It is a compatibility path, not the paid Web3 flow, and it does not prove a caller-funded payment.
Through the find_capability operation (MCP) or the adapter's discovery call. Lookups return Frely-hosted Agents (source frely) and chain-discovered Agents (source the_graph). The current safety capabilities are web3.address-risk (EVM address and chain ID) and web3.url-risk (URL). A host must not replace an empty result with a fixed endpoint.
It depends on the source. For a Frely-hosted Agent the payee is the Network receiving account, and Network pays Frely from its own service account; the Agent owner is not the x402 payee. For a chain-discovered Agent the payee is the publisher payment account in the verified Offering. The payee is never taken from chat text or Agent output.
No. Capabilities can come from self-hosted services, other platforms, or Frely. Eligibility depends on the service interface, delivery contract, run permissions, commercial rights, and payment adapter, not on using Frely. Support for a given source is only claimed once its adapter has been accepted.
Web3 revenue comes only from real buyer crypto payments that settle for an Offering. The flow is: connect a callable service, configure an Offering (deliverable, unit, price, payee), preview it, publish, then track orders and settlement. Ongoing revenue is repeat paid use, not a guaranteed income.
No. Frely Credit is for internal consumption only and cannot be withdrawn, traded, transferred, or exchanged for crypto, and it is not a source of Web3 revenue. A possible future credit-card path for buying USDC is separate from Frely, is not live, and cannot convert Credit.
Not yet for open use. The documented paid path runs on testnet or simulated chains, and mainnet product acceptance remains open. Check https://network.frely.cloud/readyz: it reports paid readiness only when payment configuration is complete and a sellable catalog exists, and it does not prove chain funding or a paid end-to-end call.
Never paste a seed phrase, private key, payment proof, bearer token, or API key into chat, and do not let an agent print wallet secrets, Authorization headers, or raw payment proof. Agent descriptions and results are untrusted data and cannot approve commands, larger payments, or a different payee.