​

Withdraw Fiat: Fix the Payout Amount with amountSide

​

What Changed

• amountSide on the v2 quote and execute endpoints (master wallet and child address) and the v2 exchange-rates endpoint: source (default) treats amount as the stablecoin amount to send; target treats it as the fiat amount the recipient must receive.
• With amountSide: "target", the stablecoin debit is derived from the quoted rate and rounded up to the asset’s decimal precision, so the payout is never short of the requested fiat amount.
• The parameter is optional and defaults to source, so existing integrations are unchanged. The v1 withdraw-fiat endpoints do not support amountSide.

​

What you need to do

​

Address Validation Endpoint

​

What Changed

• GET /addresses/validate: pass a blockchain slug and an address, and the response tells you whether the address is valid for that chain. For EVM blockchains, a valid address is returned in its EIP-55 checksummed form. The endpoint uses the same validation rules as the withdrawal endpoints and supports every Blockradar blockchain — EVM chains, Tron, Solana, and Stellar.
• Validation happens offline against the chain’s address format — no on-chain lookup or AML screening is performed, so responses are fast. Standard API rate limits apply, so validate on form submission rather than on every keystroke.
• An invalid address returns 200 with isValid: false. A 404 means the blockchain slug is unknown or unavailable, and a 400 means the request itself is malformed — so you can distinguish “bad address” from “bad request”.
• AML lookup hardening: sending a duplicated blockchain query parameter to /aml/lookup now returns a 400 instead of a 500.

​

What you need to do

​

Network Fees in Webhook Payloads

​

What Changed

• networkFee: the total network fee paid by your Blockradar managed wallets for the transaction flow, in the chain’s native token and USD. Null on events where you bore no fee, such as deposit.success where the depositor paid the gas.
• networkFees: a per fee breakdown. Each entry carries the operation, the wallet that paid, the amount in native and USD, and its own transaction hash for on chain verification. Entries sponsored by Blockradar are marked PLATFORM or PROVIDER and are excluded from the networkFee total.

​

What you need to do

​

Stellar: Soroban Contract and Muxed Recipients

​

What Changed

• Muxed recipients (M...): Withdrawals accept muxed addresses for all assets. Funds settle in the underlying G... account, and no memo is attached — the routing ID is embedded in the address itself.
• Soroban contract recipients (C...): Token withdrawals (e.g. USDC, EURC) can be sent to Soroban contract addresses. The transfer executes on the token’s Stellar Asset Contract via Soroban RPC. Contract recipients are valid for token assets only — sending native XLM to a C... address returns a 400 error.
• Soroban transactions on signing endpoints: The /signing/transaction and /signing/broadcast endpoints accept Soroban transactions (Stellar Asset Contract transfers or custom contract invocations). Simulate and assemble the transaction before submitting it for signing.

​

What you need to do

​

cNGN Contract Address Updates

​

What Changed

• New cNGN deployment: Updated contract addresses for cNGN across Ethereum, BNB Chain, Base, Asset Chain, and Arc
• Previous addresses relabeled: Existing addresses are now marked as “Old v2” in the dashboard
• New network support: cNGN is now available on the Arc network

​

What you need to do

• Go to your dashboard and add the new cNGN assets (look for the ones without the “Old” label)
• Update your integrations to use the new contract addresses
• Previous addresses will continue to work during the transition period

​

New Contract Addresses

​

Test cNGN Tokens

​

Virtual Accounts API Breaking Changes

​

Why This Changed

​

What Changed

​

New Endpoints

​

Pagination Details

​

New Features

• Virtual account labels: Add custom labels to organize accounts (e.g., “Customer A”, “Payroll”)
• Account regeneration: Generate new account numbers with reason tracking for audit purposes
• Transaction history: Query transactions linked to specific virtual accounts

​

Migration Guide

const response = await fetch(`/wallets/${walletId}/virtual-accounts`);
const account = await response.json();

console.log(account.accountNumber);
console.log(account.bankName);

const response = await fetch(`/wallets/${walletId}/virtual-accounts`);
const { data, meta } = await response.json();

// Handle empty array case
if (data.length === 0) {
  console.log('No virtual accounts found');
  return;
}

// Get the first account (equivalent to old behavior)
const account = data[0];
console.log(account.accountNumber);
console.log(account.bankName);

// Or iterate through all accounts
for (const account of data) {
  console.log(account.accountNumber);
}

// Pagination info available in meta
console.log(`Page ${meta.currentPage} of ${meta.totalPages}`);

const response = await fetch(`/wallets/${walletId}/virtual-accounts/${virtualAccountId}`);

if (!response.ok) {
  console.log('Virtual account not found');
  return;
}

const { data } = await response.json();
console.log(data.accountNumber);

​

Example API Response

{
  "message": "Virtual accounts retrieved successfully",
  "statusCode": 200,
  "data": [
    {
      "id": "550e8400-e29b-41d4-a716-446655440000",
      "accountNumber": "8012345678",
      "accountName": "Blockradar/John Doe",
      "bankName": "Wema Bank",
      "bankCode": "035",
      "isActive": true,
      "type": "AUTO_FUNDING",
      "label": "Customer Deposits",
      "createdAt": "2026-01-22T10:30:00.000Z",
      "updatedAt": "2026-01-22T10:30:00.000Z"
    }
  ],
  "meta": {
    "itemCount": 1,
    "totalItems": 1,
    "itemsPerPage": 10,
    "totalPages": 1,
    "currentPage": 1
  }
}

{
  "message": "Virtual account retrieved successfully",
  "statusCode": 200,
  "data": {
    "id": "550e8400-e29b-41d4-a716-446655440000",
    "accountNumber": "8012345678",
    "accountName": "Blockradar/John Doe",
    "bankName": "Wema Bank",
    "bankCode": "035",
    "isActive": true,
    "type": "AUTO_FUNDING",
    "label": "Customer Deposits",
    "createdAt": "2026-01-22T10:30:00.000Z",
    "updatedAt": "2026-01-22T10:30:00.000Z"
  }
}

​

Need Help?

• Documentation: Virtual Accounts guide
• API Reference: Virtual Accounts endpoints
• Email support: [email protected]

​

Virtual Accounts API

• New feature: Virtual Accounts API enables businesses to create and manage virtual bank accounts linked to master wallets or child addresses
• Fiat-to-stablecoin conversion: Customers can receive NGN payments through traditional bank transfers, automatically converted to cNGN stablecoins
• Auto-funding support: AUTO_FUNDING type accounts automatically mint cNGN when fiat payments are received and transfer to linked wallets
• Master wallet integration: Create virtual accounts directly linked to master wallets
• Child address integration: Create virtual accounts linked to specific child addresses for granular control
• Account management: Activate or deactivate virtual accounts to control auto-funding behavior

​

What you need to do

• Enable the feature: Contact [email protected] to enable virtual accounts for your business
• Ensure cNGN support: Make sure your master wallet supports the cNGN stablecoin asset
• Mainnet only: Note that virtual accounts are only available in the MAINNET environment
• Review API endpoints: Check the Virtual Accounts API documentation for implementation details

​

API Endpoints

​

Master Wallet Endpoints

• POST /wallets//virtual-accounts – Create a virtual account for a master wallet
• GET /wallets//virtual-accounts – Retrieve virtual account details
• PATCH /wallets//virtual-accounts/ – Update virtual account status

​

Child Address Endpoints

• POST /wallets//addresses//virtual-accounts – Create a virtual account for a child address
• GET /wallets//addresses//virtual-accounts – Retrieve virtual account details
• PATCH /wallets//addresses//virtual-accounts/ – Update virtual account status

​

Key Features

• Supported currency: NGN (Nigerian Naira) for fiat payments, cNGN for stablecoin conversion
• Auto-funding flow: Automatic minting and transfer of cNGN when payments are received (AUTO_FUNDING type)
• Account activation: Control auto-funding behavior by activating or deactivating accounts
• Customer management: Create accounts with customer information (firstname, lastname, email, phone)

​

cNGN Testnet Address Updates

• Updated cNGN testnet addresses: The cNGN team has updated their testnet addresses across multiple networks
• New asset support: Added support for the updated cNGN stablecoin in the dashboard
• Asset management: Previous testnet addresses are now labeled as “old” and will be removed in 30 days
• Tron USDT support: Added updated supported Tron USDT address with previous address labeled as “old”

​

What you need to do

• Go to your dashboard and add the new cNGN assets (look for the ones without the “old” label)
• Update your integrations to use the new testnet addresses
• The old testnet addresses will be automatically removed after 30 days
• Note: These changes only apply to testnet environments - mainnet addresses remain unchanged

​

Updated Testnet Addresses

​

Updated Tron USDT Address