# Download config Source: https://docs.axiom.xyz/api-reference/rest-api/configs/download-config GET /v1/configs/{config_id}/config Download the OpenVM configuration TOML file. # Get VM config metadata Source: https://docs.axiom.xyz/api-reference/rest-api/configs/get-configs GET /v1/configs/{config_id} Retrieve details about a proving system configuration. # Get EVM verifier Source: https://docs.axiom.xyz/api-reference/rest-api/configs/get-configs-evm_verifier GET /v1/configs/{config_id}/evm_verifier Download the EVM verifier contract as a JSON file for on-chain verification. # Get proving keys Source: https://docs.axiom.xyz/api-reference/rest-api/configs/get-configs-pk GET /v1/configs/{config_id}/pk/{key_type} Generate a presigned URL to download various proving keys for a configuration. Available key types: - `app`: Application VM proving key - `agg`: Aggregation proving key - `halo2`: Halo2 proving key # Get verifying keys Source: https://docs.axiom.xyz/api-reference/rest-api/configs/get-configs-vk GET /v1/configs/{config_id}/vk/{key_type} Generate a presigned URL to download various verification keys for a configuration. Available verification key types: - `app`: Application verification key - `agg`: Aggregation verification key # Overview Source: https://docs.axiom.xyz/api-reference/rest-api/overview An API reference for the Axiom Proving API.
API endpoints for VM configuration management.
API endpoints for OpenVM program management.
API endpoints for proof generation.
API endpoints for proof verification.
API endpoints for VM configuration management.
API endpoints for OpenVM program management.
API endpoints for proof generation.
API endpoints for proof verification.
# Download program Source: https://docs.axiom.xyz/api-reference/rest-api/programs/download-programs GET /v1/programs/{program_id}/download/{program_type} Download various program artifacts including compiled binaries, source code, and configuration files. Available program types: - `exe`: Compiled program executable - `elf`: ELF binary format - `source`: Original source code archive - `app_exe_commit`: Application executable commit - `openvm_config`: OpenVM configuration file # List programs (deprecated) Source: https://docs.axiom.xyz/api-reference/rest-api/programs/get-programs GET /v1/programs DEPRECATED: This endpoint is deprecated and will be removed in a future version. Use instead: - GET /v1/projects - for dashboard functionality with search/sort across projects - GET /v1/projects/{project_id}/programs - for listing programs within a specific project # Get build status Source: https://docs.axiom.xyz/api-reference/rest-api/programs/get-programs-id GET /v1/programs/{program_id} Retrieve detailed information about a specific program. # List project programs Source: https://docs.axiom.xyz/api-reference/rest-api/programs/list-project-programs GET /v1/projects/{project_id}/programs List all programs within a specific project with pagination support. # List projects Source: https://docs.axiom.xyz/api-reference/rest-api/programs/list-projects GET /v1/projects List all projects for your organization with search and sorting capabilities. Projects help organize related programs and proofs. You can search by name and sort by various criteria. # Register new program Source: https://docs.axiom.xyz/api-reference/rest-api/programs/post-programs POST /v1/programs Register a new OpenVM program from pre-built artifacts. Build the program locally with `cargo openvm build`, then upload the resulting ELF binary together with the transpiled VMEXE. The backend computes the program's exe_commit and verification baseline asynchronously (via a lightweight Kubernetes job) and flips the program to `Ready` — no cloud compilation happens. ## Example Usage ```bash curl -X POST "https://api.axiom.xyz/v1/programs?config_id=cfg_xxxx" \ -H "Axiom-API-Key: your-api-key" \ -F "elf=@program.elf" \ -F "vmexe=@program.vmexe" \ -F "project_name=My Project" ``` # Get proof logs Source: https://docs.axiom.xyz/api-reference/rest-api/proofs/get-proof-logs GET /v1/proofs/{proof_id}/logs Download the proving logs to debug proof generation issues. # List proofs Source: https://docs.axiom.xyz/api-reference/rest-api/proofs/get-proofs GET /v1/proofs List all proofs for a specific program with pagination support. # Get proof status Source: https://docs.axiom.xyz/api-reference/rest-api/proofs/get-proofs-id GET /v1/proofs/{proof_id} Retrieve the current status and details of a proof job. # Get generated proof Source: https://docs.axiom.xyz/api-reference/rest-api/proofs/get-proofs-id-type GET /v1/proofs/{proof_id}/proof/{proof_type} Download the generated proof file in JSON format. Available proof types: - `stark`: STARK proof file - `root`: Root proof file - `evm`: EVM-compatible proof file # Generate new proof Source: https://docs.axiom.xyz/api-reference/rest-api/proofs/post-proofs POST /v1/proofs Submit a program for proving with specific input data. The input data must be a JSON object with an 'input' key containing an array of hex strings. Each hex string represents either: - Hex string of bytes (prefixed with 0x01) - Hex string of native field elements as u32 little endian (prefixed with 0x02) Available proof types: - `stark`: STARK proof (default) - `evm`: EVM-compatible proof ## Deferred child proofs (optional, multipart) To fold child stark proofs into this job's `verify_stark` deferral circuit, send `multipart/form-data` to the SAME endpoint: an `input` form field (the JSON body as a string) plus one `child_proofs` file part per child. Each part is a stark proof in the same JSON format `GET /v1/proofs/{id}/proof/stark` serves (`VersionedVmStarkProof`); part order = circuit packing order. The program's config must be deferral-enabled. Validation at submit is shallow (caps + JSON shape); keyset/program mismatches fail the job at prove time. ## Example Usage ```bash # Plain (no-deferral) submission — JSON body, unchanged: curl -X POST "https://api.axiom.xyz/v1/proofs?program_id=your-program-uuid&proof_type=stark" \ -H "Axiom-API-Key: your-api-key" \ -H "Content-Type: application/json" \ -d '{ "input": [ "0x010A00000000000000", "0x02FF00000000000000" ] }' # Deferral submission — multipart with inline child proofs: curl -X POST "https://api.axiom.xyz/v1/proofs?program_id=your-program-uuid&proof_type=stark" \ -H "Axiom-API-Key: your-api-key" \ -F 'input={"input": ["0x010A00000000000000"]}' \ -F 'child_proofs=@child0_stark_proof' \ -F 'child_proofs=@child1_stark_proof' ``` # Get EVM verification result Source: https://docs.axiom.xyz/api-reference/rest-api/verify/get-verify-id GET /v1/verify/{verify_id} Check the status and result of either an EVM or STARK proof verification. # Get STARK verification result Source: https://docs.axiom.xyz/api-reference/rest-api/verify/get-verify-stark-id GET /v1/verify/stark/{verify_id} Check the status and result of a STARK proof verification. This is a legacy endpoint that routes to the unified verification endpoint. # Verify EVM proof Source: https://docs.axiom.xyz/api-reference/rest-api/verify/post-verify POST /v1/verify Submit an EVM proof for verification. Upload the proof file and specify the configuration used. # Verify STARK proof Source: https://docs.axiom.xyz/api-reference/rest-api/verify/post-verify-stark POST /v1/verify/stark Submit a STARK proof for verification. Upload the proof file and specify the program used. The configuration will be automatically determined from the program. # Rust Client SDK Source: https://docs.axiom.xyz/api-reference/sdks/rust-client-sdk A reference for the Axiom Rust Client SDK. ## Overview The Axiom Rust SDK is a library for interacting with the Axiom Proving API. It is built on top of the Axiom Proving API and provides a higher-level interface for interacting with the API. This guide covers installation, configuration, and usage of all SDK features. ## Installation Add the Axiom SDK to your `Cargo.toml`: ## Configuration ### Setting Up Your API Key Before using the SDK, you need to configure your API key. You can do this in several ways: #### Option 1: Using the CLI (Recommended) ```bash theme={null} cargo axiom register --api-key ``` #### Option 2: Manual Configuration Create a configuration file at `~/.axiom/config.json`: ```json theme={null} { "api_url": "https://api.axiom.xyz/v1", "api_key": "your-api-key-here", "config_id": "your-config-id-here" } ``` #### Option 3: Programmatic Configuration ```rust theme={null} use axiom_sdk::{AxiomSdk, AxiomConfig}; let config = AxiomConfig::new( "https://api.axiom.xyz/v1".to_string(), Some("your-api-key".to_string()), Some("your-config-id".to_string()), ); let sdk = AxiomSdk::new(config); ``` ### Progress Callbacks The SDK supports custom progress callbacks for user feedback during long-running operations: ```rust theme={null} use axiom_sdk::{AxiomSdk, ProgressCallback}; struct MyCallback; impl ProgressCallback for MyCallback { fn on_success(&self, text: &str) { println!("✓ {}", text); } fn on_error(&self, text: &str) { eprintln!("✗ {}", text); } fn on_progress_start(&self, message: &str, total: Option) { if let Some(total) = total { println!("Starting: {} (total: {})", message, total); } else { println!("Starting: {}", message); } } // Implement other required methods... fn on_header(&self, text: &str) { println!("\n=== {} ===", text); } fn on_info(&self, text: &str) { println!("ℹ {}", text); } fn on_warning(&self, text: &str) { println!("⚠ {}", text); } fn on_section(&self, title: &str) { println!("\n--- {} ---", title); } fn on_field(&self, key: &str, value: &str) { println!("{}: {}", key, value); } fn on_status(&self, text: &str) { print!("\r{}", text); } fn on_progress_update(&self, current: u64) { print!("\rProgress: {}", current); } fn on_progress_update_message(&self, message: &str) { print!("\r{}", message); } fn on_progress_finish(&self, message: &str) { println!("\r{}", message); } fn on_clear_line(&self) { print!("\r\x1b[K"); } fn on_clear_line_and_reset(&self) { print!("\r\x1b[K"); } } // Use your custom callback let config = load_config()?; let sdk = AxiomSdk::new(config).with_callback(MyCallback); ``` ## Building Programs The `BuildSdk` trait provides functionality for registering OpenVM guest programs with the Axiom Proving API. ### Basic Build ```rust theme={null} use axiom_sdk::build::{BuildSdk, UploadExeArgs}; use std::path::Path; // Run `cargo openvm build` in this directory first. let program_dir = Path::new("./my-openvm-guest-program"); let args = UploadExeArgs { config_id: None, // Use default config project_id: None, project_name: Some("My Project".to_string()), bin_name: None, // Auto-detect binary program_name: None, default_num_gpus: None, }; let program_id = sdk.upload_exe(program_dir, args)?; println!("Program registered with ID: {}", program_id); // Wait for completion sdk.wait_for_build_completion(&program_id)?; ``` The SDK reads the OpenVM v2 build output from its default locations: the transpiled VMEXE at `openvm/release/.vmexe` (a sibling of `target/`) and the raw ELF at `target//release/`. A custom `CARGO_TARGET_DIR` or a workspace-level target directory is not currently supported. ### Build with Custom Configuration `UploadExeArgs` lets you pin the VM configuration, select a binary, and control how programs are organized into projects. #### Configuration Source Set `config_id` to register the program against a specific VM configuration instead of the system default. The ID must reference a existing config. ```rust theme={null} use axiom_sdk::build::UploadExeArgs; let args = UploadExeArgs { config_id: Some("cfg_...".to_string()), project_id: Some("existing-project-id".to_string()), project_name: None, bin_name: Some("my-binary".to_string()), program_name: Some("my-program-name".to_string()), default_num_gpus: Some(1), }; let program_id = sdk.upload_exe("./my-program", args)?; ``` #### Binary Target Selection When your `Cargo.toml` contains multiple binary targets, set `bin_name` to choose which ELF and VMEXE pair is uploaded. If the crate produces exactly one binary, leave it as `None` and the SDK detects it. #### Project Organization You can control how your programs are organized by either creating new projects or adding programs to existing ones. This is useful for maintaining logical groupings of related programs or when you want to keep all your experimental builds separate from production code. Set `project_id` to add the program to an existing project, or `project_name` to create a new one. Use `program_name` to give the program itself a recognizable name instead of the generated one. ### Managing Build Artifacts Once you've initiated a build, the SDK provides comprehensive tools to monitor progress, inspect results, and download the generated artifacts. This section covers the various ways to interact with your build results. #### Listing and Inspecting Programs The SDK allows you to retrieve information about all your programs, including their current status and any error messages. ```rust theme={null} // List all programs let programs = sdk.list_programs()?; for program in programs { println!("Program: {} ({})", program.name, program.id); println!("Status: {}", program.status); if let Some(error) = program.error_message { println!("Error: {}", error); } } ``` **Program Information Available:** * **Name**: Human-readable identifier for your program * **ID**: Unique identifier used for API operations * **Status**: Current build state (pending, building, ready, failed) * **Error Messages**: Detailed error information if the build failed #### Monitoring Build Status You can check the status of a specific build to determine when it's ready or if it has encountered any issues. ```rust theme={null} // Get specific build status let build_status = sdk.get_build_status("program-id")?; println!("Build status: {}", build_status.status); ``` **Build Status Types:** * **Pending**: Build is queued and waiting to start * **Building**: Build is currently in progress * **Ready**: Build completed successfully and artifacts are available * **Failed**: Build encountered an error and cannot proceed #### Downloading Build Artifacts Once a build is complete, you can download various artifacts that were generated during the build process. ```rust theme={null} // Download build artifacts sdk.download_program("program-id", "elf")?; sdk.download_program("program-id", "exe")?; ``` Accepted artifact types are `exe`, `elf`, `source` and `app_exe_commit`. ## Generating Proofs The `ProveSdk` trait handles proof generation for your built programs. ### Basic Proof Generation ```rust theme={null} use axiom_sdk::{prove::{ProveSdk, ProveArgs}, ProofType}; use cargo_openvm::input::Input; let args = ProveArgs { program_id: Some("your-program-id".to_string()), input: Some(Input::HexBytes("0x01".to_string())), // Bytes input proof_type: Some(ProofType::Stark), }; let proof_id = sdk.generate_new_proof(args)?; println!("Proof generation started: {}", proof_id); // Wait for completion sdk.wait_for_proof_completion(&proof_id)?; ``` ### Input Formats The SDK supports multiple input formats: ```rust theme={null} use cargo_openvm::input::Input; use std::path::PathBuf; // Hex bytes input (must start with 0x01 for bytes or 0x02 for field elements) let hex_input = Input::HexBytes("0x01010101".to_string()); // JSON file input let file_input = Input::FilePath(PathBuf::from("./input.json")); // The JSON file should contain: // { // "input": [ // "0x01010101", // bytes // "0x02123456" // field elements // ] // } ``` ### EVM Proof Generation ```rust theme={null} let args = ProveArgs { program_id: Some("your-program-id".to_string()), input: Some(Input::FilePath(PathBuf::from("./input.json"))), proof_type: Some(ProofType::Evm), }; let proof_id = sdk.generate_new_proof(args)?; sdk.wait_for_proof_completion(&proof_id)?; ``` ### Managing Proofs Once you've initiated proof generation, the SDK provides comprehensive tools to monitor progress, inspect results, and download the generated proofs. This section covers the various ways to interact with your proof generation jobs and retrieve the final artifacts. #### Listing and Inspecting Proofs The SDK allows you to retrieve information about all proofs generated for a specific program. ```rust theme={null} // List proofs for a program let proofs = sdk.list_proofs("program-id")?; for proof in proofs { println!("Proof: {} ({})", proof.id, proof.state); println!("Type: {}", proof.proof_type); if let Some(error) = proof.error_message { println!("Error: {}", error); } } ``` **Proof Information Available:** * **ID**: Unique identifier for the proof generation job * **State**: Current status of the proof generation (pending, proving, ready, failed) * **Type**: The type of proof being generated (STARK or EVM) * **Error Messages**: Detailed error information if the proof generation failed #### Downloading Proof Artifacts Once proof generation is complete, you can download the generated proofs in various formats. The SDK provides flexibility in how and where you save these artifacts. ```rust theme={null} // Download proof artifacts use std::path::PathBuf; sdk.get_generated_proof("proof-id", &ProofType::Stark, None)?; // Auto path sdk.get_generated_proof( "proof-id", &ProofType::Evm, Some(PathBuf::from("./my-proof.json")) )?; // Custom path // Download proof logs sdk.get_proof_logs("proof-id")?; ``` ## Running Programs The `RunSdk` trait allows you to execute programs without generating proofs, useful for testing and debugging. ### Basic Execution ```rust theme={null} use axiom_sdk::run::{RunSdk, RunArgs}; use cargo_openvm::input::Input; let args = RunArgs { program_id: Some("your-program-id".to_string()), input: Some(Input::HexBytes("0x01010101".to_string())), }; let execution_id = sdk.execute_program(args)?; println!("Execution started: {}", execution_id); // Wait for completion sdk.wait_for_execution_completion(&execution_id)?; ``` ### Handling Execution Results ```rust theme={null} // Get execution status let execution = sdk.get_execution_status("execution-id")?; println!("Status: {}", execution.status); if let Some(cycles) = execution.total_cycle { println!("Total cycles: {}", cycles); } if let Some(ticks) = execution.total_tick { println!("Total ticks: {}", ticks); } if let Some(public_values) = &execution.public_values { println!("Public values: {}", serde_json::to_string_pretty(public_values)?); } // Save results to file if let Some(results_path) = sdk.save_execution_results(&execution) { println!("Results saved to: {}", results_path); } ``` ## Verifying Proofs The `VerifySdk` trait provides proof verification capabilities. ### EVM Proof Verification ```rust theme={null} use axiom_sdk::verify::VerifySdk; use std::path::PathBuf; let proof_path = PathBuf::from("./evm-proof.json"); let verify_id = sdk.verify_evm(None, proof_path)?; // Use default config println!("Verification started: {}", verify_id); // Wait for completion sdk.wait_for_evm_verify_completion(&verify_id)?; ``` #### Custom Configuration for EVM Verification ```rust theme={null} let verify_id = sdk.verify_evm( Some("custom-config-id"), PathBuf::from("./proof.json") )?; ``` ### STARK Proof Verification ```rust theme={null} let proof_path = PathBuf::from("./stark-proof.json"); let verify_id = sdk.verify_stark("program-id", proof_path)?; sdk.wait_for_stark_verify_completion(&verify_id)?; ``` ## Configuration Management The `ConfigSdk` trait provides access to VM configurations and related artifacts. ### Getting Configuration Metadata ```rust theme={null} use axiom_sdk::config::ConfigSdk; let metadata = sdk.get_vm_config_metadata(None)?; // Use default config println!("OpenVM Version: {}", metadata.openvm_version); println!("Status: {}", metadata.status); println!("Active: {}", metadata.active); // Get specific config let metadata = sdk.get_vm_config_metadata(Some("config-id"))?; ``` ### Downloading Configuration Artifacts ```rust theme={null} use std::path::PathBuf; // Download EVM verifier contract sdk.get_evm_verifier(None, None)?; // Auto path sdk.get_evm_verifier( Some("config-id"), Some(PathBuf::from("./verifier.json")) )?; // Custom path // Download VM commitment sdk.get_vm_commitment(None, None)?; // Download configuration file sdk.download_config(None, None)?; ``` ### Working with Proving Keys ```rust theme={null} // Get proving key downloader let pk_downloader = sdk.get_proving_keys(None, "app_pk")?; // Download with default callback pk_downloader.download_pk("./app_pk")?; // Download with custom callback struct MyCallback; impl ProgressCallback for MyCallback { // ... implement methods } pk_downloader.download_pk_with_callback("./app_pk", &MyCallback)?; ``` ## Project Management The `ProjectSdk` trait helps organize your programs into projects. ### Creating and Managing Projects ```rust theme={null} use axiom_sdk::projects::ProjectSdk; // Create a new project let project = sdk.create_project("My New Project")?; println!("Created project: {}", project.id); // List projects let projects = sdk.list_projects(Some(1), Some(20))?; // page 1, 20 items for project in projects.items { println!("Project: {} ({})", project.name, project.id); println!("Programs: {}", project.program_count); println!("Total proofs: {}", project.total_proofs_run); } // Get specific project let project = sdk.get_project("project-id")?; println!("Project: {}", project.name); ``` ### Managing Project Programs ```rust theme={null} // List programs in a project let programs = sdk.list_project_programs("project-id", None, None)?; for program in programs.items { println!("Program: {} in project {}", program.id, program.project_name); } // Move program to different project sdk.move_program_to_project("program-id", "new-project-id")?; ``` ## Troubleshooting This section covers common issues you may encounter when using the Axiom Rust Client SDK, along with detailed solutions and preventive measures. **1. `CLI not initialized` Error** ```bash theme={null} # Solution: Register your API key cargo axiom register --api-key ``` **2. `API key not valid or inactive` Error** * Check that your API key is correct * Verify your API key is active in the Axiom dashboard * Ensure you're using the correct API endpoint **3. `Not in a Rust project` Error** * Ensure `Cargo.toml` exists in the directory you passed to `upload_exe` **3a. `OpenVM build output not found` Error** * Run `cargo openvm build` in the guest crate before registering the program * The error names the directory it expected, normally `openvm/release` * If you set `CARGO_TARGET_DIR` or build from a workspace root, the artifacts land outside the expected paths, which are not currently supported **4. Registration Failures** ```rust theme={null} // Inspect the failure reason let status = sdk.get_build_status(&program_id)?; println!("Status: {}", status.status); if let Some(error) = status.error_message { println!("Error: {}", error); } ``` **5. Input Validation Errors** * Hex strings must start with `0x01` (bytes) or `0x02` (field elements) * JSON input files must have an `"input"` array * All input values must be valid hex strings ## API Reference ### Core Types * `AxiomSdk`: Main SDK struct * `AxiomConfig`: Configuration for API endpoint, key, and default config ID * `ProgressCallback`: Trait for handling progress events * `NoopCallback`: Silent progress callback implementation ### Traits * `BuildSdk`: Program building functionality * `ProveSdk`: Proof generation functionality * `RunSdk`: Program execution functionality * `VerifySdk`: Proof verification functionality * `ConfigSdk`: Configuration management functionality * `ProjectSdk`: Project management functionality ### Enums * `ProofType`: `Evm` or `Stark` * `ConfigSource`: `ConfigId(String)` or `ConfigPath(String)` # Getting Help Source: https://docs.axiom.xyz/api-reference/support-and-config/getting-help We’ve tried to provide the answers to the most common questions in these docs. If you need further technical assistance, please reach out to your contact at Axiom or contact us at [support@axiom.xyz](mailto:support@axiom.xyz). # API Status Source: https://docs.axiom.xyz/api-reference/support-and-config/status Monitoring Status and Outages for the Axiom Proving API The current uptime status of the Axiom Proving API is available at [axiomstatus.xyz](https://axiomstatus.xyz/). We will share details of any planned API maintenance or unplanned outages on that page. # Versions Source: https://docs.axiom.xyz/api-reference/support-and-config/versions Versioning Policy for the Axiom Proving API The Axiom Proving API is versioned and available at `api.axiom.xyz/{version}`. For any given API version, we will preserve: * Existing input parameters * Existing output parameters However, we may do the following: * Add additional optional inputs * Add additional values to the output * Change conditions for specific error types Generally speaking, updates to a given API version will be backwards compatible. ## Version History We always recommend using the latest API version whenever possible. Previous versions are considered deprecated and may be unavailable for new users. At present, `v1` is the only API version. # API Setup Source: https://docs.axiom.xyz/api-reference/using-the-api/api-setup Accessing and using the Axiom Proving API ## Accessing the API ### Getting an API Key The API is currently available to invited users only. To get an API key, get an invitation to the [API console](https://prove.axiom.xyz) from the Axiom team and create a new key using your account. ### Authentication All requests to the Axiom Proving API must include an `Axiom-API-Key` header with your API key. If you are using the Axiom CLI, you will initialize the client with an API key, and the client will set the API key in every request you make. If you are making raw REST API requests, you must set this header yourself. # Axiom CLI Source: https://docs.axiom.xyz/api-reference/using-the-api/axiom-cli Accessing the Axiom Proving API via CLI We provide a Cargo-based CLI paralleling the [OpenVM CLI](https://docs.openvm.dev/book/writing-apps/overview) to make it easier to work with the Axiom Proving API while developing and deploying a guest program. ## Installation and Authentication Build from source using the following command: You can verify the installation afterwards by listing available commands using: ```bash theme={null} cargo axiom --help ``` To authenticate with the Axiom Proving API, run ```bash theme={null} cargo axiom register --api-key ``` The API key can be passed in directly or by setting the `AXIOM_API_KEY` environment variable in a `.env` file. ``` AXIOM_API_KEY= ``` Note that `cargo axiom register` should be run in the directory containing the `.env` file. Throughout the CLI, `--config-id` is optional and defaults to the system default config id. ### Shell Completions The Axiom CLI supports autocompletion for all commands and options. To set up completions for your shell: ```bash theme={null} cargo axiom completions ``` Supported shells: bash, zsh, fish, elvish, powershell The command will generate a completion file and provide installation instructions specific to your shell. After installation, restart your shell or source your shell's configuration file, then test by typing `cargo axiom` and pressing TAB. ## Initializing a Project ### `cargo axiom init ` This command initializes a new OpenVM project with the given name containing a starter Rust guest program. ## Downloading VM Configs ### `cargo axiom config download-keys --config-id --type ` This command allows users to download proving keys for different VM configurations. At present, only a single `ID` is supported, and the possible options for `TYPE` are: * `app_pk`: Application proving key. * `agg_pk`: Aggregation proving key. * `halo2_pk`: Proving key for halo2 verifier. * `app_vk`: Application verification key. * `agg_vk`: Aggregation verification key. The response will be a download URL because proving key files are large. ## Building Programs ### `cargo axiom build --config-id ` This command registers a program to be proven on the Axiom Proving API by uploading a locally built ELF and VMEXE pair. Build the guest locally, then upload: The requirements are: * This command must be run in the guest program directory so we know which binary is the guest program. * `Cargo.toml` must be present. * `cargo openvm build` must have produced OpenVM v2 output in the default location. The transpiled VMEXE is written to `openvm/release/.vmexe`, a sibling of `target/`, and the raw ELF to `target//release/`. A custom `CARGO_TARGET_DIR` or a workspace-level target directory is not currently supported. * When the crate has multiple binaries, pass `--bin ` to select which pair to upload. The command waits for processing to finish by default. Pass `--detach` to return as soon as the upload completes. ### `cargo axiom build status --program-id ` This command allows users to check on the status of the program registered by `cargo axiom build`. Pass `--wait` to poll until the program is ready. ### `cargo axiom build download --program-id --artifact ` This command allows users to download the program artifacts for the given program `ID`. The accepted values for `TYPE` are: `exe`, `elf`, `source`, `app_exe_commit` and `all`. ### `cargo axiom build list` List the programs that are accessible by the API key. ## Generating Proofs ### `cargo axiom prove --program-id --type --input ` This command allows users to request proofs of type `TYPE` for the registered program with `ID` with input `INPUT`. The possible options for `TYPE` are: * `stark`: The final STARK proof generated by OpenVM. * `evm`: The halo2 proof ready for EVM verification. The `INPUT` field needs to either be a single hex string or a file path to a JSON file that contains the key `input` and an array of hex strings. If your hex string represents a single number, it should be written in little-endian format (as this is what OpenVM expects). In addition, if you need multiple input streams, only the file path option is supported. Each hex string (either in the JSON file or as direct input) is either: * A hex string of bytes prefixed with `0x01` * A hex string of native field elements (represented as concatenated `u32` in little endian encoding) prefixed with `0x02` See [the OpenVM documentation](https://docs.openvm.dev/book/writing-apps/overview#inputs) for more details. Pass `--deferred-proof ` to supply a previously generated proof to a deferral job. Repeat the flag to supply more than one. ### `cargo axiom prove status --proof-id ` This command allows users to check on the status of proof generation for proof `ID`. ### `cargo axiom prove logs --proof-id ` This command allows users to download proof logs. ### `cargo axiom prove download --proof-id --type --output ` This command allows users to download proof artifacts from a proving job identified by `ID`. The command `TYPE` identifies the artifact type and `FILE` identifies the output directory. The possible options for `TYPE` are: * `stark`: The final STARK proof generated by OpenVM. * `evm`: The halo2 proof ready for EVM verification. ### `cargo axiom prove list --program-id ` List the proofs that are run for the given program `ID`. ## Executing Programs ### `cargo axiom run --program-id --input ` This command allows users to execute a program with the given `ID` and input `INPUT`. ### `cargo axiom run status --execution-id ` This command allows users to check the status of an execution request identified by `ID`. ## Verifying Proofs As a convenience, the CLI provides verification of OpenVM proofs (for both STARK and EVM). ### `cargo axiom verify evm --config-id --proof ` The VM configuration is identified by `ID` and the proof should be in `FILE`. ### `cargo axiom verify stark --program-id --proof ` The program is identified by `ID` and the proof should be in `FILE`. ### `cargo axiom verify status --verify-id --proof-type ` This command allows users to check the status of a verification request identified by `ID` and a proof type `TYPE` (either "evm" or "stark"). # Reproducible Builds Source: https://docs.axiom.xyz/api-reference/using-the-api/reproducible-build Building OpenVM programs deterministically Using OpenVM securely requires deterministic program compilation, which enables users to verify that OpenVM binaries correspond to the original programs they are interested in. We achieve this by running the compilation process in a Docker container. We use the following host and guest versions of Rust: * The host architecture is `linux/amd64` with Rust .0. * The guest target is `riscv32im-risc0-zkvm-elf` with Rust . The resulting RISC-V ELF is then transpiled to an OpenVM binary. See [the OpenVM documentation](https://docs.openvm.dev/book/writing-apps/compiling-a-program) for more details about this build process. ## Reproducing a Build To replicate a build done on the Axiom Proving API, follow the following steps. Before running them, make sure you have [`cargo-openvm`](https://docs.openvm.dev/book/getting-started/install) and [Docker](https://docs.docker.com/engine/install/) installed. 1. Download the program source code (a `tar.gz` file) and the OpenVM config (a `openvm.toml` file) from the Axiom Proving API console program page. 2. Prepare the following files locally: An executable script (`compile.sh`), that compiles a program and puts the output in the `output` directory: ```bash compile.sh theme={null} #!/bin/bash cd YOUR_PROGRAM_NAME # this is the directory name of your program cargo openvm build cp openvm/release/*.vmexe ../output/ ``` And the `Dockerfile`. Note that `--platform=linux/amd64` on the first line is necessary to guarantee that the build is identical. 3. And then run these commands: ```bash theme={null} docker build -f Dockerfile . -t my-reproducible-build:latest mkdir -p output docker run -v $(pwd)/output:/output my-reproducible-build:latest ``` 4. Finally, download the OpenVM exe from the Axiom Proving API console and confirm that it matches what you obtained locally. ```bash theme={null} diff output/your-program.vmexe your-downloaded-exe ``` # API Console Source: https://docs.axiom.xyz/changelog/api-console Changelog for Axiom API Console ## v1.0.2 * Display information about GPU quotas. ## v1.0.1 * No console updates. ## v1.0.0 * Update OpenVM to `v1.4.0`. ## v0.4.0 * Add projects feature to group programs in the console. * Update design of program and job pages. ## v0.3.0 * No console updates. ## v0.2.1 * Update OpenVM to `v1.1.2` ## v0.2.0 * Beta release of Axiom API Console. # Axiom CLI Source: https://docs.axiom.xyz/changelog/axiom-cli Changelog for Axiom CLI ## v2.0.0 * Bump OpenVM to `v2.0.0` * **Breaking:** `cargo axiom build` now uploads a locally built ELF and VMEXE pair instead of uploading source for a server-side reproducible build. Run `cargo openvm build` first. * Added `cargo axiom prove --deferred-proof ` for deferral jobs. Repeat the flag to pass multiple proofs. ## v1.3.0 * Bump OpenVM to `v1.7.0` ## v1.2.0 * Bump OpenVM to `v1.6.0` ## v1.1.0 * Bump OpenVM to `v1.5.0` ## v1.0.10 * Bump OpenVM to `v1.4.3` ## v1.0.9 * Bump OpenVM to `v1.4.2` ## v1.0.7 * Bug fixes * Better pagination support ## v1.0.6 * Update to OpenVM 1.4.1 * Minor CLI quality of life improvements ## v1.0.5 * Add ability to upload prebuilt exe (available via whitelist only) ## v1.0.2 * Add ability to cancel running jobs. * Improve compilation time of the CLI itself. ## v1.0.1 * Add execution modes to `cargo axiom run` paralleling `cargo openvm` functionality * Expose instructions in prove status ## v1.0.0 * Update OpenVM to `v1.4.0`. ## v0.4.0 * Update OpenVM to `v1.3.0`. * Fulfill CLI commands using Axiom SDK. * Rename `cargo axiom init` to `cargo axiom register`. * Introduce new `cargo axiom init` command to start a new project using the API. ## v0.3.0 * Update OpenVM to `v1.2.0` ## v0.2.1 * Update OpenVM to `v1.1.2` ## v0.2.0 * Update OpenVM to `v1.1.1` ## v0.1.2 * `cargo axiom build` now pre-fetches dependencies and uploads them to the Axiom Proving API to ensure reproducible builds. ## v0.1.1 * Fix usage of `cargo axiom init` when API key is in a `.env` file ## v0.1.0 * Initial release of Axiom CLI for OpenVM. # Axiom SDK Source: https://docs.axiom.xyz/changelog/axiom-sdk Changelog for Axiom SDK ## v2.0.0 * Bump OpenVM to `v2.0.0` * **Breaking:** `upload_exe` with `UploadExeArgs` replaces `register_new_program` with `BuildArgs` as the path used by `cargo axiom build`. `BuildArgs` no longer carries `config_source`, `allow_dirty`, `keep_tarball`, `exclude_files`, `include_dirs` or `openvm_rust_toolchain`. * Reads OpenVM v2 build output: `openvm/release/.vmexe` and `target//release/` ## v1.3.0 * Bump OpenVM to `v1.7.0` ## v1.2.0 * Bump OpenVM to `v1.6.0` ## v1.1.0 * Bump OpenVM to `v1.5.0` ## v1.0.2 * Improve compilation time of the SDK itself. ## v1.0.1 * Add support for execution modes. ## v1.0.0 * Initial release of Axiom SDK with support for OpenVM `v1.4.0`. # Overview Source: https://docs.axiom.xyz/changelog/overview Follow along with updates across the Axiom Proving API.
Releases for the REST API interface.
Releases for the Axiom CLI interface.
Releases for the Axiom SDK.
Releases for the Axiom API Console.
Releases for the REST API interface.
Releases for the Axiom CLI interface.
Releases for the Axiom SDK.
Releases for the Axiom API Console.
# REST API Source: https://docs.axiom.xyz/changelog/rest-api Changelog for Axiom REST API ## v2.0.0 * Bump OpenVM to `v2.0.0` * Retire support for OpenVM `v1.7` * Program registration now accepts a locally built ELF and VMEXE pair instead of a source archive. Source is no longer compiled server-side. ## v1.3.0 * Bump OpenVM to `v1.7.0` * Retire support for OpenVM `v1.6` ## v1.2.0 * Bump OpenVM to `v1.6.0` * Retire support for OpenVM `v1.4` and `v1.5` ## v1.1.0 * Bump OpenVM to `v1.5.0` * OpenVM `v1.4` is now deprecated ## v1.0.10 * Bump OpenVM to `v1.4.3` ## v1.0.9 * Bump OpenVM to `v1.4.2` ## v1.0.7 * Better pagination support ## v1.0.6 * Bump OpenVM to `v1.4.1` ## v1.0.2 * No API updates. ## v1.0.1 * No API updates. ## v1.0.0 * Add support for OpenVM `v1.4.0`. * Retire support for OpenVM `v1.3.0`. ## v0.4.0 * Update OpenVM to `v1.3.0`. ## v0.3.0 * Update OpenVM to `v1.2.0` ## v0.2.1 * Update OpenVM to `v1.1.2` ## v0.2.0 * Update OpenVM to `v1.1.1` ## v0.1.0 * Initial alpha release of Axiom Proving API for OpenVM. * Support for OpenVM v1.0.0. * Support for API-only single machine proving on a private alpha basis. # Introduction Source: https://docs.axiom.xyz/user-guides/getting-started/introduction About the Axiom Proving API The Axiom Proving API enables developers to generate proofs for ZK-enabled applications built with [OpenVM](https://openvm.dev) via a hosted API interface. This allows developers to access reliable cloud infrastructure built by Axiom to reduce cost and latency for OpenVM proof generation while maintaining a similar developer experience. To try the API, get started at [Quickstart](/user-guides/getting-started/quickstart). Developers can use a REST API and accompanying Axiom SDK and CLI compatible to generate proofs for [supported OpenVM versions](/user-guides/openvm/versions). The following operations are supported: * **OpenVM Deployment:** Key generation and configuration for OpenVM, including generation of smart contract verifiers. * **OpenVM Program Deployment:** Publicly reproducible builds and artifact management for programs built with OpenVM. * **Proof Generation and Verification:** ZK proof generation and verification for OpenVM programs. These API docs detail the following: * [**Quickstart:**](/user-guides/getting-started/quickstart) A simple example of how to use the Axiom Proving API using the CLI. * [**Using the API:**](/api-reference/using-the-api/api-setup) A guide for setting up and using the API via CLI. * [**API reference:**](/api-reference/rest-api/overview) A comprehensive API reference. If you are an application or infrastructure developer interested in using OpenVM to generate ZK proofs using the Axiom Proving API, [please get in touch](https://chat.axiom.xyz). # Quickstart Source: https://docs.axiom.xyz/user-guides/getting-started/quickstart Generate your first proof with the Axiom Proving API in under 5 minutes ## Setup API Access ### Get an API Key The API is currently available to invited users only. To get an API key, get an invitation to the [API console](https://prove.axiom.xyz) from the Axiom team and create a new key using your account. ### Install the Axiom CLI and Initialize with your API Key To use the Axiom Proving API from CLI, you must install the Axiom command line tool `cargo-axiom` using the following command. You should first make sure you have installed the necessary [Prerequisites](#installation-prerequisites), notably including `cargo-openvm`. To authenticate with the Axiom Proving API, run ```bash theme={null} cargo axiom register --api-key ``` The API key can be passed in directly or by setting the `AXIOM_API_KEY` environment variable in a `.env` file. ```bash theme={null} AXIOM_API_KEY= ``` Note that `cargo axiom register` should be run in the directory containing the `.env` file. ## Register a Program We will now walk through an example of generating a proof on the Axiom Proving API for an example Fibonacci guest program. First, initialize a new project: ```bash theme={null} cargo axiom init fibonacci ``` Note that this creates the `Cargo.toml` and adds `openvm` dependencies for you. The `openvm` version used depends on your local `cargo openvm` version, so make sure `cargo openvm` is up to date. ### Building Your Program Build the guest locally, then register the resulting ELF and VMEXE pair with the Axiom Proving API under the default [VM configuration ID](/user-guides/openvm/configuration#supported-configurations) with config-id = . `cargo axiom build` uploads artifacts produced by `cargo openvm build`, so run the two in this order from the guest program directory. This will return a `program-id` and display the project information. You can check the build status with: ```bash theme={null} cargo axiom build status --program-id [program-id] ``` The status output will show both the program details and which project it belongs to: `cargo axiom build` already waits for the program to be ready, so this step is only needed if you passed `--detach`. Alternatively, `build status` can poll on its own: ```bash theme={null} cargo axiom build status --program-id [program-id] --wait ``` ### Understanding Projects vs Programs The Axiom Proving API organizes your code into **Projects** and **Programs**: * **Project**: A logical container that groups related programs together. Projects have human-readable names like `"fibonacci"` and unique project IDs like . * **Program**: A specific build of your code within a project. Programs have computer-generated names like `"bulky-piculet"` and program IDs like . The first time you run `cargo axiom build`, the CLI will prompt you for a project name and create the project accordingly. The `project-id` is stored locally at `.axiom/project-id`. On subsequent runs in the same directory, the CLI will reuse this `project-id` so new programs are added to the same project. To add a program to an existing project, add `--project-id ` to your build command. ## Generate a Proof Next, request a proof from the Axiom Proving API: ```bash theme={null} cargo axiom prove --program-id [program-id] --type stark --input "0x010A00000000000000" ``` This will return a `proof-id`. You can check the status of the proving job with: ```bash theme={null} cargo axiom prove status --proof-id [proof-id] ``` Similarly using `--wait` polls the proving status automatically ```bash theme={null} cargo axiom prove --program-id [program-id] --type stark --input "0x010A00000000000000" --wait ``` Once the proving job is done, you can download the proof using: ```bash theme={null} cargo axiom prove download --proof-id [proof-id] --type stark --output proof.json ``` Finally, verify the proof is valid using: ```bash theme={null} cargo axiom verify stark --program-id [program-id] --proof proof.json ``` ## Installation Prerequisites Prior to installing `cargo-axiom`, make sure you have the following packages installed: # Config Support Source: https://docs.axiom.xyz/user-guides/openvm/configuration Supported OpenVM configurations on the Axiom Proving API OpenVM allows developers to specify a zkVM configuration consisting of VM extensions using a `openvm.toml` file. For each supported version, supported configurations may be added, but supported configurations will not be discontinued. ## Supported Configurations. The Axiom Proving API supports the following OpenVM configurations. | OpenVM Version | Deployment Type | Config ID | `openvm.toml` | | -------------- | --------------- | ---------------------------------------------------------------------------------------------------------------- | ------------- | | `v2.0.0` | Production | Download | | # Introduction to OpenVM Source: https://docs.axiom.xyz/user-guides/openvm/intro-to-openvm A performant and modular zkVM framework built for customization and extensibility OpenVM is an open-source zero-knowledge virtual machine (zkVM) framework focused on modularity at every level of the stack. OpenVM is designed for customization and extensibility without sacrificing performance or maintainability. Developers can use OpenVM to generate ZK proofs that verify the execution of arbitrary Rust programs, accelerate proving with custom VM extensions, and verify proofs on-chain efficiently. OpenVM ships with: * A Rust frontend supporting std and no-std programs via compilation to RISC-V. * Verification of unbounded length programs via continuations and proof aggregation. * A Solidity verifier to efficiently verify OpenVM proofs in EVM. * A robust set of VM extensions allowing developers to efficiently verify operations like the following efficiently from within standard Rust programs: * SHA2-256 and Keccak hashes. * Elliptic curve operations over short Weierstrass curves including ECDSA on secp256k1 and secp256r1. * Optimal Ate pairing on curves including BN254 and BLS12-381. * Int256 and modular arithmetic over arbitrary moduli. * STARK recursion. To learn more about OpenVM, you can check out: * [Developer Quickstart](https://docs.openvm.dev/book/getting-started/quickstart): A developer-focused guide to proving your first Rust program with OpenVM. * [Developer Book](https://docs.openvm.dev/book): A guide for using OpenVM to prove arbitrary code execution in Rust and for customizing OpenVM by adding program-specific VM extensions. * [Whitepaper](https://openvm.dev/whitepaper.pdf) and [Specifications](https://docs.openvm.dev/specs): A formal specification for OpenVM including details on the proof system, no-CPU architecture, continuations design, and soundness analysis. * [OpenVM GitHub](https://github.com/openvm-org/openvm): The source code for OpenVM. To chat with other developers building with OpenVM, join the OpenVM [Developer Chat](https://t.me/openvm). # Security Source: https://docs.axiom.xyz/user-guides/openvm/security Security considerations for OpenVM As of July 2026, OpenVM v2.0.0 is recommended for production use. OpenVM v2.0.0 completed an external security review by [zkSecurity](https://zksecurity.xyz/), available as the [v2.0.0 audit report](https://github.com/openvm-org/openvm/blob/main/audits/v2/v2.0.0-zksecurity-report.pdf). Earlier versions completed manual security reviews through external [audits](https://github.com/openvm-org/openvm/tree/main/audits) on [Cantina](https://cantina.xyz/) and an internal [audit](https://github.com/openvm-org/openvm/tree/main/audits/v1/v1-internal) by members of the [Axiom](https://axiom.xyz/) team. As of February 2026, the OpenVM RV32IM extension has been formally verified in [Lean](https://lean-lang.org/) by [Nethermind Research](https://www.nethermind.io). All audit reports for OpenVM are available on the [OpenVM GitHub](https://github.com/openvm-org/openvm/tree/main/audits). To report a security issue pertaining to OpenVM, please see the [OpenVM Security page](https://github.com/openvm-org/openvm/blob/main/SECURITY.md). # Version Support Source: https://docs.axiom.xyz/user-guides/openvm/versions Supported OpenVM versions on the Axiom Proving API The Axiom Proving API maintains support for production versions of OpenVM for as long as practical. Preview versions of OpenVM are not recommended for production and will be regularly deprecated and retired. ## Deprecation Policy Axiom uses the following terms to describe the lifecycle of OpenVM support: * **Supported:** The version is actively supported by Axiom and recommended for use on the API. * **Deprecated:** The version is not supported for new deployments, but Axiom maintains legacy support on the API. * **Retired:** The version is not supported by Axiom and is no longer available on the API. Axiom notifies all users with active deployments of OpenVM with upcoming deprecations and retirements. ## OpenVM Version Status All currently and previously supported versions of OpenVM are listed below with their status. | OpenVM Version | Deployment Type | Status | Deprecated | Retired | | -------------- | --------------- | --------- | ---------- | ---------- | | `v2.0.0` | Production | Supported | N/A | N/A | | `v1.7.0` | Production | Retired | `20260729` | `20260729` | | `v1.6.0` | Production | Retired | `20260630` | `20260630` | | `v1.5.0` | Production | Retired | `20260518` | `20260518` | | `v1.4.3` | Production | Retired | `20260209` | `20260518` | | `v1.4.2` | Production | Retired | `20260209` | `20260518` | | `v1.4.1` | Production | Retired | `20260209` | `20260518` | | `v1.4.0` | Production | Retired | `20260209` | `20260518` | | `v1.3.0` | Production | Retired | `20250828` | `20250828` | | `v1.2.0` | Production | Retired | `20250818` | `20250818` | | `v1.1.2` | Production | Retired | `20250605` | `20250605` | | `v1.1.1` | Production | Retired | `20250508` | `20250508` | | `v1.0.0` | Production | Retired | `20250505` | `20250505` |