## Summary Allow validators to configure third-party chain data providers as alternatives to running local chain daemons. This would reduce infrastructure requirements for validators and provide redundancy/fallback options for chain data sourcing. ## Motivation Currently, Bifrost chain clients connect to a single local daemon per chain (via `RPCHost` config). This requires validators to run and maintain full nodes for every supported chain. Supporting external providers would: - Lower the barrier to entry for new validators - Provide fallback data sources if a local daemon goes down - Allow validators to choose providers based on cost, reliability, or geography ## Supported Chains & RPC Types | RPC Type | Chains | Current Client | |----------|--------|----------------| | Bitcoin JSON-RPC | BTC, LTC, BCH, DOGE | `bifrost/pkg/chainclients/utxo/` | | Zcash Custom RPC | ZEC | `bifrost/pkg/chainclients/utxo/rpc/zec/` | | Ethereum JSON-RPC | ETH | `bifrost/pkg/chainclients/ethereum/` | | EVM JSON-RPC | AVAX, BSC, BASE, POL | `bifrost/pkg/chainclients/evm/` | | Cosmos gRPC | GAIA, NOBLE | `bifrost/pkg/chainclients/gaia/` | | Solana JSON-RPC | SOL | `bifrost/pkg/chainclients/solana/` | | Tron API + JSON-RPC | TRON | `bifrost/pkg/chainclients/tron/` | | XRP Ledger JSON-RPC | XRP | `bifrost/pkg/chainclients/xrp/` | ## Candidate Providers ### Multi-Chain Providers | Provider | UTXO | EVM | Cosmos | Solana | Tron | XRP | Notes | |----------|------|-----|--------|--------|------|-----|-------| | **Ankr** | BTC | ETH, AVAX, BSC, BASE, POL | GAIA | SOL | TRON | - | Decentralized RPC, free tier | | **QuickNode** | BTC, LTC, BCH, DOGE | ETH, AVAX, BSC, BASE, POL | - | SOL | TRON | XRP | Wide chain coverage | | **GetBlock** | BTC, LTC, BCH, DOGE | ETH, AVAX, BSC, BASE, POL | - | SOL | TRON | XRP | Shared & dedicated nodes | | **NOWNodes** | BTC, LTC, BCH, DOGE, ZEC | ETH, AVAX, BSC, POL | - | SOL | TRON | XRP | Full node API access | | **Chainstack** | BTC | ETH, AVAX, BSC, BASE, POL | GAIA | SOL | TRON | - | Elastic nodes | | **Blast API (Bware Labs)** | BTC | ETH, AVAX, BSC, BASE, POL | - | SOL | - | - | Decentralized infra | | **dRPC** | BTC | ETH, AVAX, BSC, BASE, POL | - | SOL | TRON | - | Decentralized RPC | ### EVM-Focused Providers | Provider | Chains | Notes | |----------|--------|-------| | **Infura** | ETH, AVAX, BASE, POL | Industry standard, ConsenSys | | **Alchemy** | ETH, AVAX, BASE, POL, SOL | Enhanced APIs, webhooks | | **Moralis** | ETH, AVAX, BSC, BASE, POL | Web3 data APIs | | **LlamaNodes** | ETH, AVAX, BSC, BASE, POL | Privacy-focused | ### UTXO-Focused Providers | Provider | Chains | Notes | |----------|--------|-------| | **Blockchair** | BTC, LTC, BCH, DOGE, ZEC | REST API, explorer data | | **BlockCypher** | BTC, LTC, DOGE | REST API, webhooks | | **Mempool.space** | BTC | Open source, self-hostable | | **Blockstream Esplora** | BTC, LTC | Open source, REST API | ### Chain-Specific Providers | Provider | Chain | Notes | |----------|-------|-------| | **Helius** | SOL | Solana-specialized, enhanced APIs | | **Triton (RPC Pool)** | SOL | Solana-focused, load balanced | | **TronGrid** | TRON | Official Tron Foundation provider | | **Polkachu** | GAIA, NOBLE | Cosmos validator with public endpoints | | **All That Node** | GAIA | Cosmos ecosystem | | **XRPL Foundation** | XRP | Official public nodes | ### Decentralized/Protocol-Level Providers | Provider | Chains | Notes | |----------|--------|-------| | **Pocket Network (POKT)** | BTC, ETH, AVAX, BSC, SOL, GAIA | Decentralized RPC protocol | | **Lava Network** | ETH, AVAX, SOL, GAIA | Decentralized RPC with quality scoring | ## Implementation Considerations ### EVM Chains (easiest) EVM providers all speak standard Ethereum JSON-RPC — validators can simply point `RPCHost` to a provider URL (e.g. `https://eth-mainnet.g.alchemy.com/v2/<key>`). This largely works today with no code changes. ### UTXO Chains (adapter needed) Most UTXO providers (Blockchair, BlockCypher) expose REST APIs with different schemas than Bitcoin JSON-RPC. An adapter/translation layer would be needed to map provider-specific REST responses to the interface expected by the UTXO chain client. ### Cosmos Chains Providers must support gRPC (not just REST) to be compatible with the current Cosmos chain client. ### Solana / Tron / XRP These use chain-specific JSON-RPC protocols. Providers that expose the native RPC interface (most do) can be used directly via `RPCHost`. ### General Architecture - Introduce a `Provider` abstraction/interface per chain type - Allow configuration of provider type + credentials per chain in `config.yaml` - Support fallback chains: local daemon → provider A → provider B - Consider health checking and automatic failover between providers - Rate limiting awareness (most providers have rate limits on free/lower tiers) ## Tasks - [ ] Design provider abstraction interface per chain type (UTXO, EVM, Cosmos, Solana, Tron, XRP) - [ ] Implement EVM provider support (lowest effort — just config change validation) - [ ] Implement UTXO provider adapters (Blockchair, BlockCypher REST → Bitcoin RPC translation) - [ ] Implement Cosmos provider support (gRPC endpoint swapping) - [ ] Implement Solana/Tron/XRP provider support - [ ] Add provider health checking and failover logic - [ ] Add configuration schema for provider selection and credentials - [ ] Documentation for validators on provider setup