Moove Developer Program

Capxul

Capxul is a financial operations layer for businesses and freelancers where every account is a Gnosis Safe with programmable roles, and where AI agents can hold spending authority or run accounts of their own.

What it is. Capxul is a financial operations layer for businesses and freelancers. Payments are the core of it, but the product covers the whole operation: invoicing, payroll, contractor payouts, spending permissions and budgets, activity history, and analytics over all of it. Anything you would expect from software that handles money coming in and going out.

The account primitive. Everyone who touches Capxul gets a Gnosis Safe. Not just the company. A freelancer working alone gets one. Every staff member gets one. The company itself gets one. Each Safe address is derived deterministically from the owner's email, so an account exists before the person has signed up, and the address never moves when their signing key rotates. Zodiac role modules sit on top, which is how permissions and budgets are enforced on chain rather than in our database. We are non custodial at every step. The account holder controls the funds, not us.

The SDK and the MCP server. The same primitives that power the Capxul app are exposed two ways. There is a developer SDK for building on top of Capxul, and there is an MCP server so an AI agent can drive Capxul directly. This is the half of the product that matters most for this programme, and it is already how agentic payments work for us today.

Three ways agents move money on Capxul.

1. An agent prepares work. Through the MCP server, an agent assembles a payroll run or a batch of payouts and hands it to a human to approve. The agent does the operational work, a person signs.
2. An agent holds spending authority on someone else's account. A Zodiac role is a programmable mandate: which contracts may be called, which functions, with what parameter constraints, up to what budget, over what period. You grant that to a human team member, and you grant exactly the same thing to an agent. The agent transacts inside its limits with no human in the loop, and the mandate is revocable at any moment.
3. An agent has its own Capxul account. An agent can be a staff member in its own right, with its own Safe, its own budget and its own history. Not a key someone is lending it, an account it holds.

Who it is for. Businesses that pay people, freelancers who invoice and get paid, and developers building agent driven financial applications who need an account primitive with real spending controls instead of a hot key.

Track record. We are not new to this. Our V1 product, Paynest, is live with real customers running real payroll volume today. Capxul is the V2, much wider in scope, currently in prototype, with alpha launching in October when we begin onboarding our existing Paynest customers.

Why we need agentic payments. An agent with a mandate on a Capxul account can already pay anyone on an EVM chain. What it cannot do is raise a hosted payment request, move fiat in or out, or reach a counterparty on Solana, Tron or Bitcoin. Those are the gaps Moove fills. We do not want to bolt a payments product onto the side of ours. We want Moove available as a provider underneath the SDK and the MCP server, so that everything already built on Capxul, and everything anyone builds on top of it, inherits that reach automatically.

How we do agentic payments, so the integration point is clear.

Capxul accounts are Gnosis Safes with Zodiac role modules. A role is a programmable spending mandate, scoped to specific target contracts, function selectors and parameter constraints, with budgets and periods attached. Granting a role to an agent is how an agent gets money moving authority that is bounded, auditable and revocable, instead of being handed a private key. We expose this through a developer SDK and through an MCP server, so agents can prepare work for human approval, hold spending authority on an account, or hold an account of their own.

Behind all of that we built one front door, a single quote and pay pair, with providers plugged in behind it as rails. The product never names a provider, so we can add, swap or fail over between them without touching application code, and we are KYB'd and live with our first provider already. This is where Moove fits: as a provider behind that seam, not as a separate API our users call. That matters, because it means every agent already operating on Capxul inherits Moove's reach the day we wire it in, with no change to how it works.

Where we would use Moove, concretely.

1. Ramping. Fiat in and out. Freelancers cashing out to a local bank account, businesses funding a treasury, contractors paid in local currency. This is a live need today and one of the first things we would route through you.

2. Bridging and swapping. Cross chain movement and asset conversion across your 37 chains and 16,000 plus assets. We reach some of this already, so Moove would give us a second route, which matters for corridor coverage, pricing and failover. That is exactly why we built the rail seam rather than hardcoding a single provider.

3. Non EVM reach, the capability we cannot build ourselves. A Gnosis Safe cannot exist on Solana, Tron or Bitcoin, and nothing we integrate today reaches them. Moove Send would let a Capxul account pay a contractor on Tron or Solana out of an EVM account. In markets where Tron is the default rail for stablecoins, that closes a real gap for us.

4. Moove Receive, payment links as the payer half of invoicing. Our invoice flow has an issuer half and no payer half. We would call POST /v1/payment-link with toAmount as a decimal string and the invoice reference in description, which is the only field that travels into the dashboard and therefore our reconciliation key. We then poll GET /v1/payment-link for status reaching completed, read receivedAmount and transactionUrl, and correlate the on chain deposit to the invoice in our ledger. The customer pays in whatever they hold on whatever chain, and the account holder sees one clean settlement.

5. Moove Handles as an optional public identity. We would offer every Capxul account holder an optional Moove handle attached to their Safe. To be clear about what this is and is not: our own contacts and identity model is ours, and we are not proposing to build our address book on your handles. What a handle gives our users is a public, human readable way to be paid into their Capxul account from outside Capxul, by someone who has never heard of us. Companies, staff, freelancers and agent accounts could all carry one. That puts a Moove handle in front of every person on our platform.

The one thing we need from you.

Your docs state that a payment link settles to the authenticated user's default wallet, and that the destination cannot be specified by the caller. A Capxul account is a Safe, a contract rather than a key, so it has no twelve word phrase and cannot be added by import. Connect and sign is the only open route, and that depends on how you verify signatures. Either of the following unblocks us, whichever suits your roadmap:

• Accept an optional destinationAddress on POST /v1/payment-link. The field already exists on PaymentLinkData, it just is not accepted on write. This needs no signature, and we would argue that is correct rather than convenient. A signature proves the right to spend. Receiving requires no proof of ownership.
• Support EIP-1271 on wallet registration. After ecrecover fails, check whether the address has code and call isValidSignature(bytes32,bytes), accepting 0x1626ba7e. That gives you Safe, Coinbase Smart Wallet, Argent and every ERC-4337 account at once. One note that catches most implementations: a Safe validates against its own EIP-712 wrapped message hash rather than the raw message, and getMessageHash(bytes) returns the hash to sign.

Our side is already compatible, and we verified it rather than assuming. Capxul Safes are v1.4.1 with the Safe4337Module as fallback handler, which inherits CompatibilityFallbackHandler, so EIP-1271 is live today. Direct eth_calls against a deployed Capxul Safe on Base Sepolia (0xb547dcbc82fc83913d85ad58f0d763c37c52da2d) return the following. VERSION() returns 1.4.1. getOwners() returns a single owner EOA that can sign. getMessageHash(bytes) returns a hash. And isValidSignature(bytes32,bytes) executes and reverts through Safe's own checkSignatures with Hash not approved on an empty signature. There is no contract work needed on our side.

Two operational notes we would want to discuss. There are no webhooks yet, and our rail design assumes signed webhooks with a dedupe key. We will build polling with reconciliation and adopt webhooks the day you ship them. And there is no documented sandbox. We test against a hermetic fake rail and would need a test key to prove a corridor before going live.

Selected: Live With Users

V1 (Paynest) is live with paying customers and real payroll volume. V2 (Capxul) is in prototype with alpha in October. Q3 states both plainly, so the selection does not overstate the position.

US$10,000

Runway. We are bootstrapped, and this extends the time we can spend building.

Being straight about our position: V1 (Paynest) is live and carries real payroll volume. We do monetise it, but at a very low level. The volume is genuine and the revenue from it is not enough to fund development at the pace we need. V2, Capxul, is what changes that, and we are funding it ourselves in the meantime.

The $10,000 goes directly into engineering time on the Moove integration and the surfaces it needs.

• The rail adapter layer. A Moove adapter behind our provider seam. This is the seam every future provider plugs into, so the work outlasts this one integration.
• The invoice payer flow, end to end. Payment link creation, status reconciliation, deposit correlation against our on chain ledger, and the payer facing invoice page.
• Deposit correlation. Turning on and hardening our chain scanner so inbound money is matched to the account and invoice that expected it.
• Safe message signing in the SDK, so a Capxul account can register itself with Moove under EIP-1271, if that is the route we take together.
• Handle integration, provisioning and binding a Moove handle to every Capxul account, including agent accounts.
• Ramping and bridging corridors through Moove once available, with test coverage and a live corridor proof with recorded receipts.

None of it goes to marketing or tokens. It is engineering time on shipping the integration, and it buys us the runway to do that properly rather than in the gaps around paid work.

Our alpha timeline is fixed. The Moove milestones depend on what you have shipped by then, so M2 onward is written to flex against your roadmap.

M1, alpha launch and integration foundation, October 2026. Capxul V2 alpha goes live and we begin onboarding our existing Paynest customers onto it. In parallel, the Moove adapter is built behind our rail seam, implemented against your OpenAPI schema, with a full test suite against a mock. Evidence: live alpha with onboarded accounts, merged pull requests, passing CI.

M2, first live Moove transaction, November 2026. The first real money movement through Moove in production. Which product depends on what is available. Payment links if the destination question is resolved, ramping or bridging if those land first. We would rather commit to a real transaction through Moove than to one specific endpoint whose timing we do not control. Evidence: transaction hashes, Moove side records, a recorded end to end run.

M3, Moove live for onboarded accounts, December 2026 to January 2027. Moove available as a rail to every account on the alpha, with handles provisioned per account, invoicing settled through payment links, and ramping or bridging corridors in production. Evidence: usage figures, settled invoices from real customers, live URLs.

M4, non EVM payouts, scheduled against Moove Send. First contractor payment to Solana or Tron from an EVM account. This is the capability we cannot build ourselves and the one we most want. Timed to your Send launch rather than ours. Evidence: transaction records on both chains.

To be explicit about the dependency, we would not be using Moove for one thing. Ramping, bridging, payment links, handles and non EVM payouts are five separate integration points, and we expect to reach them in whatever order you ship them.

We expect US$1M to US$5M in transaction value over the next 12 months. The range is wide because growth is not a smooth ramp for us, it is step changes.

Volume is driven by companies. Our core product is payroll, so onboarding one or two larger companies moves the number far more than a steady trickle of small ones. That is why we are targeting company onboarding as the primary growth lever, and why the top of the range depends on a small number of specific deals landing rather than on broad adoption.

Transaction count follows headcount. Payroll is periodic, so each onboarded company contributes a recurring run every cycle, one payment per person, plus invoices and ad hoc contractor payments in between.

Revenue is driven by ramping, and ramping is done by individuals. This is the part worth being explicit about, because it is where Moove sits. We do not monetise payroll volume itself. We monetise the moment a person moves money between crypto and their local currency. Those people are the staff, employees, freelancers and contractors on the receiving end of the companies we onboard. A company brings the volume; its people generate the ramp transactions, and the ramp transactions are the business.

Which is why ramping is the first thing we want to route through Moove. It is not a peripheral integration for us. It is directly on our revenue line, and every person cashing out to local currency is a transaction we would want to put through you. The wider your corridor coverage gets, the more of our user base becomes monetisable.

Paynest (V1, live): https://www.paynest.xyz/

On open source. Our contracts will be open source. We build on Safe, and our own payment contracts are a relatively thin layer on top of it, so there is limited value in keeping them closed and real value in them being independently auditable.

Our SDK and application code stay private, and it is worth explaining why, because we come from an open source background and this is not a philosophical position. It is also not squeamishness about financial code. It is that the current generation of coding agents has made vulnerability discovery cheap, fast and thorough, including obscure supply chain paths that a human reviewer would take weeks to find. Publishing the full source of a non custodial system today is publishing a map for anyone who cares to point an agent at it. We would rather not carry that risk on a product holding customer funds.

We are happy to grant repository access and full visibility to your team on request, including a code walkthrough on a call. We are not asking you to take our engineering on trust, only not to make it public.

Paynest (paynest.xyz). Our V1, and still live today: crypto payroll for businesses paying distributed teams, with paying customers and real volume running through it.

Running payroll in production is where our view of what a payment rail actually has to do comes from. Money that has to arrive, on a date, in the right amount, to people who notice immediately when it does not.

Capxul is the V2 of that product line, built on what we learned doing it.

Grant funds are disbursed in USDC to the Moove handle, and that is also the account whose default wallet we want pointed at a Capxul Safe. It needs claiming before submission.

Six actions, all scored: follow @moovexyz on X, join the X community, join the Discord, join both Telegram channels, and requote the programme post with the link supplied. Plus how we heard about the programme.

all to complete before submitting

Three things worth saying plainly.

We have already done the technical work rather than proposing in the abstract. We read the docs, pulled the OpenAPI schema, read the agent skill file, and verified our own accounts on chain before writing this application. We are happy to walk your team through the working on a call.

We are raising the blocker up front rather than after an award. A payment link cannot currently settle to an address the caller names, and a Gnosis Safe cannot be added to a Moove account by seed phrase because it does not have one. Q4 sets out two ways to solve it, either of which works for us. We would rather you knew that now.

What we most want from this is not the money. It is early access to Moove Send, and a working technical relationship while you are still deciding what to build. Half your product is announced rather than shipped, which we read as an opportunity. We would like to be one of the integrators whose requirements shape it. We are a distribution channel into business and freelancer accounts, and through our SDK and MCP server into whatever other developers build on top of us. That is worth considerably more to both sides than $10,000.

Agreed to the Moove Developer Program Terms and Conditions and confirmed accuracy of all information. Clauses worth remembering.

• Clause 3. Funding is disbursed in tranches against verified milestones, not upfront. Milestones agreed in writing before the first disbursement. Paid in USDC to the designated Moove Handle.
• Clause 5. Moove may withhold or reclaim funds if the project is abandoned, milestones are missed, funds are misused, or fraud is identified.
• Clause 6. Identity and project verification checks, including KYC where applicable.
• Clause 7. Moove may reference our project name, description and progress publicly. We retain ownership of the project and its IP.
• Clause 8. No employment, agency or partnership relationship. We are responsible for our own taxes on funds received.