Migration to Stellar
The port migrates platform capabilities and the API adapter before offering users a balance-transfer route. Existing Base and BSC events keep their original contracts, settlement rules, and claim paths. A USDC transfer does not migrate an open hedge or an LP obligation.
Implementation mapping
| Existing component | Stellar adaptation |
|---|---|
| Solidity Diamond and facets | Rust Soroban contracts with explicit roles and upgrade policy |
| Event range payoff | Same initial-rate, strike and limit semantics with parity tests |
| ERC20 asset and approval | Verified issued USDC asset and SAC authorization flow |
| Numeric EVM chain ID | Explicit Stellar network and passphrase |
| Calldata and raw hex transaction | Simulated XDR and account auth entries |
| Rift-backed EVM wallet infrastructure | Preferred BlockFinaX-operated Stellar wallet layer; Rift extension or another provider as alternatives |
| EVM wallet address | User-verified typed G or C account |
| EIP-712 engine attestation | Optional separately versioned Stellar-bound attestation |
| Chain indexer | Stellar ledger events and reconciliation |
User migration
Our current Rift integration cannot sign Stellar transactions. We will build onboarding, authorization, recovery and relaying into our own Stellar wallet layer, using established libraries. Blux, Privy and Dfns are alternatives we will evaluate. Read the wallet infrastructure plan.
Users will verify and link their Stellar account, fund it through a supported route, and choose new Stellar events. Their existing keys and positions stay on the original chain. The interface shows original-chain positions until their lifecycle completes.
Supported USDC transfers
Circle CCTP is a candidate for supported native USDC routes. Stellar-bound transfers use Circle's forwarder flow and retain the full typed recipient in the hook data. Messages use six decimal places while Stellar USDC uses seven; conversion and retained dust are explicit. Track burn, attestation and confirmed destination mint independently. Destination mint-and-forward atomicity does not make the entire cross-chain transfer atomic.
Base, BSC, and USDT routes are evaluated separately against current provider support; unsupported routes remain disabled. Every transfer requires recipient review, fees and minimum-received terms. Reference: Circle CCTP on Stellar.
Testnet and production
Separate manifests, assets, signer roles, credentials and data stores. Reproducible testnet fixtures are labelled nonredeemable. Production release requires payoff and accounting parity tests, oracle evidence, restoration/TTL operations, monitoring, independent review, and permission to offer the selected product and corridor. Mainnet contract IDs are published only after deployment verification.