NetworkValidated independently
Multi-chain asset coverage
Bring every approved asset into one controlled operating model.
bitgo is designed to coordinate wallet, transfer, signing, policy and reporting workflows across native coins, tokens, stablecoins and tokenized instruments. Each network and service is enabled separately after integration, security testing, recovery validation and jurisdictional review.
Asset and service availability is specific to each deployment.
ContractVerified before enablement
ServiceActivated capability by capability
Asset-aware by design
Built around the way each network actually works.
Digital assets do not share one universal transaction, signing or custody model. bitgo evaluates the technical and operating boundary independently for every proposed integration.
Network-specific construction
Address formats, transaction models, fees, required metadata and finality behavior are mapped for the selected network.
The workflow is designed for the protocol rather than forced into a generic wallet pattern.Contract-level verification
Token deployments are identified by network, issuer and verified contract address before they can be evaluated for enablement.
A familiar ticker alone is never treated as a complete asset identifier.Capability separation
Custody, deposits, withdrawals, trading, staking and settlement are assessed as distinct capabilities.
Compatibility with one operation does not imply availability of every service.Deployment approval gates
Security testing, recovery validation, provider review and jurisdictional assessment precede production enablement.
The signed implementation scope remains the authoritative service schedule.Candidate integration catalogue
25 candidate integrationsExplore the asset universe bitgo is designed to evaluate.
These networks, standards and instruments are candidate integrations drawn from the platform blueprint. They are not a representation of currently active support.
Filter candidate integrations by group
Showing 25 candidate integrations in Native assets.
01
25 candidate integrationsNative assets
Coins native to their respective blockchain environments, evaluated with their own address, fee, signing and recovery requirements.
- BitcoinBTC
- EthereumETH
- Bitcoin CashBCH
- LitecoinLTC
- DogecoinDOGE
- XRPXRP
- StellarXLM
- SolanaSOL
- CardanoADA
- PolkadotDOT
- AvalancheAVAX
- BNBBNB
- TRONTRX
- AlgorandALGO
- CosmosATOM
- NEAR ProtocolNEAR
- AptosAPT
- SuiSUI
- HederaHBAR
- ZcashZEC
- DashDASH
- Bitcoin GoldBTG
- TezosXTZ
- EOSEOS
- IOTAIOTA
Candidate integration only; wallet and service availability must be approved per network.
Catalogue entries describe an intended evaluation scope. Current availability exists only when enabled and documented for a specific deployment.
Network operating models
The control pattern follows the transaction model.
Signing, fee handling and recovery must be selected for the exact blockchain and wallet architecture. No single cryptographic pattern is presented as universal.
Bitcoin and UTXO networks
Candidate UTXO integrations can use input-level construction, dynamic fee estimation and network-native signing patterns where supported.
- UTXO selection and controlled consolidation
- Multiple receiving-address workflows
- Dust-output screening
- PSBT and native multisignature where implemented
Ethereum, EVM and Layer 2
Native assets and approved token contracts can be evaluated for threshold-signing or smart-contract wallet designs.
- Chain and contract identification
- Native asset and token transaction handling
- Destination, value and expiry validation
- Dedicated gas or fee-wallet workflows
Alternative native networks
Account-based and network-specific Layer 1 integrations are designed around their own signing, metadata, fee and finality requirements.
- Network-native address validation
- Protocol-specific transaction construction
- Required memo and metadata handling where applicable
- Recovery and broadcast testing
Issued and tokenized assets
Tokens add issuer, contract and legal dependencies beyond the underlying blockchain integration.
- Verified network and contract identity
- Issuer and administrator review
- Transfer-rule and decimal validation
- Redemption, bridge and custody-risk assessment
Asset-class controls
The same ticker can conceal a different technical and legal instrument.
bitgo is designed to identify what an asset is, where it is issued and which dependencies must be evaluated before a capability can be enabled.
Stablecoins
Candidate stablecoins are evaluated by issuer, reference asset, network, verified contract and transfer behavior. USDC on Ethereum, Solana, Polygon or Base represents a different technical deployment on each network.
Reserve, redemption, depegging, freezing, issuer and bridged-asset risks remain outside a ticker symbol.Wrapped and tokenized value
Candidate instruments can include WBTC, PAXG, XAUT and eligible tokenized real-world assets, financial instruments or NFTs on individually approved networks and standards.
The represented rights, issuer, custodian, oracle, bridge, redemption process and legal classification require separate assessment.Additional token candidates
Governance, utility, ecosystem and community tokens may be evaluated in response to client requirements and the internal integration process.
Inclusion in the catalogue is not an offer, recommendation, liquidity statement or confirmation of support.Service capability map
Compatibility is not a single yes-or-no flag.
An asset may be available for one operation without being eligible for trading, staking, settlement or every wallet model. Each capability is evaluated separately.
| Capability | Deployment-specific meaning |
|---|---|
| Custody | The asset can be safeguarded under an expressly documented custody model. |
| Deposit | An approved address can receive the asset under the selected workflow. |
| Withdrawal | The asset can be transferred to an approved external destination. |
| Trading | Buying, selling or conversion can be made available through an eligible provider. |
| Staking | The asset can participate in a separately approved staking workflow. |
| Settlement | The asset can be used in an agreed settlement process. |
| Hot wallet | The asset is enabled for frequent operational transfers in a connected environment. |
| Cold wallet | The asset is enabled in an offline signing or storage design. |
| MPC / TSS | The selected network can use the approved threshold-signing implementation. |
| Multisignature | The network or wallet contract can use the approved multisignature design. |
Security alignment
The protection model follows the asset and responsibility boundary.
Controls are selected for the target network, wallet design, participant roles and recovery objectives. No architecture removes every digital-asset or operational risk.
Native multisignature
A documented quorum such as 2-of-3 may distribute control on networks that support the selected multisignature model.
MPC and TSS
Threshold signing may distribute signing authority across independent key shares while producing a network-valid signature.
Hot and cold boundaries
Operational liquidity and long-term holdings can use separate environments, approval rules and recovery procedures.
Protected key operations
Eligible implementations may use hardware security modules for controlled cryptographic generation, storage and signing.
Policy evaluation
Destinations, values, users, time windows, approval thresholds and external risk signals can be evaluated before execution.
Access and audit
Role separation and event records can cover authentication, wallet changes, policy updates, approvals, API access and recovery.
Network-aware staking, without guaranteed yield.
Where separately enabled, bitgo can be designed to coordinate staking operations for individually evaluated Proof-of-Stake assets.
Candidate assets for individual evaluation
ETHSOLADADOTATOMAVAXNEARSUI
Potential workflow coverage
- Asset delegation
- Validator selection
- Estimated reward-rate display
- Reward accounting and history
- Activation and unbonding status where applicable
- Reward claiming workflows
- Wallet-level reporting
Integration lifecycle
From candidate asset to controlled deployment.
Every proposed integration passes through a network-specific process before any service capability can be described as available.
- 01
Identify
Confirm the exact network, native asset, token standard and verified contract where applicable.
- 02
Construct
Implement address, metadata, fee and transaction-building requirements for the selected protocol.
- 03
Sign and broadcast
Validate the selected signing model, authorization path, broadcast behavior and confirmation monitoring.
- 04
Recover
Test backup, signer-loss, replacement and disaster-recovery procedures.
- 05
Assess dependencies
Review issuers, contracts, bridges, validators, liquidity and external providers relevant to the asset.
- 06
Review security
Complete threat analysis, control testing and operational readiness checks.
- 07
Review jurisdiction
Confirm legal entity, client eligibility, regulatory conditions and contractual responsibilities.
- 08
Enable capabilities
Activate only the approved custody, transfer, trading, staking or settlement functions.
- 09
Monitor
Track protocol upgrades, forks, contract changes, operational incidents and service availability.
Define your asset scope
Turn a candidate asset list into an accountable integration plan.
Discuss the networks, wallet models, service capabilities and jurisdictions relevant to your organization.