Supported Assets and Non-Custodial Scope
Manatee currently supports on-chain Bitcoin (BTC). Bitcoin Cash (BCH) is planned as the next asset, and we continue to evaluate other cryptocurrencies against the same requirement: customer funds must go directly to a wallet controlled by the merchant, not through a Manatee wallet or balance.
Supporting more assets does not by itself make a payment service custodial. The important question is who controls the private keys and who can move the funds. We will only add an asset when we can support it without taking that control from the merchant and without weakening the reliability of the checkout flow. For the underlying custody model, see Custodial vs. Non-Custodial Bitcoin Payments.
Why we started with Bitcoin
The public beta deliberately has a narrow scope. Supporting one asset first lets us make the complete payment lifecycle reliable before increasing the number of networks and edge cases.
For Bitcoin, Manatee can provide the required checkout infrastructure while remaining non-custodial:
- A customer pays an address controlled by the merchant.
- Manatee can derive fresh receive addresses from read-only wallet information or monitor a destination address supplied by the merchant.
- Our nodes independently observe transactions and confirmations.
- Manatee never needs a seed phrase or private key.
- Manatee cannot spend, freeze, reverse, or refund a payment.
This lets us focus the beta on address monitoring, payment reconciliation, confirmation tracking, signed webhooks, and reliable retries instead of presenting broad but shallow asset support.
Bitcoin Cash is planned next
Bitcoin Cash has a transaction model that is sufficiently close to the current on-chain monitoring approach to be a strong candidate for the next supported asset. A BCH integration can still send payments directly to merchant-controlled addresses and does not require Manatee to hold customer funds.
BCH support is not available in the public API yet, and there is no published release date. Before enabling it, we need to complete and verify BCH-specific work including CashAddr handling, read-only address derivation, node integration, transaction detection, confirmations, fiat conversion, webhook data, test coverage, and operational monitoring.
When BCH becomes available, it will use an explicit asset scope. BTC and BCH API keys, addresses, payments, and webhook events will remain clearly separated.
How we evaluate additional cryptocurrencies
We do not choose assets based only on market size or popularity. Each candidate is reviewed across the full payment lifecycle.
| Requirement | What we evaluate |
|---|---|
| Direct settlement | Can the customer pay a merchant-controlled address without funds passing through Manatee? |
| Read-only integration | Can we create or monitor unique payment destinations without private keys or signing authority? |
| Independent verification | Can we operate reliable node infrastructure and verify transactions without depending on a custodial intermediary? |
| Payment finality | Can detection, confirmation, replacement, reorganisation, and double-spend risks be represented accurately? |
| Amount matching | Can an incoming transfer be matched unambiguously to a checkout, including memo, tag, token, or contract-specific rules? |
| Operational safety | Can we monitor the network, recover from missed events, and deploy updates without risking merchant funds? |
| Checkout usability | Can wallets present addresses, payment URIs, fees, expiry, and network information without creating avoidable payment mistakes? |
| Compliance and scope | Can the service remain payment-monitoring infrastructure rather than operating customer balances, exchanges, or managed wallets? |
An account-based network, token, or smart-contract platform is not automatically custodial. It can, however, introduce different requirements from a UTXO-based asset. Examples include destination tags, contract event interpretation, gas requirements, token contracts, chain reorganisations, or the need to sign operational transactions. We need to determine whether those requirements can be handled while the merchant remains in control and Manatee remains a monitoring and notification service.
What Manatee will not do to add an asset
Broader asset support will not change the current custody boundary. Manatee will not require or store merchant seed phrases or private keys, receive customer payments into pooled Manatee wallets, maintain withdrawable customer balances, or exchange one asset for another as part of the payment flow.
If an asset cannot be integrated reliably without Manatee controlling funds or signing transactions on behalf of merchants, it will not be added under the current product model. We may also defer an otherwise non-custodial integration when its node infrastructure, wallet interoperability, finality model, or operational risk is not mature enough for a dependable checkout service.
Current roadmap status
| Asset | Status |
|---|---|
| Bitcoin (BTC) | Available for on-chain testnet and mainnet payments |
| Bitcoin Cash (BCH) | Planned and under technical preparation; not yet available in the public API |
| Other cryptocurrencies | Evaluated individually; no support or release commitment until announced in the documentation |
For the current integration boundary, see Accept Bitcoin Payments. For short answers about wallets, custody, and the beta, see the FAQ.