Designing a platform to manage a country's digital currency
A B2G project for the Government of Uzbekistan
Role: Product designer Product: web app Scope: Currency issuance and burn · Multisig wallets · Organisations and users · Roles and permissions · Transfers · Notifications · Dashboard Project type: B2G, custom development for government Client: Government of the Republic of Uzbekistan
Context
Asterium is a platform for issuing, managing and circulating Uzbekistan's national digital currency. Essentially, it's an infrastructure layer for a state-backed digital currency, intended in the future to unite banks, companies and government bodies in a single, transparent system of money flow. This is a B2G project with a high cost of error: we weren't designing an interface for the mass consumer, but a tool to be operated by government officials, issuers, banks and operators. Every action in the system is an operation with real national currency, so the logic of permissions, confirmations and audit had completely different requirements than in a typical fintech product.
Currency issuance and burn
This is one of the largest and most complex flows in the project — many roles are involved, each with its own set of actions and view of the operation. To structure it properly, I broke the flow into sections and connected them via Autoflow — it was easier to hold the whole picture in my head and discuss it with the team. The operations themselves are critical — they can't be rolled back. So execution is tied to multisig: for an operation to go through, you need to collect signatures from several signers. The flow is built for multi-user work. Inside a deal you can see details, download attached documents, leave comments — all of which is necessary because several people with different roles work on a single operation at once and need a shared context.
Wallets and multisig
Wallets in the system don't belong to a person — they belong to an organisation. So to send money, one user isn't enough; you need several signatures. This is a baseline security requirement for a financial platform at this level. We worked out the multisig concept together with the CEO: how many signers by default, what the signature threshold is, how long a transaction lives before being cancelled. I was responsible for how this works in the interface. When creating a wallet, the administrator adds signers, sets the required number of signatures and the transaction's time-to-live. When someone initiates a transfer, the others see it in the pending list — with the number of collected signatures, the remaining time, and the option to sign or reject. If time runs out and there aren't enough signatures, the transaction is auto-cancelled. Wallet parameters can be changed after creation — adding or removing signers, changing the threshold. This is also a critical action, so it goes through the same multisig confirmation.
Analytics dashboard
Another big task on the project was the issuer's analytics dashboard for tokens and transactions. It's a separate role in the system and needs its own slice of data: how many tokens have been issued in total, how many are in circulation, what transaction activity looks like, whether there are anomalies. We worked on this together with bizdev — they helped figure out which metrics actually matter for an issuer, what they should show, and how they're looked at in real work. I turned this into a dashboard structure: what we surface at the top as key indicators, what we show as dynamics, and what as distribution. The result is a three-level dashboard: at the top — key numbers (tokens issued, issuance forecast, average transaction time, total volume), in the middle — interaction structure, activity anomalies and security level, and at the bottom — trends in transactions and in issuance/burn over time.
Organisations, users and roles
The platform has many roles — organisation admin, signer, operator, regulator representative, and others. Each has its own set of permissions: some create wallets, some only sign, some only view reports. The role model itself was owned by the product manager — they aligned it with the client, and it kept being refined throughout the project: new roles appeared, permissions changed. My job was to turn this matrix into a clear interface. I designed flows for creating organisations, adding users and assigning roles. The administrator sees all users in their organisation, their roles and statuses, can invite new ones and change permissions for existing ones. To make the interface withstand changes in the role model without rework, I designed it through component states — a new role plugs into existing screens rather than requiring its own flow. Separately I thought about making sure each role only sees what they're supposed to and doesn't run into disabled buttons and empty screens. It's a small thing, but in a system with dozens of roles it strongly affects how the product feels.
What was difficult
A few things in this project made the work tough, and I think it's important to call them out. First, there was no user research. In B2G that's the norm — the end user is a ministry or a bank, and you can't just show up there for an interview. So all decisions were made inside the team and through alignment with the client, and I had to learn to lean on the CEO's and PM's expertise instead of direct feedback. Second, the role model was being refined throughout the project. New roles appeared, permissions changed. I designed components and states so that new roles would slot into existing screens without rework. Third, I was the only product designer on a project of this scale. That gave freedom, but also meant the systemic quality of all the work was on me. Flow coherence, a single visual language, consistency of states — I kept all of that myself, talking it through with the art director along the way.
Result
The platform is shipped to production and handed over to the client. At the current stage it operates with demo organisations and demo tokens; onboarding real organisations and switching to real operations is planned as the next phase of the project. The client accepted the work, and remarks and revisions were closed within the project.
What I take away from this project
On this project I worked for the first time with such a complex role model and with operations that can't be rolled back. It strongly changed how I approach flows — now I look at states, permissions, and confirmation points first, and the visual layer is assembled on top of that. It was also my first B2G experience, and it taught me to work without direct access to users — through the team's expertise and alignment with the client.