Wallet infrastructure
We currently use Rift for the BlockFinaX wallet, but our integration does not support Stellar account creation or signing. We can keep the wallet screens and product workflows; we need a new wallet layer to run them on Stellar.
Our preferred approach is to build and operate the Stellar wallet infrastructure ourselves, using established Stellar SDKs and smart-account libraries. We will also consider Rift adding Stellar support or another Stellar wallet provider. This section describes the work we are proposing for the SCF-funded release.
Three implementation paths
| Path | What we would do | Main tradeoff | Proposal status |
|---|---|---|---|
| Extend Rift | Work with Rift to add Stellar accounts, signing and network operations to its infrastructure | Preserves the provider relationship, but depends on Rift's engineering and commercial roadmap | Alternative, subject to Rift agreement |
| Build BlockFinaX infrastructure | Operate our own account, passkey, authorization, relayer and wallet integration layer using Stellar building blocks | More engineering and operational responsibility, with control over UX, recovery and treasury policies | Preferred approach |
| Integrate another provider | Evaluate Blux, Privy or Dfns behind the same wallet adapter | Can reduce integration work, with provider-specific custody, pricing and dependency considerations | Fallback or complementary option |
All paths retain the BlockFinaX brand, wallet screens, and event-based hedger, LP and underwriter experience. Choosing a signing backend does not change the event payoff or migrate existing EVM positions automatically.
Option one: work with Rift
We would ask Rift to support the Stellar operations our platform needs: account creation, signing, assets and trustlines, fee sponsorship, and transaction tracking. Its API would also need to handle transaction XDR, network passphrases and Soroban authorization for the chosen account model.
We will test Rift through the BlockFinaX UI. An institutional tester will create or link an account, receive the configured test asset, send a payment, buy an event-based hedge, and claim its payout after oracle-based settlement. For each transaction, we need a record of the institution, the approving signer and the Stellar operation. Email or Google sign-in is only the first step in that workflow.
If Rift takes this work on, we will need an agreed scope and delivery date, clear terms for account ownership and recovery, and documentation our institutional customers can review. We have no Stellar agreement with Rift yet. Building our own wallet layer remains the delivery plan unless a tested provider meets these requirements.
Option two: build our own wallet infrastructure
We will build the account, authorization, recovery and transaction services that connect the BlockFinaX application to Stellar. We will use established Stellar libraries and keep transaction approval with the customer.
Account and identity layer
Keep the familiar application sign-in and link it to a verified Stellar account. Separate the application session from authority to move funds. The preferred embedded account design uses a user-controlled passkey with a Soroban smart account, after validating the chosen library and network versions. A classic G-account connector can support early integration tests and users with an existing Stellar wallet.
Account linking stores network, typed address, credential reference, and verification status. An existing Rift EVM address or login token does not authorize a new Stellar account. Users consent to the account linkage and any balance transfer; their EVM private keys are not copied into the Stellar implementation.
Signing and account policy
Build a wallet adapter for the actual Stellar authorization flow, using the official JavaScript SDK and a pinned compatible smart-account library. OpenZeppelin's Stellar smart-account framework is a candidate basis for signer and policy composition. The precise passkey adapter, signature format, origin checks, and contract authorization must be verified in the implementation. OpenZeppelin smart accounts
The wallet displays recipient, asset, amount, contract action, network and expiry before requesting approval. Customer-controlled signing is distinct from BlockFinaX's fee-sponsor and service keys. An application administrator must not gain unrestricted transaction authority merely by managing the user's login record.
Services we will operate
| Component | Planned responsibility |
|---|---|
| Account provisioning | Create or link supported Stellar accounts and record verified ownership |
| Passkey integration | Registration and transaction authorization through the selected account model |
| Recovery workflow | Additional user-approved credentials and tested lost-device recovery with explicit policy |
| Transaction preparation | Build XDR, simulate Soroban calls, verify authorization and show fees |
| Relayer and sponsorship | Submit approved transactions with bounded fee budgets and abuse controls |
| Wallet data | Asset identity, balances, history, operation status and ledger reconciliation |
| Developer adapter | Expose the same wallet capabilities to the platform SDK and partner integrations |
Recovery policy is part of the funded build and must be specified before production. An email reset must not silently transfer control of a customer's wallet. Recovery, credential rotation, device loss, revoked credentials and administrator misuse need dedicated tests.
Why this is the preferred approach
Our primary customers are financial institutions and insurance desks. They need to know who controls an account, who can approve transactions, how recovery works, and who is responsible when something goes wrong. Relying on another wallet operator adds a dependency that their compliance teams and our regulators must assess, including whether its regulatory status covers the services we would use.
As we pursue the Securities and Exchange Commission Ghana and Bank of Ghana sandbox processes, we want to present the wallet, platform, partner API and treasury services together under BlockFinaX's governance. Operating our own wallet layer would give us direct responsibility for those controls and a clearer basis for regulatory review. We will document external dependencies as part of that submission. Each authority will determine the scope of its approval; any permissions required for production remain separate from sandbox testing. SEC sandbox guidelines · Bank of Ghana regulatory sandbox
For an institution using BlockFinaX, this means named signer and recovery roles, approval policies for payments and hedge purchases, and transaction records it can reconcile with its treasury books. Fee-sponsor permissions will be separate from customer signing authority. An institution should be able to trace a treasury movement from its approval to its settlement on Stellar. We will build these controls as part of the Stellar release.
We also want to keep the current wallet experience and use the same authorization services across the platform and partner SDK. Our wallet adapter will keep provider-specific details separate from payments and hedging, so we can change providers later without rebuilding those workflows.
Running these services makes BlockFinaX responsible for maintenance, recovery, monitoring and security review. The grant covers the wallet and SDK engineering needed for this release. Independent audit invoices and legal fees remain separately financed.
Option three: use a Stellar wallet provider
We have shortlisted Blux, Privy and Dfns for evaluation. We checked their documentation on 9 October 2026; we have no partnership agreement with them. Before choosing one, we will test signing and recovery and review account ownership, costs and production terms.
| Candidate | Relevant documented capability | What BlockFinaX must validate |
|---|---|---|
| Blux | Stellar-focused infrastructure with email, social and passkey login, branded UI, and transaction hooks | Provisioned-account custody and recovery, contract authorization support, tenant controls and provider dependence |
| Privy | Embedded wallet creation includes Stellar as an extended chain | Stellar signature and XDR handling, Soroban authorization, user versus server authority, recovery and fees |
| Dfns | Wallet infrastructure with a documented Stellar transaction-broadcast API | End-user onboarding, key-control policies, exact Soroban signing support, deployment model and commercial access |
Blux offers onboarding options similar to our current wallet. Its documentation distinguishes provisioned custodial accounts from external wallets; we would need to choose the account model that fits our customers. Sources: Blux introduction and wallet verification.
Privy lists Stellar among its supported extended chain types. We still need to test the Soroban authorization used by our hedge contracts. Source: Privy wallet creation.
Dfns documents Stellar broadcast integration. We will test the exact contract transaction and account policy needed for hedge purchases and claims before selecting it. Source: Dfns Stellar broadcast.
We will also consider Freighter and Stellar Wallets Kit for customers who bring an existing wallet. These connectors handle external-wallet access; BlockFinaX would still need its own provisioning and recovery services for embedded accounts. Stellar wallet integration catalog
Delivery and selection gates
The first build phase verifies account creation or linking, signing, and a Soroban action on testnet. The second adds embedded onboarding, recovery, sponsorship and partner SDK tests. Production enablement requires documented key control, tested recovery, security review, supported account/provider combinations, and operational ownership.
Each candidate is evaluated against the same tests: network isolation, USDC transfer, hedge purchase, LP deposit, payout claim, user refusal, expired authorization, key rotation, and duplicate submission. A working ordinary Stellar payment is not sufficient evidence of full protocol integration.
The SCF request funds the wallet, protocol and API work needed to bring the existing BlockFinaX platform to Stellar. We plan to operate the wallet layer ourselves and will assess the provider alternatives against the same institutional requirements.