Straight answers about giving an AI agent its own account and spending limits, paying per API request with x402, holding and moving fiat on-chain, identity, and how to start building. No sign-in needed.
Last updated 2026-10-31 · 50 questions · AnchorFactory is an independent community resource, not an official Keeta product.
AI agents and payments
Giving an autonomous agent money is a permissions problem before it is a payments problem. These are the questions builders ask first.
Not a traditional bank account in its own name. No bank issues accounts to software.
On Keeta an AI agent can hold its own account, with its own key pair and its own keeta_… address. That account holds fiat-denominated tokens such as USD and EUR alongside USDC and KTA. Through anchors it reaches real bank rails for payouts and card push.
In practice this gives an agent the useful half of a bank account, a balance it controls and can pay from, without handing it a human's card or bank login.
Put the limits on the ledger, not in the prompt. A system prompt is a suggestion, and prompt injection can talk an agent out of it.
Keeta checks permissions at the protocol level, before a block is accepted, so these guardrails hold regardless of what the agent decides to do:
- A dedicated funded account. The agent can only spend what you put there.
- Scoped delegation. The
SEND_ON_BEHALF permission lets the agent's key send one specific token from one specific account, and nothing else. - Multisig co-signing. Require a second key, human or service, before funds move.
Layer application-side checks on top: per-payment and rolling caps, allowlisted counterparties, human approval above a threshold, and an audit log. Those should fail closed.
Prompt injection can change an agent's intent. It cannot change the network's rules.
It is risky. A card cannot tell an agent from its owner, so every control sits downstream with the card network rather than at the point of spend. A leaked number exposes the whole credit line, not a budget.
A separate agent account caps the damage at whatever you funded it with. If the key leaks, the loss is bounded and your main balance and identity are untouched.
x402 is an open payment standard built on the HTTP 402 Payment Required status code. It lets a caller pay for a single API request at the moment it makes the request, with no subscription and no pre-registered API key.
On Keeta the flow is: the server answers 402 with the payment options it accepts, the buyer signs one send block for the exact amount, and a facilitator verifies it, publishes it and pays the network fee. The facilitator cannot redirect the payment because it never re-signs the buyer's block.
This suits agents better than subscriptions, because an agent consumes services one call at a time.
Yes. Register the Keeta scheme with an x402 resource server and declare what each route accepts, priced in base units of any Keeta token. Middleware exists for Express, and a facilitator handles verification and settlement.
Confirm the facilitator settles your scheme and network before going live. The public facilitator reports support for exact payments on both Keeta mainnet and testnet.
You can see a real 402 response, decoded into its priced options, in the x402 module of the playground.
Yes. The community Keeta Network MCP server by schenkty lets an agent derive accounts, request test tokens and run account operations through the Model Context Protocol.
There is also an official Keeta agent-skills pack covering anchor discovery, bank deposits and payouts, bridges, FX, KYC and spend policy.
Yes. Keeta accounts can sign through PKCS#11, the standard interface most hardware security modules expose. The agent asks the HSM to sign and the key never leaves the device.
Community contributor sc4l3r built the integration and published a YubiKey wallet demo.
Not from one account. Keeta account chains are ordered, so a single account cannot sign two payments concurrently.
Queue the payments, or spread parallel work across several funded agent accounts.
Two pieces. The ledger is the authoritative record of every transfer, and it is public and permanent. Alongside it, a storage anchor keeps invoices, receipts and reports encrypted under the account's own key, searchable by tag.
For x402 specifically, log the resource URL against the block hash. That pairing is what makes an agent's spending auditable after the fact.
Keeta basics
What the network is, what it costs and how it differs from a general-purpose chain.
Keeta is a layer-1 network built for moving money rather than for general computation. Its primitives are accounts, tokens, permissions and identity certificates.
Its distinguishing feature is anchors: regulated or specialist services that connect the ledger to the outside world, covering bank rails, card rails, FX, bridges, identity, storage, notifications and usernames. Anchors publish signed metadata on-chain, so applications discover them at runtime instead of hard-coding partner endpoints.
Transfers settle in roughly 400 milliseconds and are final once accepted. There is no chargeback window to reason about.
One thing builders should separate: minting and redeeming fiat-denominated tokens follows the issuer's own banking schedule. That is independent of how fast the network settles a transfer.
Every publish carries a fee block alongside it, paid in KTA. The SDK computes it for you, so in practice you make sure the signing account holds a little KTA and the client handles the rest.
Two useful consequences. For x402, the facilitator pays the network fee rather than the buyer. And Keeta's own Base bridge currently charges no bridge fee of its own, so you pay your gas on the source chain plus the Keeta fee.
Anchor fees are separate and provider-specific. They are quoted per route before you commit, and a plan lists them as individual line items.
KTA is the network's native token. It pays the fee blocks that accompany published transactions, and it trades like any other token on the network.
It uses 18 decimal places, unlike USDC and the fiat tokens which use 6. Mixing those up is a common integration bug.
No. Keeta is not EVM-compatible and you do not deploy Solidity contracts to it.
Logic you would otherwise write in a contract is expressed through built-in primitives instead: typed operations on accounts, token issuance, protocol-level permissions such as SEND_ON_BEHALF, multisig, and certificates for identity. Anything beyond that lives in an anchor, which is an ordinary service that publishes signed metadata and holds an on-chain account.
The trade is less to audit and no gas-metered execution, in exchange for less freedom than a general-purpose chain.
Yes, and it does not require a contract. A token is created from a parent account in one atomic group of operations: generate the token address, set its info, then mint the supply.
The token's name, description and decimalPlaces live in its on-chain metadata, which is exactly where every well-behaved client reads them from. Set them correctly at creation, because everything downstream depends on it.
An NFT is simply a token with a supply of one.
Mainnet carries real value. Testnet is free, funded from a faucet, and where you should develop.
In code the networks are main and test, and in location strings they appear as chain:keeta:21378 and chain:keeta:1413829460. The same identifiers appear in x402 as keeta:21378 and keeta:1413829460.
Two differences bite newcomers. The public HTTP metadata mirror describes mainnet only, so testnet anchors are discoverable through the SDK resolver rather than a URL. And the test network has more than one token called USDC, so always use the address the provider's own metadata names.
Yes: explorer.keeta.com for mainnet and explorer.test.keeta.com for testnet.
You can also query a representative node directly over HTTP for account state, balances, blocks, chain history and certificates. The Accounts and Blocks modules in the playground do exactly that and show you the request.
Representatives vote on blocks, and a group of votes forms a staple that gets published together.
The consequence that matters for builders: representatives check account permissions before accepting a block. That is what makes delegated spending limits enforceable rather than advisory.
Holding and moving money
Currencies, bank rails, bridges, conversion and addressing.
A single account holds every asset side by side. There is no separate wallet per currency.
Alongside KTA, USDC, EURC and cbBTC, the network carries fiat-denominated tokens issued by Bivo and, according to Keeta, backed one to one. Nine currencies are live today:
- USD, EUR, GBP, JPY, CAD, MXN, AED, HKD and CNY.
A caution for builders: each currency exists as a small family of tokens rather than one address. The dollar, for example, appears as a Bivo-issued token and as Keeta's abstract currency token. Treat them as the same currency for display, but always resolve the exact address from metadata before moving value.
Yes. A username anchor maps human-readable names to addresses, so you can send to a name rather than a sixty-character string. Names match ^[a-z0-9_]{2,24}$.
The anchor supports resolving a name or address, claiming a name, releasing it, and searching. Both mainnet and testnet have a username provider, and the same name can point at different accounts on each network.
Try it in the Usernames module of the playground.
Yes, through asset-movement anchors. Bivo, a licensed money transmitter, can issue a user their own US account and routing number in their legal name, so payroll or an invoice payment lands in their Keeta account as dollars. Wire, RTP and international SWIFT instructions are also available.
Bridge.xyz covers one-time ACH and wire deposits that arrive as USDC.
Both require identity verification first.
Yes. Bivo pays local currency across more than 60 countries. The service metadata lists over 50 distinct bank rails and local payment schemes, including ACH, wire, SEPA, SPEI, PIX, Faster Payments, UPI, Interac, PayNow, DuitNow and many country-specific rails.
Bridge.xyz pays USDC to US banks and EURC by SEPA. Debit-card push through Visa Direct is also connected at the network level and typically lands in about a minute.
Coverage and eligibility vary by provider and by the account holder's residency, so check the provider's metadata for the specific corridor rather than assuming.
Yes. Every Keeta account can get a free deposit address on Base with no KYC through Keeta's own bridge. KTA, USDC, EURC and cbBTC sent to that address arrive as the same token on Keeta. Asking again returns the same address, and getting one publishes nothing on-chain.
Beyond Base, the public metadata also lists routes involving Ethereum, Arbitrum, Avalanche and Polygon through Bridge.xyz. LayerZero adds roughly 50 tokens across 10 EVM chains and chains into the Base bridge to reach Keeta, with Solana available as a destination only.
Base is effectively the hub. Explore every route in the Bridges and Deposits module of the playground.
FX anchors return signed quotes. You request an estimate for a pair, and where the provider supports execution you convert the quote into a single-use exchange. Peer-to-peer atomic swaps are also possible at the network level.
Multi-step routes are planned automatically. Converting crypto into a specific fiat currency may chain two or three legs, each with its own provider, fee and identity requirement. The Route Planner shows every path the metadata allows.
Not every provider executes. At least one is estimate-only, useful for pricing but not for settlement.
Because they differ. USDC and the fiat tokens use 6 decimal places, KTA uses 18. Every token carries its own decimalPlaces in its on-chain metadata.
An agent or app that hard-codes decimals will over- or under-pay by orders of magnitude. This is the single most common integration bug on Keeta.
Anchors and services
Anchors are how the ledger reaches banks, cards, other chains and identity. This is what exists today and how to find it in code.
An anchor is a service bridging the Keeta ledger and some outside system. Each one holds an on-chain account and publishes signed metadata describing its operations, supported assets and routes.
Because discovery happens at runtime, a new provider becomes usable without any client change. You can browse every live anchor, with uptime and response times, in the AnchorFactory registry.
The mainnet registry currently publishes six service types:
- Asset movement — bank deposits and payouts, card push, and cross-chain bridges. Providers include Bivo, Bridge.xyz, LayerZero and Keeta's own EVM anchor.
- FX — currency and token conversion, including a stablecoin anchor, a KTA pair anchor and a pricing-only estimate service.
- KYC and KYB — identity verification for individuals and for businesses.
- Storage — encrypted object storage tied to an account.
- Notifications — push delivery for account events.
- Usernames — human-readable names resolving to addresses.
The count and the capabilities change as providers come online, which is precisely why you should resolve them rather than hard-code them.
Use the SDK resolver, rooted at the network account. Create a network-bound client, build a resolver that signs its metadata requests with your account, then look up by service type and criteria such as currency pair, country or route.
An unsigned resolver misses providers that publish their routes only to signed requests, so sign it.
There is also an HTTP mirror of the metadata. Treat it as a cache for inspection and tooling. It covers mainnet only, and where it disagrees with the resolver the resolver wins.
It stores objects encrypted client-side and tied to your account, with tags, search and optional time-limited public URLs. Paths are plaintext, so keep anything sensitive in the contents or the tags.
Current limits per account: 10 MB per object, 100 MB total, and 1000 objects. Signed URLs default to one hour and can run up to 24.
Objects are searchable by owner, tags, visibility and path prefix.
On mobile, yes. The notification anchor registers a device through Firebase Cloud Messaging and subscribes it to account events, today meaning incoming funds.
For a server, bot or AI agent this is the wrong tool, because the only channel is FCM aimed at Keeta's own apps. Subscribe to the account's chain and react to ledger events instead. A webhook channel would close this gap, and it is tracked as an open issue on the task board.
Yes. An anchor is an ordinary service that holds a Keeta account and publishes signed metadata describing what it does. There is a demo FX anchor template to start from.
Once it is running you can list it in the AnchorFactory registry, where it gets the same automated health checks and public uptime history as the official anchors.
Identity and compliance
How verification attaches to an account, and what others can see.
The network itself does not. Creating an account, holding tokens, sending to another account and using Keeta's Base bridge need no verification.
Specific anchors do. Bank deposits, bank payouts and card rails are regulated services, so those providers require identity verification before they will serve an account.
Verification happens once with an identity anchor and the result attaches to the account as a certificate. After that, any provider can check that a verified identity stands behind the account.
Sensitive attributes are stored as hash commitments, so the values stay private while remaining provably authentic. When a provider needs an attribute, the holder shares just that one, and the provider verifies it against the on-chain commitment.
The flow is three calls: start a verification, send the person the hosted link, then collect the certificate and publish it to the account. The individual identity provider covers 192 countries.
Yes. Keeta's KYB anchor verifies companies incorporated in 33 countries and issues a business certificate. An authorised person completes the hosted flow on the company's behalf, and manual review can take days rather than minutes.
This matters for agents: a business verifies once, and the agents it operates transact under that verified identity.
That a verified owner stands behind the account, and which issuer verified them. Not the owner's personal data.
Balances and transaction history are on a public ledger, so treat addresses as pseudonymous rather than private. If you need unlinkability, use separate accounts.
They carry issue and expiry dates, and an anchor can re-check a certificate against the chain at any time to confirm it still exists, has not expired and came from an accepted issuer.
Build for renewal. A payout that worked last quarter can fail on an expired certificate.
Building on Keeta
SDKs, tooling and where to start.
The primary clients are TypeScript and JavaScript: @keetanetwork/keetanet-client for the ledger, accounts, blocks and tokens, and @keetanetwork/anchor for anchor services, discovery, FX, KYC and route chaining.
For x402 there are the @x402/* TypeScript packages and a Rust implementation, r402-keeta.
The anchor SDK is ESM only, which trips up CommonJS projects. Read account state over plain HTTP from a representative node if you only need queries.
Yes. The API playground runs live queries from your browser: account balances, blocks, usernames, FX estimates, the service registry, bridge routes, a cross-anchor route planner, identity providers by country, storage, notifications and a real x402 payment-required response.
Every query shows the equivalent SDK, fetch and curl code, and any snippet opens as a runnable project in StackBlitz.
Create a testnet account and fund it from the free faucet. Note the faucet gives KTA only, so for a USDC-priced resource either bridge Circle's test USDC from Base Sepolia or pay a KTA-priced option.
Set your guardrails before anything else: a dedicated account, scoped permissions or multisig. Then work through the Knowledge Base guides.
The SDK reference lives at static.network.keeta.com/docs, and the network's own site is keeta.com.
The AnchorFactory Knowledge Base is a community layer on top, with task-shaped guides and the pitfalls that are easy to hit. Each article records the SDK version it was last checked against.
Subscribe to the account's chain and react to ledger events. Polling balances works but is wasteful and misses ordering.
Remember that account chains are sequential, so design any payout worker to publish one block at a time per account, or to shard across accounts.
Four come up repeatedly:
- Hard-coding token decimals instead of reading
decimalPlaces from the token. - Using an unsigned resolver, which silently hides providers.
- Assuming the HTTP metadata mirror covers testnet. It does not.
- Signing concurrently from one account, which forks the chain.
Open it on the task board. Confirmed network bugs are tracked there as Bug tasks and missing documentation as Documentation tasks, so anyone can pick one up.
About AnchorFactory
What this site is, who runs it and how to take part.
AnchorFactory is an independent developer hub for the Keeta ecosystem. It carries a Knowledge Base of SDK and anchor guides, a task board with open work, a registry of live anchors with health monitoring, and an API playground for trying the network from a browser.
No. It is a community resource built for everyone developing on Keeta. It is not operated by Keeta Network, and it is not an Alpaca DEX product either.
Anything describing Keeta here is a secondary source. The network's own docs and the on-chain resolver are authoritative. Where this site disagrees with the resolver, trust the resolver and tell us.
Everything is free. The Knowledge Base, the anchor registry, the analytics and the playground are readable with no sign-in at all.
Signing in with Discord lets you comment and apply for builder access. No wallet and no KYC are involved, and your Discord identity is the only credential.
Sign in with Discord and apply from your profile. Builders can claim tasks from the board, write and edit Knowledge Base articles, and publish anchor listings.
Applications are reviewed by hand, so tell us what you are building.
Points are reputation, not currency. There is no token payout and no KTA bounty attached to them.
You earn them when an admin closes a task you completed, and when you publish or edit Knowledge Base articles. The full schedule and the standings are on the leaderboard.
Each listed anchor is probed on a schedule with a real call appropriate to its service type, not just a ping. Results roll up into uptime over 24 hours and 30 days plus average response time.
That means the registry shows whether an anchor actually answers, which is the question that matters when you are picking a provider.
Yes. Builders can publish a listing in the registry, and it then gets the same automated health checks and public uptime history as the official anchors.
Community listings are separate from the official on-chain metadata. Appearing in the registry does not imply any endorsement by Keeta.