Addresses, not questions
The custody partner issues endpoints per customer per supported network, under its own permissions. You publish one account number once and never revisit it.
Universal payment account
Routing & normalisation
Routing & execution
Local currency settlement
Reconciliation & records
Platform & embedded accounts
Solutions
Universal payment account
One permanent account number instead of a different set of payment details for every rail. Whatever arrives against it we detect, screen and match to what you were expecting — and the same identity is what money leaves from when you pay out.
One identity
NP-847291. Permanent, for money in and money out, on every rail
Supported rails
USDC and USDT on a defined set of networks, shown at the point of payment
Screened and matched
Every sender screened before settlement; every arrival matched to its intent
The problem it solves
The rail should not be your identity. The account should.
In crypto the wallet address is the identity, so every network means new payment details and a fresh chance to send $40,000 somewhere irreversible. Invert it and the account is permanent while the endpoints underneath are ours to manage — and to rotate, when security or a partner requires it, without your customers ever noticing.
01
02
Detection with a stated policy
We index the supported networks and watch for arrivals against your endpoints. Every network has its own confirmation policy, and reorgs are handled explicitly — a payment is not final because it appeared once.
03
Screening before settlement
Sanctions, illicit addresses, mixers, ransomware and stolen-funds exposure, fraud indicators. Adverse results stop the payment and escalate to a person; the outcome is recorded either way.
What you see
Plain words, not a block explorer.
You are told what arrived, from whom, on what chain, and whether it needs anything doing to it. Nobody has to learn what a chain is.
Detected
14 Mar 10:42:13 UTC$40,000.00 USDC arrivedNewOn Base, from Acme’s treasury wallet · tx 0x7f2a…9c1414 confs
Source screenedClean · result recorded permanentlyDone
Needs normalisingBase is not a rail your settlement partner acceptsNext
Illustrative. Where a payment arrives on a directly supported rail, this row reads nothing to route and there is no normalisation cost at all.
Coverage
A defined set, and a rule for adding to it.
Adding a network is an indexer, a confirmation policy, reorg handling, a hot wallet and gas management. It is real work, so one is added only when customer demand, settlement capability, compliance support, reliable infrastructure and positive unit economics are all present — never for marketing.
| Network | Assets | Status |
|---|---|---|
| Ethereum | USDC, USDT | At launch |
| Base | USDC | At launch |
| Solana | USDC, USDT | At launch |
| Tron | USDT | At launch |
| BNB Chain | USDT | At launch |
| Others | USDC, USDT | On demonstrated demand |
This is the set we support at launch, decided before the build rather than after, and the payment page only ever offers what is genuinely available at that moment.
Would you give a customer this account?
That question matters more than whether you like the idea. Tell us how your foreign customers pay you today, and whether you would replace those instructions with one number.