01
Local access is disconnected
Users hold value in mobile-money and digital wallets; agent services settle in stablecoins. The connection stays fragmented and market-specific.
Local-wallet infrastructure for AI agents
Let your users fund AI agents with the wallet they already have.
st4bl gives agent platforms one integration for local-wallet funding, controlled agent spending, and local-currency payouts. Users fund through a familiar wallet. Agents transact within owner-defined limits. Earnings and unused balances return in local currency.
First corridor: M-PESA Kenya.
People own the funds. Agents receive permission. Code enforces the boundaries.
M-PESA
First wallet corridor
x402
Machine-payment rail
ARP
Policy enforcement
Licensed partners
Conversion and payout
The gap
The agent economy assumes everyone already holds stablecoins.
Many agent-payment services settle in stablecoins such as USDC. Most people don't hold them. GSMA counted 2.3 billion registered mobile money accounts in 2025, with Africa accounting for around two-thirds of global transaction value.¹ When a product asks those users to fund an agent, they stop. Building around it means a separate funding and payout integration in every market, each with its own licence, partner and compliance review. That's a separate technical, commercial and compliance project for every new market.
02
Agents need bounded authority
Software should never get unrestricted access to someone's funds. Authority has to be scoped, capped and revocable.
03
Agent earnings need a route back to everyday money
Value that settles on-chain only helps an owner once it reaches the wallet they actually use, in the currency they actually spend.
Why now
Agents have learned to transact. Local wallets aren't connected yet.
x402 and programmable wallets are making machine-native payments practical, so agent platforms can let software buy data, compute, inference and services. But access still starts with stablecoins or card credentials. The next problem is distribution: letting people fund and benefit from agent activity through the wallets they already use.
How it works
Five steps from everyday money to agent activity
One integration. The owner stays the principal at every step, and the agent only ever acts inside the mandate the owner set.
01
Fund
The owner starts with the wallet they already use for everyday money.
02
Control
The owner sets how much the agent can spend, what it can buy, and when approval is required.
03
Transact
The agent pays only for authorised APIs, data, compute, inference and services.
04
Earn
Revenue is attributed to the verified owner and reconciled against the agent's activity.
05
Withdraw
Eligible value returns through a supported local wallet and a licensed payout partner.
The same five steps, technically
M-PESA
partner conversion
USDC wallet
x402
partner payout
M-PESA
Use cases
What becomes possible
Research agents
A research platform gives each user's agent a controlled budget for paid data, market intelligence and model inference.
Developer agents
A coding agent buys approved compute, testing tools and API calls without holding unrestricted payment credentials.
Agent marketplaces
An agent earns for completing digital tasks; the marketplace attributes the revenue and pays the owner through a local wallet.
Small-business agents
A business funds an operations agent from its everyday wallet and caps spending to approved services and daily amounts.
For platforms
The financial control plane for agent platforms
One integration for local funding, controlled agent spending, earnings attribution, reconciliation and local-currency payouts. st4bl doesn't replace wallets, stablecoins or payment providers — it connects them through one policy and orchestration layer.
Local-wallet funding
Top-ups from a mobile-money or digital wallet, collected and converted by a licensed partner.
Owner-controlled agent wallets
Every wallet is attributed to a verified person or business.
Agent mandates
Caps, approved uses, expiry and revocation, set by the owner.
x402 payments
Machine-native settlement for APIs, data, inference and compute.
Earnings attribution
Income booked to the owner of record, with a reconcilable trail per wallet.
Local-currency payout
Conversion and payout back to the owner's own wallet, through licensed partners.
Who this is for
Agent platforms
AI marketplaces
API and MCP providers
Developer platforms
Digital wallets
Coverage
Corridor roadmap
Your users don't hold USDC. They hold this. We connect to mobile-money and digital wallets through licensed local partners, starting with Kenya.
Phase 1 · Building now
M-PESA
Kenya
Partner pilot in development
-
Phase 2 East Africa
-
M-PESA
Tanzania
-
Airtel Money
Kenya, Uganda, Tanzania
-
MTN MoMo
Uganda
Follows the first corridor, reusing the same partner model.
-
-
Phase 3 West Africa
-
MTN MoMo
Ghana
-
Orange Money
Côte d'Ivoire, Senegal
-
Wave
Senegal
Requires local licensed partners in each market.
-
-
Phase 4 South and Southeast Asia
-
GCash
Philippines
-
bKash
Bangladesh
Same architecture, different regulatory regimes.
-
Sequencing follows platform demand and licensed-partner coverage, not the other way round. We add a corridor when a platform has users in it and a licensed partner can support it.
Wallet names and logos are the property of their respective owners. st4bl is not affiliated with, endorsed by, or partnered with these providers unless stated.
What makes this different
The missing layer between wallets and agents
Local-wallet networks move everyday money. Agent-payment protocols move machine payments. st4bl sits between them, connecting a verified owner, a familiar local wallet, a controlled agent mandate and an agent-payment rail in one auditable workflow.
Local access
Funding and payout through licensed wallet partners.
Owner control
Limits, approved uses, expiry and revocation.
Agent transactions
Authorised payments for data, compute, inference and services.
Reconciliation
Earnings attribution, balances, activity and local payout.
Status
Where we are today
Live (previous product)
Payment rails integrated with Wise and IntaSend.
Published
ARP policy, state, execution and audit model on GitHub.
In build
M-PESA funding into an owner-controlled agent wallet.
Planned
x402 purchase, earnings attribution and local-wallet payout.
We'd rather tell you what's working than imply more than there is. Regulated collection, conversion and payout sit with licensed partners.
Security
Autonomy needs boundaries
An agent is software acting for a person. The controls have to live in code that the agent cannot talk its way past.
Human ownership
Every human-owned agent wallet belongs to a verified person or business. Agents operate; they never own.
Least-privilege mandates
Authority is scoped to a cap, an approved use and a period — and can be narrowed or revoked by the owner.
Deterministic enforcement
Mandate checks run in code before any payment call. They are not instructions given to a model.
Execution locks and idempotency
Idempotency keys and execution locks are designed so a payment cannot be duplicated under retry.
Human approval thresholds
Above the owner's threshold, a payment waits for explicit human authorization or it does not happen.
Append-only audit trail
Intents, mandate decisions, executions and payouts are written once and never rewritten.
AI proposes. Mandates authorize. Code enforces.
Infrastructure
Built between wallets, agents and settlement protocols
-
Layer 1Local accessThe mobile-money or digital wallet a person or business already uses.
-
Layer 2Licensed financial partnersCollection, conversion, custody and payout, performed under partner licences.
-
Layer 3st4bl control layerOwner attribution for the human-owned agent wallet, mandates, policy enforcement, transaction state, reconciliation and audit.
-
Layer 4Agent activityAuthorised purchases of data, compute, inference and services over agent-payment rails.
-
Layer 5Local returnEligible value converted and paid out to the owner's own local wallet.
Where the line sits
st4bl is the orchestration and control layer. Licensed partners handle regulated collection, conversion, custody and payout.
st4bl handles wallet attribution, mandates, policy enforcement, transaction state, reconciliation and audit.
Licensed partners
Collection · conversion · custody · payout
st4bl
Attribution · mandates · policy · state · reconciliation · audit
Protocols
Works with the emerging agent-payment stack
We build to the emerging standards rather than around them, so a platform integrating st4bl isn't buying into a private scheme.
Pay
x402-ready
Settlement for machine-purchased APIs and services.
Authorize
AP2-aligned
Mandates for owner-approved agent activity.
Enforce
ARP
Deterministic policy, state, execution and audit controls.
Developers
One API for local funding and agent settlement
The shape we're building to, published early so integration partners can push back on it before it sets. Not yet available — design feedback is exactly what a pilot conversation is for.
- POST/owners/{owner_id}/agentsRegister an agent operated on a verified owner's behalf.
- POST/wallets/{wallet_id}/funding-intentsStart a local top-up through a licensed collection partner.
- POST/wallets/{wallet_id}/mandatesSet caps, approved uses and approval thresholds.
- POST/payments/authorizeCheck a proposed payment against the mandate.
- POST/payoutsPay out to the owner's local wallet via a licensed partner.
Interface design in progress — endpoints and payloads may change.
View the full proposed
interface on GitHub ↗
What you integrate once
A platform calls st4bl to open a wallet for a user, set the mandate that user chose, and authorize each payment the agent proposes. Funding and payout are handed to licensed partners underneath the same API, so you don't take on a separate integration, licence and compliance review per market.
The control layer is reachable over MCP, so a tool-calling agent can request an authorization without a language model ever holding payment credentials, and the identity model is A2A-ready for agent-to-agent work.
ARP is the open part: the policy, state, execution and audit semantics are published so you can see exactly what a mandate decision means before you depend on it.
FAQ
Questions we get asked first
Does the agent own the funds?
No. A human-owned agent wallet is attributable to a verified person or business at all times. The agent operates the wallet under a mandate the owner sets, and the owner can narrow or revoke that mandate. Agents receive permission to spend; they never take ownership.
Does st4bl hold customer money?
No. Collection, conversion, custody, settlement and payout are performed by licensed partners. st4bl provides the orchestration, policy and audit layer above them. st4bl is not a bank, exchange, custodian or money transmitter.
Is M-PESA support live?
Not yet. The M-PESA funding flow is in development for partner pilots. Our previous product integrated payment rails with Wise and IntaSend, and the ARP policy model is published on GitHub — everything else on this page is in build or planned.
Why USDC?
Stablecoin settlement is what agent-payment rails such as x402 currently speak, and it makes a payment programmable enough to check against a mandate before it executes. Owners don't have to manage stablecoins themselves: they fund in local currency and are paid out in local currency, with conversion handled by licensed partners.
What can an agent buy?
Only what the mandate permits. The owner sets the spending cap, the per-transaction limit, the approved uses — typically data, compute, inference and services — and the threshold above which a payment needs explicit approval. Anything outside the mandate does not execute.
Who is st4bl for?
Agent platforms, AI marketplaces, developer products, API providers and digital wallets with users in mobile-money markets. It is infrastructure sold to those companies, not a consumer product.
Discuss a pilot
Do your users get stuck before the first agent payment?
We're looking for agent platforms and marketplaces with users in mobile-money markets. If local funding or payout is blocking adoption, let's design the first corridor together.
Building an agent platform, marketplace or x402 service? Tell us where your users are — or email [email protected].
First corridor: M-PESA, Kenya. Funding and payouts through licensed partners.