DD 68: Token Feature Roadmap

13.68. DD 68: Token Feature Roadmap#

Status: incomplete draft (2025-07-31)

13.68.1. Summary#

This design document documents the roadmap for token types supported by Taler.

13.68.2. Motivation#

13.68.3. Plan for Wallet#

Types of tokens:

  • donations tokens (hard deadline: End of November)

    • onboarding (1st donation)

      • ask for tax payer id, add taxOfficeBaseUrl (only one per wallet)

      • can be changed, but new donations will have a different tax payer ID

      • store date with tax payer ID for merge

    • reporting: per year, one QR code per: (taxPayerId, walletSalt, year)

      • meta data per QR code: taxPayerId, walletSalt, year, taxOfficeBaseUrl

      • out of scope: generate PDF

      • listing: just show sum (per tax payer ID and year and salt), not individual tokens

    • listing: there is separate listing for tokens

    • delete: out of scope for now / future work

  • subscription

    • listing

      • Expired tokens are deleted automatically after grace period (30 days).

      • Consider not deleting the last token of a particular slug. Maybe in the future, subscription tokens will have a link to re-purchase them.

      • No counter

      • Show expiration date

    • delete (with big fat warning)

  • discount tokens

    • listing (type and number, description) * group by expiration date (if it exists)

    • delete

  • asset tokens (deadlines: end of March)

    • listing (with number, no fractions possible, no expiration)

    • background task: poll for share action, automatically execute the share action

      • share action dividend: not supported for now

      • share action voting: multiple in parallel possible, maybe show vote weight, have expiration date

      • votes are grouped under the respective asset tokens

    • voting action

      • normally grouped under asset token (“history” for corporate actions)

      • in notificiation state: vote directly or dismiss

      • eventually, result is fetched and shown

    • divident (initially out of scope)

      • normally grouped under asset token (“history” for corporate actions)

      • in notificiation state: dismiss, auto-dismiss after some time

13.68.4. Plan for Merchant Backend#

TBD.

13.68.5. Plan for Donau#

  • Service exists

  • Needs to packaged

13.68.6. User Experience#

13.68.6.1. Donau MVP#

Donor / wallet user:

  1. User opens Taler wallet, goes to Settings -> Donations

  2. In the initial state, user can enter a donau base URL and tax ID.

  3. Subsequently, the Settings -> Donations screen shows:

    • Currently configured donation authority

    • Currently configured tax ID

    • Navigation link Show donation statements

  4. User makes a payment with a merchant that offers donation receipts. If the merchant supports the same donau service as configured in the wallet, the wallet UI shows some notice (e.g. This payment provides a donation receipt).

  5. User can view their current donation statement via Settings -> Donations -> Show donation statements.

Merchant:

In the MVP, the merchant backend will be set up via the REST API, we won’t provide any SPA support.

13.68.6.2. Donau Next Iteration#

Donor / wallet user:

In the post-MVP iteration, we want to improve the onboarding experience. The wallet should ask during a payment that supports a donation receipt if the user wants to set up donation receipts.

As the merchant might offer multiple donau URLs (each for their own financial domain), the user needs to be shown all possible donaus with their respective financial domain. After choosing the donau, the user needs to enter their tax payer identifier.

Merchant:

In the post-MVP iteration, the merchant SPA should allow a merchant to set up the donau integration. This includes the following steps:

  1. The merchant registers a charity ID with the donau.

    • The SPA should probably explain this process and show the merchant public key, which needs to be given to the donation authority for the charity registration process.

    • The actual registration happens via a side channel (e-mail, postal, in person, …), there is no protocol for this.

    • As a result of the registration, the merchant obtains a charity_id

  2. The merchant SPA provides a configuration page for the supported donation authorities, where the merchant can enter the donau base URL and charity ID.

  3. For each configured charity, there should be a details page that shows the used and remaining donation amount.

  4. When creating an order via the SPA, there should be an option labled “this is a donation”.

13.68.7. Test Plan#

  • Subscription/discount: blog.demo.taler.net

  • Donations: donations.demo.taler.net

    • Receipt validation: TBD

  • Asset tokenization: TBD / will be deployed on demo via merchant

13.68.8. Definition of Done#

  • Donau deployed in sandcastle

  • donations in demo must use donau / contracttermsv1

  • use separate app (prototype exists?) for verification of receipts

13.68.9. Discussion / Q&A#

(This should be filled in with results from discussions on mailing lists / personal communication.)