RP1 supports multiple kinds of interoperability. Choose the one whose trust and recovery model matches the asset movement you are building.
Connector choices
| Boundary | RP1 surface | Trust and recovery model |
|---|---|---|
| Cosmos ecosystem | IBC / ICS-20 | Relayed packet proofs and channel configuration. |
| EVM source chains | InstaWrap contracts and light-client/proof path | Origin-chain vault events, relayer proofs, and threshold-controlled withdrawals. |
| Solana | InstaWrap Anchor vault and account/event proofs | Program events, account proofs, relayer processing, and threshold controls. |
| Bitcoin | Native vault address, transaction/OP_RETURN conventions, SPV proof | Confirmations, block/merkle proof validation, and relayer submission. |
| Solidity-to-RP1 workflows | Velocity precompile and native modules | Native RP1 execution with explicitly bounded adapters; not external runtime emulation. |
Deposit and withdrawal lifecycle
The public mental model is:
origin action
→ observation and confirmations
→ proof or packet construction
→ RP1 verification
→ wrapped/native accounting
→ optional withdrawal request
→ threshold or relayer settlementInstant credit, where enabled, is an early credit state and not a replacement for final source-chain settlement. An application must display pending, confirmed, completed, and failed states separately.
Safety boundaries
- Verify the destination chain ID, source transaction, recipient, denom, and amount.
- Treat vault addresses as generated network state; do not hard-code an address from a different environment.
- Do not promise a withdrawal before the relevant threshold and relayer lifecycle completes.
- Keep bridge contracts and relayer credentials outside the application browser boundary.
- Do not describe Bitcoin or Solana support as a general-purpose VM running inside RP1.
Read InstaWrap, light clients, cross-chain integration, and the public disclosure policy.