Building Axiom's Proving Dashboard
Lead Designer • 2025 • New York City, NY
I directed a seamless user experience (UX) for managing and monitoring zero-knowledge proving jobs on blockchain applications.
.png)
Background
Axiom is a venture-backed cryptography startup building OpenVM, an open-source software package which enables developers to generate zero-knowledge (ZK) proofs which verify the correct execution of computer programs used to build blockchain applications. They were building a new product called Axiom Proving Service (APS) that allows our users (developers) to interact with OpenVM and generate zero-knowledge proofs in a seamless way. APS allows users to:
• Register programs for ZK verification
• Generate ZK proofs for programs with specified inputs
• View artifacts produced by programs
• View data generated by proofs
• Monitor proving jobs
• Track performance of programs
• Publicly publish programs, profiles, and jobs for others to see in a public dashboard (even those outside of their organizations)
APS was going to be built with 3 components:
• Set of APIs where users can perform any action (eg register programs, generate proofs, and run jobs) necessary to interact with APS (and therefore OpenVM).
• APS Public Explorer (Web) for any user to view public programs and proofs
• APS Private Dashboard (Web) to assist users in managing, monitoring, and troubleshooting their programs. They should also be able to pay for the service and monitor their usage.
In the past, the team had only offered developer products without any front-end user interface. This was the first web interface they were building as a product offering.
• Register programs for ZK verification
• Generate ZK proofs for programs with specified inputs
• View artifacts produced by programs
• View data generated by proofs
• Monitor proving jobs
• Track performance of programs
• Publicly publish programs, profiles, and jobs for others to see in a public dashboard (even those outside of their organizations)
APS was going to be built with 3 components:
• Set of APIs where users can perform any action (eg register programs, generate proofs, and run jobs) necessary to interact with APS (and therefore OpenVM).
• APS Public Explorer (Web) for any user to view public programs and proofs
• APS Private Dashboard (Web) to assist users in managing, monitoring, and troubleshooting their programs. They should also be able to pay for the service and monitor their usage.
In the past, the team had only offered developer products without any front-end user interface. This was the first web interface they were building as a product offering.
.png)
Project Overview
The team was looking to design the private dashboard and public explorer web interfaces which would help users building blockchain applications that use APS for OpenVM to manage the programs they are generating proofs for and monitor proving jobs. Users first register programs via API for verification in OpenVM. To be proven with OpenVM on APS, a program must be built, which produces some build artifacts. After registering the program, users will then be able to use our web interfaces to view key details of their work. The public explorer would support:
• Display of public registered programs
• For each program, a program profile displaying:
- OpenVM version (format: string)
- OpenVM configuration (format: JSON)
- Program hash resulting from the build process (format: string)
- Download link for program (format: link)
- Download link for ELF file resulting from the build process (format: link)
- Download link for EXE file resulting from the build process (format: link)
- Instructions for how to reproduce the build (format: string)
- The user who registered the program (format: string)
• For each program, a list of public proving jobs displaying:
- Inputs to proof (format: small text file)
- Witness data for proof (format: small text file)
- Outputs of proof (format: small text file)
- Proof itself (format: a binary file)
- Proving job metadata (time, time elapsed)
• Display of public registered programs
• For each program, a program profile displaying:
- OpenVM version (format: string)
- OpenVM configuration (format: JSON)
- Program hash resulting from the build process (format: string)
- Download link for program (format: link)
- Download link for ELF file resulting from the build process (format: link)
- Download link for EXE file resulting from the build process (format: link)
- Instructions for how to reproduce the build (format: string)
- The user who registered the program (format: string)
• For each program, a list of public proving jobs displaying:
- Inputs to proof (format: small text file)
- Witness data for proof (format: small text file)
- Outputs of proof (format: small text file)
- Proof itself (format: a binary file)
- Proving job metadata (time, time elapsed)
Our ultimate goal was to design the private dashboard and public explorer web interfaces which would help users who are building blockchain applications that use APS for OpenVM to manage the programs they are generating proofs for and monitor proving jobs.
The private dashboard supported private details that a logged-in user needed to monitor their work, performance, and costs:
• Display of all registered programs and program profiles for logged-in user / organization of logged-in user
• Display of all proving jobs for logged-in user, alongside private proving job metadata of machine type, cost, and other performance metrics
• Issuance and management of API key (see API Issuance in Glossary)
• User management (via 3rd party plugins like Clerk or WorkOS)
• Authentication (account creation, sign-in/sign-out, password recovery, etc)
• Billing details – we will handle payments separately, but this should show the cost accrued
• Summary stats on APS usage
We needed to support users and organizations within those organizations. To do so, we utilized authentication and organization management via plugins like Clerk or WorkOS:
• For organizations – all users from an org will be able to see all of the org’s views, but there will be admin users who can add or remove users from the org.
• Here organization means companies or projects where our users work.
• Display of all registered programs and program profiles for logged-in user / organization of logged-in user
• Display of all proving jobs for logged-in user, alongside private proving job metadata of machine type, cost, and other performance metrics
• Issuance and management of API key (see API Issuance in Glossary)
• User management (via 3rd party plugins like Clerk or WorkOS)
• Authentication (account creation, sign-in/sign-out, password recovery, etc)
• Billing details – we will handle payments separately, but this should show the cost accrued
• Summary stats on APS usage
We needed to support users and organizations within those organizations. To do so, we utilized authentication and organization management via plugins like Clerk or WorkOS:
• For organizations – all users from an org will be able to see all of the org’s views, but there will be admin users who can add or remove users from the org.
• Here organization means companies or projects where our users work.
Personas
1. Developers: blockchain developers who are responsible for building programs and generating accompanying ZK proofs.
Developers are often working with collaborators within their organization to write code for a project or a company. Collaborators may run proving jobs on programs that they themselves did not write.
2. Organization Admins: Administrators for the organization, controlling user access of their organization to APS. They’re likely a developer as well. If the developer is the only person within the organization, they are also the default admin.It is possible for there to only be 1 developer within an organization. There can be multiple admins within an organization.
3. Public Viewers: People who can access the public explorer of published programs and proving jobs. They can be either part of the organization or not.
Developers are often working with collaborators within their organization to write code for a project or a company. Collaborators may run proving jobs on programs that they themselves did not write.
2. Organization Admins: Administrators for the organization, controlling user access of their organization to APS. They’re likely a developer as well. If the developer is the only person within the organization, they are also the default admin.It is possible for there to only be 1 developer within an organization. There can be multiple admins within an organization.
3. Public Viewers: People who can access the public explorer of published programs and proving jobs. They can be either part of the organization or not.
Competitive Analysis
I took a lot at public blockchain explorers as well as private dashboards for API-based platforms:
.png)
User Flows
Developer
1. [Web-only] Create account / accept invitation to organization.
a. After login, they will find their user-specific API key to start using the APIs.
2. [API-only] Register programs via API in APS. This makes APS aware of the program and initiates a build process which enables APS to generate proofs for the program using OpenVM.
a. Specify Program and corresponding OpenVM config for the Program.
i. The OpenVM config must already be supported by APS, or this will error.
ii. Initially only the Axiom team can add OpenVM configs, but in future iterations developers will be able to add configs.
b. Receive a Program ID identifying their registered program and config.
3. [web OR API] Check status of program build either through API or dashboard, indexed by Program ID.
a. Monitor the build of their program on APS and check for accuracy.
b. View / download build artifacts (files and metadata created by the build necessary to generate and verify proofs for that program).
c. Builds can fail, in which case an error should be displayed
1. [Web-only] Create account / accept invitation to organization.
a. After login, they will find their user-specific API key to start using the APIs.
2. [API-only] Register programs via API in APS. This makes APS aware of the program and initiates a build process which enables APS to generate proofs for the program using OpenVM.
a. Specify Program and corresponding OpenVM config for the Program.
i. The OpenVM config must already be supported by APS, or this will error.
ii. Initially only the Axiom team can add OpenVM configs, but in future iterations developers will be able to add configs.
b. Receive a Program ID identifying their registered program and config.
3. [web OR API] Check status of program build either through API or dashboard, indexed by Program ID.
a. Monitor the build of their program on APS and check for accuracy.
b. View / download build artifacts (files and metadata created by the build necessary to generate and verify proofs for that program).
c. Builds can fail, in which case an error should be displayed
4. [API-only] Generate proofs for registered programs via API. This initiates a proving job which tells APS to generate a proof for a single program run on a single program input using OpenVM.
a. Specify Program ID, Program Input, and Job config (what type of computer resources to use, what proving strategy is requested).
b. API returns Job ID.
5. [web OR API] Check status of proving job either through API or dashboard, indexed by Job ID.
a. Monitor the status of the proving job on APS (pending / in progress / completed, requested / start / end times, time elapsed)
b. If completed, the proving job outputs:
i. Program output (specific to program/input pair)
ii. Generated proof (specific to the proving job)
iii. Metrics (specific to the proving job)
6. [web-only] Make programs / proving jobs public. Programs / jobs are default private, but can be set as public.
a. Programs can only be set as public after successful build completion.
b. Proving jobs can be set as public at any time after creation (even while in progress).
7. [web-only] Create API keys and track usage. Developers access the API using API keys, which are shown and managed via APS.
a. See usage of APS in total and per API key
a. Specify Program ID, Program Input, and Job config (what type of computer resources to use, what proving strategy is requested).
b. API returns Job ID.
5. [web OR API] Check status of proving job either through API or dashboard, indexed by Job ID.
a. Monitor the status of the proving job on APS (pending / in progress / completed, requested / start / end times, time elapsed)
b. If completed, the proving job outputs:
i. Program output (specific to program/input pair)
ii. Generated proof (specific to the proving job)
iii. Metrics (specific to the proving job)
6. [web-only] Make programs / proving jobs public. Programs / jobs are default private, but can be set as public.
a. Programs can only be set as public after successful build completion.
b. Proving jobs can be set as public at any time after creation (even while in progress).
7. [web-only] Create API keys and track usage. Developers access the API using API keys, which are shown and managed via APS.
a. See usage of APS in total and per API key
Org Admin
1. Invite users via email within organization
2. Remove users from organization when necessary
3. View total utilization of the organization
1. Invite users via email within organization
2. Remove users from organization when necessary
3. View total utilization of the organization
Public Viewer
1. View programs and proving jobs shared by developer URL, job id, or program ID
2. View all other public programs and proving jobs proven on APS
1. View programs and proving jobs shared by developer URL, job id, or program ID
2. View all other public programs and proving jobs proven on APS
Final Designs
Developer and Org Admin Flow
User finds his or her API key to start using APIs within the table.
User finds his or her API key to start using APIs within the table.
New API Keys
User will use the command line to submit a program registration and can copy the API key to access the API through the command line.
User will use the command line to submit a program registration and can copy the API key to access the API through the command line.
APS
User monitors status of proving job on APS and can view APS Public Explorer (Web) to then directly view a program's details.
User monitors status of proving job on APS and can view APS Public Explorer (Web) to then directly view a program's details.
Public Program
This web interface helps users build blockchain applications that use APS for OpenVM to manage the programs they are generating proofs for and monitor proving jobs.
This web interface helps users build blockchain applications that use APS for OpenVM to manage the programs they are generating proofs for and monitor proving jobs.
.png)
Public Job
This web interface helps developers browse jobs easily to view all proving jobs for a program, all proving jobs for all his or her programs, and all proving jobs for his or her organization.
This web interface helps developers browse jobs easily to view all proving jobs for a program, all proving jobs for all his or her programs, and all proving jobs for his or her organization.
Impact
I handed off engineering-ready designs to the team (cofounders, PM, and full-stack engineer) within two weeks of starting the project after ~70 hours across onboarding, wireframing, UI design, design reviews, and iteration cycles.
READ NEXT: SPEARHEADING 0-1 DESIGNS AT DAIMO