https://api.sandbox.conduit.financial) runs real testnet for crypto: on a supported testnet chain (Base, Ethereum, Polygon, Solana, Stellar, Tempo — see Supported testnets below; Tron is not supported) a crypto transfer both broadcasts and is signed on a public testnet, and you verify it on that network’s block explorer. A crypto transfer is a real on-chain movement, not a mock. Real testnet is a property of the whole sandbox cluster, not a per-request choice, and it applies to every customer and wallet you provision.
Because a crypto transfer is a real on-chain movement, it runs the same compliance, finality, and signing steps a live crypto flow runs. This page walks the path from funding to a credited deposit, and calls out the traps a mocked run never hits.
What real testnet covers
- It applies to every crypto transfer that leaves a wallet: the crypto source leg of an offramp or a crypto conversion on
POST /v2/orders, and a crypto withdrawal onPOST /v2/payouts. Those transfers move on a real testnet and need a real signature; the FX conversion and the fiat payout stay mocked. - It also applies to crypto delivered into a wallet by Conduit: the delivery leg of an onramp (Conduit → customer wallet) and the destination leg of a crypto conversion are real on-chain transfers too. The customer signs nothing for these (Conduit sends them), but they broadcast a real
txHash, take minutes to finalize, and can occasionally be delayed before they settle. - It is a sandbox feature — real testnet runs only on a sandbox cluster, never on the live API.
Before you start
A customer’s account. A customer’s wallet account is provisioned once, the first time it gets a wallet, and every wallet it adds afterward shares that same real testnet custody. For a non-custodial customer this happens when you claim non-custodial control (see Add a crypto wallet); for a custodial customer it happens on its firstPOST /v2/customers/:id/wallets call.
A way to sign for real. A real broadcast is signed through the wallet’s normal payout approval. Conduit sets the signing mode per organization, with an optional per-customer override (see Signing modes for what each mode means and commits you to); read GET /v2/customers/:id → signingMode before you claim. Every sandbox organization defaults to programmatic_unattended today, unless yours was explicitly set otherwise, so a customer you provision now claims with a machine-signer roster out of the box, with no sign-off needed (see Quickstart Step 9.2 and Multi-signer wallets).
Supported testnets
A claim that omits
chains provisions a wallet on each chain in the default set — Base, Ethereum, and Polygon. Solana and Stellar are real, supported chains outside that default: name them in chains to get a wallet on either.
A Stellar wallet receives testnet USDC once it reads status: "active". A non-custodial Stellar wallet reads pending until its signers approve a one-time on-chain setup, which the wallet.awaiting_setup_signature webhook announces (see Stellar setup).
Tron is excluded from the default set because it cannot transact here. POST /v2/quotes, POST /v2/orders and POST /v2/payouts answer 422 CHAIN_NOT_SUPPORTED when either side, or the payout destination, is on Tron, and no quote, order or payout is created. A claim that names tron in chains still creates a wallet for it.
A Tempo wallet holds OUSD on this sandbox (see Tempo). Get test OUSD from the Tempo testnet faucet. Test OUSD has the same contract address as OUSD on mainnet.
End-to-end walkthrough
Prerequisites: a sandbox API key, and the base URLhttps://api.sandbox.conduit.financial.
1. Create a customer and a wallet
Create a customer, then its first wallet on a supported chain — Add a crypto wallet walks the non-custodial claim; a custodial customer instead callsPOST /v2/customers/:id/wallets directly (see Before you start). The wallet object’s address is a real address on that chain’s testnet — capture it as the address you will fund.
An EVM address is shared across Ethereum, Base, and Polygon because those wallets share one key, but each chain is a separate wallet resource with its own id and its own balance. Funds are only spendable by the wallet on the chain you sent them to, so fund the chain the wallet is on — the same 0x… address on another chain holds a different balance.
2. Fund the wallet from a faucet
A real broadcast spends real testnet funds, so send the asset you will move — for example test USDC — to the wallet’saddress. Get test USDC on any supported testnet except Tempo from the Circle testnet faucet. Gas is sponsored on every supported chain, so you never fund native ETH, POL, SOL, or XLM yourself.
The faucet sends from an address the customer has never registered, so the deposit will park at the sender-information gate below before it credits — that is expected, not an error. See the next step to clear it.
3. Let the deposit clear
The inbound faucet transfer is a real deposit, so it passes two gates before its balance is spendable — the same gates a live deposit passes. Chain finality. The balance stays pending until the transfer is final on its network. Watch for thetransaction.completed webhook; it fires once the deposit credits.
These are the network’s real thresholds — the same ones live uses — so a testnet deposit can take a few minutes. A deposit that does not reach finality in about ten minutes parks for an operator instead of crediting. To continue without waiting on an operator, call
POST /v2/sandbox/transactions/:id/simulate/terminal with {"outcome": "completed"}: it re-runs the finality probe on the same deposit.
The sender-information gate. A deposit can park awaiting sender information and emit transaction.awaiting_sender_information. Into a customer wallet it parks when the sender is not registered (any amount), when the amount is 10,000 units or more (even from a registered sender), or when sourceAddress ends in DE5E11F1. A transfer into the funding address of a deposit-funded order never parks: an unregistered sender, or a sourceAddress ending in DE5E11F1, is returned as a deposit_return.
A faucet sends from an address the customer has never registered, so every first faucet deposit from that address parks here. Clear it with register: true on that first deposit, and every later deposit from the same address passes without parking:
originator shape when the sender isn’t a person.
In sandbox the gate’s deadline is compressed to about ten minutes. After it, the deposit stays held until you clear it with the same call.
The gate mechanics and the deterministic sandbox drivers are covered in full under Deposits — sender information.
Once both gates clear, transaction.completed fires and the deposit credits the wallet’s balance.
Where to go next
- Spend the credited balance on a crypto withdrawal: approve the signature and watch it broadcast.
- Or route it through an OFFRAMP order to pay out to a bank account.
Limitations
- Tron cannot be used on this sandbox: a Tron wallet cannot transact even once created. A quote, order or payout on Tron is refused with
422 CHAIN_NOT_SUPPORTED, and a claim that omitschainscreates no Tron wallet — namechains: ["tron"]explicitly to get one anyway. - OUSD on Ethereum and Base cannot be used on this sandbox: neither testnet has an OUSD token. A quote, order or payout with OUSD on Ethereum or Base is refused with
422 CHAIN_NOT_SUPPORTED, andGET /v2/asset-chain-pairsdoes not list those pairs. Use OUSD on those chains on your live organization. - USDC on Tempo cannot be used on this sandbox: Conduit cannot detect a test USDC deposit on Tempo. A quote, order or payout with USDC on Tempo is refused with
422 CHAIN_NOT_SUPPORTED, andGET /v2/asset-chain-pairsdoes not list that pair. Use OUSD on Tempo here, and USDC on Tempo on your live organization. - Solana and Stellar are real, supported chains outside the default claim: pass
chains: ["solana"]orchains: ["stellar"]to provision one. - Automated testnet deposit detection runs against a shared capacity limit, so at high volume a testnet deposit can be detected with some delay.