Loading...
Supporting developers, startups, and full-fledged companies building on Stellar and Soroban
© 2026 Stellar Development Foundation
Subscribe to the Newsletter
By Sorted
Stablecoins can provide practical access to digital dollars, but the current user experience is designed for crypto-native users with modern smartphones, reliable connectivity, bank accounts, and knowledge of wallets, gas, networks, bridges, and off-ramps.
That is not how many people in Africa and South Asia access financial services.
Sorted’s users often rely on Android Go phones, older smartphones, basic phones, intermittent connectivity, cash, airtime, and fragmented local payment rails. A user who wants to move $20 from an existing stablecoin balance into Stellar USDC and then collect local cash currently has to:
Understand which network the stablecoin is on.
Maintain sufficient gas on the source chain.
Find and operate a compatible bridge.
Create and fund a separate Stellar wallet.
Configure the correct asset and trustline.
Authenticate with an off-ramp.
Track transaction status across several services.
Avoid mistakes with addresses, memos, fees, expiry times, and unsupported corridors.
Each additional step increases abandonment and the risk of irreversible loss.
Sorted replaces that stack with one mobile experience:
The user signs in through the existing Sorted authentication flow.
An individual Stellar account is created and prepared for USDC.
The user can send and receive Stellar USDC without manually configuring Stellar, buying XLM, or managing a separate wallet.
Polygon USDC can be routed into Stellar USDC through Bridge without the user operating an external bridge.
Eligible users can withdraw Stellar USDC through MoneyGram Ramps.
The app displays the amount, exchange rate, fees, limits, expiry, status, cash-pickup instructions, and reference number.
Interrupted transactions can be safely resumed on weak networks.
Every completed blockchain leg remains independently verifiable on Stellar.
The result is a simple flow from digital dollars to local cash, built for the devices and connectivity conditions people actually have.
1. Dfns: individual Stellar wallets and user-authorized signing
Dfns will provide the Stellar wallet infrastructure required to create and map individual wallets, activate accounts, establish USDC trustlines, authorize transactions, sign and broadcast Stellar transactions, and monitor transaction events.
The implementation will preserve Sorted’s non-custodial product requirement: every user has an individual Stellar account, transaction authorization requires user action, and backend permissions are restricted so that Sorted cannot unilaterally move user funds.
Dfns supports Stellar account operations and delegated wallets where end users retain signing authority.
2. Bridge: stablecoin routing into Stellar USDC
Bridge will be integrated as a provider inside Sorted’s existing multi-chain abstraction layer.
The primary acceptance route will be Polygon USDC to Stellar USDC. The integration will handle:
Route and quote retrieval
Source and destination amounts
Fees, minimums, maximums, and expiry
Deposit instructions
Stellar destination addresses and memos
Pending, processing, completed, failed, expired, cancelled, and delayed states
Webhooks, retries, idempotency, and reconciliation
Users will see one quote and one transaction flow rather than a separate bridging interface.
3. MoneyGram Ramps: Stellar USDC to local cash
MoneyGram will be implemented as a pluggable provider within Sorted’s existing off-ramp layer.
The integration will use:
SEP-10 for authentication
SEP-24 for the hosted withdrawal and compliance flow
Individual non-custodial Stellar accounts
Stellar USDC settlement
Transaction polling and status reconciliation
Cash-pickup reference numbers and instructions
MoneyGram’s official flow authenticates the user through SEP-10, initiates the withdrawal through SEP-24, processes the USDC transfer, and returns the reference number required for cash pickup.
4. Sorted: the low-spec user experience and distribution layer
Sorted will unify these integrations through:
Android and Android Go applications
Shared APIs and transaction states for simple-device clients
Weak-network recovery and resumable transactions
Clear fees, expiry, eligibility, and risk messaging
Transaction monitoring and support tooling
Existing distribution through low-end smartphone and basic-phone channels
Stellar balances and transfers remain on-chain. Sorted’s database stores mappings, partner references, and operational transaction state, not an off-chain representation of user funds.
Why this matters for Stellar
This project is not another greenfield wallet competing for existing crypto users.
Sorted brings Stellar into an operating wallet with:
500,000+ existing downloads
Established emerging-market distribution
Existing multi-chain and local-payment infrastructure
Low-spec device expertise
A planned OEM preinstallation channel reaching millions of devices
Stellar becomes the settlement and cash-access rail inside an existing product rather than an optional network hidden in an advanced settings menu.
$150.0K
Sorted has already reached 500,000+ downloads, primarily through low-end smartphone and basic-phone channels, including emerging-market app ecosystems. We have also proven that users in these markets want simple access to digital dollars, airtime, and local payment rails, especially when the product removes crypto complexity.
On the strategic side, Sorted is backed by investors including Tether and Gnosis, and we are building around device-level and ecosystem partnerships rather than competing only in crowded app-store channels.
We are now partnering up with one of the world’s largest feature phone and smartphone manufacturers, to deliver a wallet solution to tens of millions of devices across Africa. Starting this year, our wallet will be preinstalled on millions of devices shipped to target markets (Africa, South Asia, Middle East).
Sorted already operates:
A production non-custodial wallet
Multi-chain transaction infrastructure
Stablecoin send-and-receive flows
Airtime and local-payment integrations
A provider abstraction for on- and off-ramps
Monitoring and support processes for emerging-market users
The project extends a production system. It does not fund development of the underlying wallet from zero.
A reviewer can install a Sorted test build, sign in through the existing Sorted flow, receive an individual Stellar testnet account, and send and receive USDC without buying XLM, configuring a trustline, selecting a network, or using a separate wallet.
Allocation: $30,000
SOW estimate: 200-230 hours
Brief description:
Produce and implement the technical design covering wallet ownership, user authorization, signing policies, backend permissions, account lifecycle, account activation, USDC trustlines, secure credential handling, transaction failure modes, and the relationship between Dfns and Sorted’s non-custodial architecture.
Create separate Dfns sandbox and staging environments with restricted service credentials and secure secret management.
How to measure completion:
Architecture document and sequence diagrams supplied to reviewers.
Threat model covers unauthorized signing, credential exposure, replay attempts, duplicate requests, and account-recovery scenarios.
Dfns sandbox and staging projects are operational.
No Dfns secrets or unrestricted signing credentials are present in the mobile application bundle.
CI security and secret-scanning checks pass.
Reviewer-accessible API documentation is provided.
Budget: $4,000
Brief description:
Create an individual Stellar account for each participating Sorted user, map the Dfns wallet to the Sorted user, activate the Stellar account, establish the USDC trustline, manage minimum-reserve requirements, and store the required non-sensitive wallet metadata.
How to measure completion:
Reviewer creates three new accounts through the normal Sorted onboarding flow.
All three accounts are visible on Stellar testnet.
Each account is activated and has the correct USDC trustline.
The reviewer does not need to purchase or manually transfer XLM.
Account-to-user mappings reconcile across Dfns, Sorted, and Stellar.
Wallet access and mapping persist after logout and reinstall.
Budget: $5,000
Brief description:
Implement user-authorized signing, transaction construction, signing and broadcasting, balance checks, send and receive flows, transaction expiry, and clear handling of failed transactions.
How to measure completion:
Reviewer completes at least five testnet USDC transfers.
Each successful transfer has a verifiable Stellar transaction hash.
An unauthorized backend-only signing attempt is rejected.
Insufficient-balance and invalid-destination cases display clear errors and create no transaction.
The balance displayed in Sorted reconciles with the Stellar account.
Budget: $7,000
Brief description:
Implement the internal Dfns abstraction, transaction logging, webhook processing, status reconciliation, retries, support logs, and idempotency protection.
How to measure completion:
Reviewer-accessible OpenAPI specification and Postman collection are supplied.
Automated unit, integration, and end-to-end tests pass.
Replaying an identical request or webhook does not create a duplicate transaction.
Dfns events reconcile with Stellar transaction status.
Failed transactions are visible in the support dashboard with a usable failure reason.
Budget: $6,000
Brief description:
Add Stellar account, balance, send, receive, confirmation, progress, success, and failure states to Sorted’s Android and Android Go applications. Expose the same backend transaction-state model to KaiOS/simple-device clients and maintain an iOS-ready API contract.
How to measure completion:
Installable Android and Android Go reviewer builds are supplied.
Reviewer completes onboarding and a send-and-receive round trip on a low-spec Android profile.
The primary user flow does not expose network IDs, trustlines, XDR, gas configuration, or Dfns terminology.
Shared transaction-state documentation is provided for other Sorted clients.
Budget: $4,000
Brief description:
Test the integration on older Android devices, Android Go, small screens, low memory, low storage, slow connections, interrupted sessions, and retry/resume scenarios. Confirm that existing Sorted wallet functionality remains operational.
How to measure completion:
At least 40 documented automated or manual cases are completed.
Existing Sorted send, receive, market, and authentication flows pass regression testing.
Interrupted transaction status resumes correctly after app restart and network loss.
No unresolved severity-0 or severity-1 defect remains.
Staging deployment and read-only monitoring dashboard remain operational for seven consecutive days.
Budget: $4,000
A Sorted user can request a quote, confirm a Polygon USDC to Stellar USDC route, follow one transaction flow, and receive Stellar USDC in their individual Sorted account.
Allocation: $40,000
SOW estimate: 220-240 hours
Brief description:
Define the Polygon USDC to Stellar USDC acceptance route, including supported asset identifiers, address requirements, minimums, maximums, quote expiry, destination assumptions, return handling, and unsupported conditions.
Produce high-fidelity designs for quote, confirmation, progress, success, failure, expiry, and delayed-transfer states.
How to measure completion:
Route specification identifies one fixed primary route rather than a list of “and/or” providers.
Figma designs cover every transaction state.
API-to-UI mapping is documented.
Unsupported assets, networks, and amounts are rejected before funds can be sent.
Reviewer approval of the route specification is recorded before implementation sign-off.
Budget: $5,000
Brief description:
Fetch and display the source amount, destination amount, route, partner fee, other applicable fees, minimum and maximum amount, quote expiry, and destination asset.
How to measure completion:
Reviewer can request quotes for at least ten supported test cases.
The amount, fee, destination amount, and expiry displayed in Sorted match the Bridge response.
Expired quotes cannot be submitted.
Below-minimum and above-maximum amounts are rejected with clear guidance.
Quote refresh does not create a transfer.
Budget: $6,000
Brief description:
Implement transfer creation, deposit instructions, confirmation, source-asset transfer, and destination-state handling. Track pending, processing, completed, failed, expired, cancelled, and delayed transactions.
How to measure completion:
Reviewer completes at least ten Bridge sandbox transactions.
Successful live blockchain legs include verifiable transaction hashes.
Failed, expired, cancelled, and delayed states are demonstrated using controlled test cases.
Reopening the app restores the correct transaction state.
Repeated confirmation taps do not create duplicate transfers.
Budget: $8,000
Brief description:
Process Bridge callbacks, match them to internal transfer records, handle Stellar destination addresses and memos, reconcile partner status with on-chain settlement, and create support/debug logs.
How to measure completion:
Every completed test transaction matches a Bridge transfer ID and its corresponding Stellar destination record.
Webhook replay produces no duplicate credit or transfer.
Missing, delayed, and out-of-order webhooks are reconciled through polling.
Stellar destination failures are surfaced before funds are sent where technically possible.
A reconciliation report is supplied for the complete test set.
Budget: $7,000
Brief description:
Implement the Bridge quote, confirmation, progress, receipt, success, and failure experience across Sorted’s mobile applications. Add clear warnings for fees, quote expiry, unsupported assets, delayed settlement, and failed routes.
How to measure completion:
Reviewer completes the flow on an Android Go device profile.
The flow resumes after connectivity is interrupted at confirmation, deposit, and processing stages.
Users cannot proceed without seeing the destination amount and applicable fees.
Unsupported and expired routes do not expose a payment address.
No transaction-critical text is clipped on supported small-screen profiles.
Budget: $6,000
Brief description:
Run a structured testnet/sandbox cohort with 25 users across low-spec and standard Android devices. Test comprehension, transaction completion, weak-network recovery, and support requirements.
Before Tranche 3 begins, publish a signed mainnet-readiness document naming the specific eligible MoneyGram launch market, participating-location test plan, certification owner, and production acceptance criteria.
How to measure completion:
25 users are onboarded.
At least 20 complete the full quote-to-Stellar-destination flow without live team assistance.
All reported issues are triaged by severity.
No unresolved severity-0 or severity-1 issue remains.
A cohort report identifies the five largest friction points and the response to each.
Signed mainnet-readiness document names one verified MoneyGram market and production test location.
Budget: $8,000
An eligible user in the named launch market can withdraw Stellar USDC through Sorted, complete MoneyGram’s hosted compliance flow, receive a cash-pickup reference number, and collect local cash at a participating MoneyGram location.
Allocation: $80,000
SOW estimate: 550-580 hours
MoneyGram KYB, legal onboarding, and certification will begin before Tranche 3 development is complete. Tranche 3 will not be claimed complete until production certification and real cash-out testing are finished.
Brief description:
Configure the MoneyGram preview environment, Stellar testnet accounts, USDC/XLM setup, home-domain and TOML requirements, credentials, SEP endpoints, and test accounts. Implement the non-custodial SEP-10 authentication model, including challenge handling, transaction signing, token handling, session expiry, user mapping, and rejection of invalid or replayed challenges.
How to measure completion:
MoneyGram preview environment is operational.
SEP-10 authentication succeeds for an individual Sorted Stellar account.
Ten consecutive authentication cycles complete successfully.
Invalid, expired, reused, and incorrectly signed challenges are rejected.
Authentication and session-expiry tests are included in CI.
No MoneyGram or signing credential is present in the mobile client.
Budget: $10,000
Brief description:
Implement MoneyGram as a pluggable provider inside Sorted’s existing off-ramp abstraction. Start the SEP-24 withdrawal, open the hosted MoneyGram interface, complete required user actions, return to Sorted, and track the partner transaction through its lifecycle.
How to measure completion:
Reviewer initiates and completes at least ten preview-environment withdrawal flows.
Each flow creates a MoneyGram transaction ID.
The hosted flow opens and returns to the correct Sorted transaction.
Cancelling or abandoning the hosted flow does not send USDC.
The implementation uses the same internal provider interface as Sorted’s other off-ramp integrations.
Budget: $15,000
Brief description:
Implement amount entry, local-currency estimate, fees, limits, expiry, supported-market checks, compliance handoff, reference/PIN display, pickup instructions, and “what to show the agent” guidance.
How to measure completion:
Twenty scripted cases cover valid and invalid amounts, expired quotes, unsupported corridors, missing user information, eligibility failure, and delayed pickup.
The user sees the expected local-currency amount, fees, limits, and expiry before approving.
Unsupported users cannot reach the USDC-transfer step.
MoneyGram handles the hosted compliance flow; Sorted does not store unnecessary KYC information.
Ready transactions display the correct reference number and pickup instructions.
Budget: $12,000
Brief description:
Implement Stellar USDC balance validation, account and trustline readiness, memo and reserve handling, USDC transfer, transaction-state management, MoneyGram polling and webhooks, retry logic, ledger reconciliation, and operational alerts.
The backend will track initiated, pending, ready, completed, failed, expired, cancelled, delayed, and refunded states.
How to measure completion:
A test set of at least 30 transactions covers all supported lifecycle states.
Every completed transaction reconciles across the Sorted record, MoneyGram record, and Stellar transaction.
Replayed requests and webhooks do not create duplicate transfers.
Failed Stellar transactions cannot be marked ready for pickup.
Stuck, delayed, and reconciliation-failure alerts appear in the monitoring system.
Support staff can search by Sorted transaction ID, MoneyGram ID, or Stellar transaction hash.
Budget: $17,000
Brief description:
Complete the Android, Android Go, and simple-device experience for confirmation, compliance handoff, progress, reference number, pickup instructions, errors, and support.
Test older devices, small screens, slow connections, interrupted sessions, repeated taps, app restarts, and delayed partner responses.
How to measure completion:
Twenty controlled users test the complete preview or approved production flow.
At least 80% complete the flow without live assistance.
Transactions resume safely after app closure or network interruption.
Repeated actions do not create duplicate withdrawals.
All critical instructions are legible on supported small-screen profiles.
No unresolved severity-0 or severity-1 issue remains before production release.
Budget: $14,000
Brief description:
Complete MoneyGram certification, KYB and legal onboarding, production configuration, controlled team-only mainnet testing, application release, monitoring, and post-launch support.
The launch will initially be limited to the named eligible market and verified participating location approved in the Tranche 2 readiness gate.
How to measure completion:
MoneyGram production certification and commercial onboarding are complete.
At least five real mainnet cash-out transactions are completed.
Each transaction has a Stellar mainnet hash, MoneyGram transaction record, pickup reference, and confirmed cash-collection result.
The production Sorted build is available through its applicable public distribution channel.
Reviewer downloads the production build and verifies the flow.
No simulated transaction is counted toward the five mainnet transactions.
Thirty-day post-launch report includes completed transactions, failed transactions, reconciliation exceptions, support volume, and response times.
No unresolved severity-0 or severity-1 production defect remains.
Budget: $12,000
Our core team has 12 people, combining business development, product/technology, operations, and go-to-market expertise across fintech, Web3, digital assets, and emerging markets.
Stephen Browne leads strategy and partnerships, with legal, regulatory, and digital asset infrastructure experience: https://www.linkedin.com/in/stephen-browne/
Jure Zih leads product and technology, having built and scaled Web3/NFT companies including 0xcert, Clout.art, and Venly Market: https://www.linkedin.com/in/jurezih/
Shishir Gupta leads operations and marketing, with hands-on experience across DeFi, GameFi, Web3 projects, and emerging market execution: https://www.linkedin.com/in/shishrgupta/
Together, we have previously built companies and products across wallets, digital assets, NFT infrastructure, marketplaces, and crypto operations.
Jure Z
No other submissions.