Skip to content

Milestones

List view

  • Migrate Freighter History to Wallet Backend

    Due by June 30, 2026
    0% complete0 open0 closed

  • Migrate Freighter Account Balances to Wallet Backend

    Due by June 30, 2026
    •4/4 issues closed
    100% complete0 open4 closed

  • Wallet Backend O3 Performance Experiments

    As part of the O3 performance pod, we want to conduct experiments for wallet backend - this could range from optimizing ingestion performance, improving read latency and any other whacky experiments we can think of.

    No due date
    •0/2 issues closed
    0% complete2 open0 closed

  • Data Migrations

    Adds the ability to support new protocols or bespoke deployments as a migration in order to provide a first class experience for protocols in history, and to build features that require protocol state(like balances). Design Document: https://github.com/stellar/wallet-backend/pull/503

    No due date
    •10/10 issues closed
    100% complete0 open10 closed

  • Indexing Reserves

    Today, the wallet backend indexes transactions that sponsor reserves for registered accounts. However, it does not index the increases and decreases of an account's reserves, which is used to derive the account's available XLM balance. We should update our indexing to replace "sponsorship" state changes with "reserve" state changes that index a larger set of changes. Namely, we should index changes to reserves regardless of whether an account sponsored the reserve. Once this is implemented, it can be used to calculate the "available" balance for registered account's current XLM balance.

    No due date
    0% complete0 open0 closed

  • Webhook or Websocket Support

    The wallet backend is a pull-only service, so clients must poll the API to get its data and become aware of changes to their users' accounts' state. We should consider supporting a push method, so clients can be notified of changes to registered accounts without polling. HTTPS webhooks are one common approach, but websockets are also common and better-suited for client-side applications without backends. Given that the API is also GraphQL, and therefore API response schemas are flexible and defined by the client, it is unclear what the schema of HTTPS or websocket callbacks should be, or if we should try to define an approach for the client to specify their preferred schema and criteria for receiving a message.

    No due date
    0% complete0 open0 closed

  • Support SEP-50

    Today the wallet backend only indexes SEP-41 tokens. We should add support for SEP-50 NFTs as well. This includes both historical state (so transactions, operations, and state changes) as well as current state, similar to SEP-41 tokens, so clients can query for the collectibles an account currently has.

    No due date
    0% complete0 open0 closed