Internal briefing · 7 September 2026
Written for the Capxul team ahead of our call with Moove. No prior crypto plumbing knowledge assumed. The short version: Moove is another payment provider, most of what it does overlaps things we already reach, and the part that doesn't overlap is the interesting part.
If you read nothing else
01 · The basics
Moove is a consumer payments app, phone and web, with a developer API bolted on this year. A person signs up, gets a wallet, claims a name like @aaron, and can send, receive and swap crypto. In Nigeria they can also move money in and out of a bank account.
Three things it is not, because the name misleads:
And the detail that matters most for us: a "Moove wallet" is just an ordinary wallet. There is nothing special about it. It's a standard address made from a twelve-word phrase, the same kind MetaMask makes. Moove keeps a database mapping @aaron to that address. That's the whole trick. Their handle system is a lookup table, not a technology.
Which means integrating with them is ordinary web-API work. There is no new chain to support, no new programming language, no new signing scheme. Our smart-contract code is untouched.
02 · Our side
We are not new to this. Paynest shipped and ran real payroll, and it is still live with customers today. Capxul is the second product, and Chainrails, one of our first integrations, was Paynest's most loyal payroll customer. We have a track record and a live commercial relationship in exactly this space.
Capxul is a financial operations layer for businesses and freelancers. Payments are the core of it, but the product is everything around them too: invoicing, payroll, contractor payouts, spending permissions and budgets, activity history, and analytics across all of it. Whatever you would expect from software that handles money coming in and going out.
Everyone who touches Capxul gets a Safe. Not just the company. A freelancer working alone gets one. Every staff member gets one. The company itself gets one. A Safe is the standard, widely audited smart account used across the industry, and we attach Zodiac roles to it so permissions and budgets are enforced on chain rather than in our database. Each address is derived from the owner's email, so the account exists before anyone signs up and never moves when their signing key changes.
The same primitives are exposed two ways beyond the app itself: a developer SDK, and an MCP server so an AI agent can drive Capxul directly. That is what makes agentic payments work for us, and it is covered properly in section 4.
Money leaves an account through what we call rails. A rail is just a provider. We deliberately built one front door with providers plugged in behind it, rather than wiring each provider into the product separately. Chainrails is the first, and we completed KYB with them this week. Moove would be the second.
DIAGRAM 1 · MOOVE IS A PEER OF CHAINRAILS, NOT A NEW LAYER
03 · Agents
This is the part the Moove programme is about, and it already works. Because a Capxul account is a Safe with Zodiac roles attached, a role is a programmable spending mandate: which contracts may be called, which functions, with what limits, over what period. You grant that to a human team member. You grant exactly the same thing to an agent. It is bounded, auditable and revocable at any moment, which is what makes it safe to give an agent money-moving authority instead of handing it a private key.
We expose this through the SDK and through an MCP server, so an agent can work with Capxul directly. There are three modes, and we use all three.
Mode one
Mode two
Mode three
The relevance to Moove is direct. An agent operating on Capxul today can pay anyone on an Ethereum-family chain. It cannot raise a hosted payment request, move fiat in or out, or reach Solana, Tron or Bitcoin. Moove sits underneath the SDK and the MCP server as a provider, which means every agent already running on Capxul inherits that reach the day we wire it in, with no change to how it works.
04 · The fit
This is the honest comparison. Most of what Moove does, we already reach through Chainrails. That overlap is a good sign, not a problem. It means Moove slots into a shape we already designed, rather than us inventing a reason to use them.
| Capability | What we have today | What Moove adds |
|---|---|---|
| Same-chain payment | Direct rail, Safe to Safe | nothing new |
| Cross-chain transfer | Chainrails, via four bridges | Same capability, different provider, useful as a fallback |
| Swapping one coin for another | Chainrails | Much wider selection of coins |
| Crypto out to a bank | Chainrails, via Yellow Card and three others | Nigeria only, different banks. Overlaps |
| Cash in to crypto | Chainrails | Nigeria only. Overlaps |
| Solana, Tron, Bitcoin | nothing, we are Ethereum-family only | The one thing no current provider gives us |
| A shareable payment page | not built, our invoicing work hasn't started | Live today. Would give us the payer half of invoicing for free |
| A name instead of an address | not built, contacts is parked | @handle, already working |
Three rows are genuinely new, and two of them cover work we have on the roadmap but haven't started.
Every chain we support today is in the Ethereum family, which is what lets an account have one address that works everywhere. Solana, Tron and Bitcoin work differently, and a Safe cannot exist on them. So we could never offer those chains as a Capxul account. But through a provider like Moove we can pay someone on them. For anyone paying contractors in markets where Tron is the default rail for stablecoins, that is a real gap closed.
05 · The mechanics
The clearest first use is money coming in. A business or a freelancer raises an invoice in Capxul. We ask Moove for a payment page. The customer pays in whatever coin they happen to hold, on whatever chain, Moove converts it, and the money arrives in that person's own Capxul account.
DIAGRAM 2 · MONEY IN, VIA A MOOVE PAYMENT PAGE
Every step here works today except the last arrow. Moove currently sends the money to a Moove account, not to the account holder's own Capxul.
06 · The one blocker
Moove's payment pages currently pay into a wallet on the Moove account that created them. You can't tell them to pay somewhere else. Their docs are explicit that the destination can't be chosen by the caller.
To point that at a Capxul account, the address has to be registered on the Moove side. Moove has two ways to register an address: type in a twelve word phrase, or connect a wallet and sign a message to prove it's yours. A Safe has no twelve word phrase, because it is a program rather than a key, so only the second route is open.
That route is a solved problem industry wide. There is a standard, EIP-1271, for exactly this: instead of doing the maths to check a signature, you ask the account itself whether the signature is good. Moove would add one branch to their existing check. Our side already supports it, and we verified that directly against a live Capxul account.
DIAGRAM 3 · THE CHANGE WE'D ASK FOR, IN FULL
Real results from a live Capxul account on the test network. The last line is the important one: the function exists and ran. An account without this support would fail differently.
| What we asked the account | What it answered |
|---|---|
| What version are you? | Safe 1.4.1 |
| Who controls you? | One owner, the key our user holds, which can sign |
| What should I sign? | 0x37774d66…7ff1 |
| Is this signature valid? | “Hash not approved”. It checked, and correctly said no to an empty signature |
Instead of the above, Moove could simply let us name the destination when we create the payment page. The field already exists in their data, they just don't accept it as an input. This needs no signature at all, and there is a good argument it is the right design anyway: you prove ownership to spend money, not to receive it. Nobody proves they own a letterbox before you can post them a letter.
07 · Honest risks
Design boundary
Half-built vendor
Plumbing
One more, worth stating plainly for the commercial side: on money coming in through Moove, we don't control the transfer, so we can't take a margin on it the way we can on payments we send. That doesn't make it worthless, because it makes invoicing work, but it is not a revenue line on its own.
08 · The call
Ordered by how much the answer changes our thinking. The first two are the only ones that decide whether this happens at all.
09 · Where this lands
Apply, and take the call. The fit is real rather than manufactured. Moove does things we already built a home for, plus three things we want and don't have. The integration is ordinary API work, with nothing touching our contracts.
It is not on the critical path. Chainrails is the first rail and stays first. Nothing here should reorder that. What we want out of the conversation, in order: the destination change, early access to their send product, and a working relationship with a team that is still deciding what to build, which is the best time to be talking to them.
The funding is the least interesting part of the offer. Early access to what they build next is worth considerably more.