Capital · coordination · constructionCareers
MLG BlockchainAI & blockchain engineering · a practice of GDA Group

Wallet — service, mobile and extension

The wallet service — balances, credits, debits and the idempotent write path into the ledger — is specified as a versioned contract against an endpoint that already exists in production. The client applications are a different matter, and this page separates the two rather than letting the working half imply the other.
IN BUILDCode exists, under active construction.

Evidence for that status: The wallet service contract is specified in flashy-contracts/specs/wallet.v1.yaml against an endpoint already present in production. No iOS, Android or browser-extension client exists in the group’s estate today. Read the case study →

What it does

Balance and entries

An append-only entry model where every credit names its source and carries an idempotency key derived from the causing event, not from a timestamp.

Service-to-service writes

A separate trust boundary from user sessions and from admin, because another service is neither.

Versioned contract

Breaking changes mint a new version rather than mutating the current one; a consumer that cannot redeploy in lockstep is the normal case.

White-labelled, and not

Yours

  • Brand and any surface built on the service
  • Asset, denomination and entry-source configuration
  • The support relationship with your holders

Not white-labelled

  • iOS, Android and browser-extension clients — these do not exist yet; see the status note
  • Any regulatory permission to hold value on a person’s behalf
  • Custody of external chain assets — that is the custody platform, a separate and unverified legacy asset

Integration surface

http · credit an identityidempotent
POST /v1/internal/wallet/credit
x-internal-key: <service credential, not an admin key>
{
  "identityId": "idn_1042",
  "amount": "25.00",
  "source": "duel-win",
  "idempotencyKey": "duel-win:8831"
}
→ replaying the key returns the original entry and writes nothing

REST for credit, debit and balance; the idempotency key is required rather than advisory, because a key that differs on every retry is the absence of one wearing the costume of one.

Who operates what

The licensee owns the programme and any regulatory position on holding value. We own the service, its contract and its defects. Client applications are an engagement, not a licence — see below.

Service
In build; contract published
iOS · Android · extension
Not built — north star
Licensing
Annual + accounts
Support
Tiered; SLA in contract

Publication gate: capability claims on this page are verified against the running software before publication. Lineage: Built in-house.

Reference deployment

A rewards ledger that reconciles, by construction — A points-and-rewards ledger built so that a repeated request cannot double-credit a balance — with the idempotency key derived from the event that caused it, never from a timestamp.

Related

Request a technical evaluation

Engineers on both sides, against your requirements. If the software does not do what you need, this is where you find out.