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. 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 gives a business a treasury account it genuinely controls. Under the hood that account is a Safe — the standard, widely-audited business wallet used across the industry. The address is derived from the owner's email, so the account exists before anyone signs up.
Money leaves that 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 — 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 · 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 — 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 Invoices 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 a business have one account address that works everywhere. Solana, Tron and Bitcoin work differently — a Safe cannot exist on them. So we could never offer those chains as a Capxul treasury. But through a provider like Moove we can pay someone on them. For a business paying contractors in markets where Tron is the default, that is a real gap closed.
04 · The mechanics
The clearest first use is money coming in. A business 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 the business's Capxul treasury.
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 business's own treasury.
05 · 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 treasury, the treasury address has to be registered on the Moove account. 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 — it's a program, not a key — so only the second route is open.
And that route is a solved problem industry-wide. There's 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 — we verified this 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's a good argument it's 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.
06 · 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 — it makes invoicing work — but it's not a revenue line on its own.
07 · 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.
08 · 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.