Aptos to Supra Cheatsheet

This quick-reference guide helps you take what you know from the Aptos framework and translate it into building Move modules with the Supra framework.

Framework Overview

Both frameworks share a few similar foundational designs of code. As such, many modules and patterns are familiar, but the migration requires updating import paths, constants, and sometimes function names to reflect the Supra ecosystem.

What’s Different?

Module Prefixes: All module references in Aptos starting with aptos_framework:: are replaced with supra_framework:: in Supra.
Additional Features: Supra includes extra modules (e.g., for randomness, advanced governance) that expand functionality.
Configuration and Constants: Some constants, such as domain separators or error codes, have been updated to reflect the Supra ecosystem.

Import Paths and Their Changes

There are differences in import paths that set Supra apart:

Aptos Example:


use aptos_framework::account::{Self, SignerCapability, new_event_handle, create_resource_address};
use aptos_framework::aptos_coin::AptosCoin;

Supra Example:


use supra_framework::account::{Self, SignerCapability, new_event_handle, create_resource_address};
use supra_framework::supra_coin::SupraCoin;

✅

All your module imports should replace aptos_framework with supra_framework accordingly.

Module and Naming Conventions

Table mapping a few key modules and their counterparts between Aptos & Supra Move Framework

Functionality	aptos_framework	supra_framework
Account Management	aptos_framework::account	supra_framework::account
Coin Operations	aptos_coin:: AptosCoin	supra_coin::SupraCoin
Multisig & Voting	aptos_framework::multisig_account	supra_framework::multisig_account
Fungible Assets	aptos_framework::fungible_asset	supra_framework::fungible_asset
Event Handling	aptos_framework::event	supra_framework::event
Governance	aptos_framework::governance	supra_framework::supra_governance
Staking/Consensus	aptos_framework::staking_config	supra_framework::staking_config
Randomness Configuration	Customized or external implementation	`[dependencies.SupraVrf]` in `Move.toml`, see Randomness *Supra offers its own Supra dVRF services for developers to integrate*

The Fungible Assets Module has Migration disabled on Mainnet, kindly use the coin_wrapper for using FA Standard in any Supra project from THIS REPO↗

Detailed Code Template Comparisons

Here is an example of diff in code for both frameworks, let’s take a look at Multisig_account module from both Frameworks:

Aptos Version


Aptos Version:
module aptos_framework::multisig_account {
    use aptos_framework::account::{Self, SignerCapability, new_event_handle, create_resource_address};
    use aptos_framework::aptos_coin::AptosCoin;
    // Other imports ...

    const DOMAIN_SEPARATOR: vector<u8> = b"aptos_framework::multisig_account";

    // Error codes
    const EDUPLICATE_OWNER: u64 = 1;
    const EACCOUNT_NOT_MULTISIG: u64 = 2002;
    const ENOT_OWNER: u64 = 2003;
    const EPAYLOAD_CANNOT_BE_EMPTY: u64 = 4;
    const ENOT_ENOUGH_OWNERS: u64 = 5;
    const ETRANSACTION_NOT_FOUND: u64 = 2006;

    /// Creates the resource account that backs a new multisig account. The function is private and
    /// `create_with_owners` is its only caller; `create` and `create_with_owners_then_remove_bootstrapper`
    /// reach it through `create_with_owners`. `create_with_existing_account*` do not call it.
    fun create_multisig_account(owner: &signer): (signer, SignerCapability) {
        // Create the resource account and its signer capability...
    }
}

Supra Version


module supra_framework::multisig_account {
    use supra_framework::account::{Self, SignerCapability, new_event_handle, create_resource_address};
    use supra_framework::supra_coin::SupraCoin;
    // Other updated imports ...

    const DOMAIN_SEPARATOR: vector<u8> = b"supra_framework::multisig_account";

    // Error codes remain conceptually similar
    const EDUPLICATE_OWNER: u64 = 1;
    const EACCOUNT_NOT_MULTISIG: u64 = 2002;
    const ENOT_OWNER: u64 = 2003;
    const EPAYLOAD_CANNOT_BE_EMPTY: u64 = 4;
    const ENOT_ENOUGH_OWNERS: u64 = 5;
    const ETRANSACTION_NOT_FOUND: u64 = 2006;

    /// Creates the resource account that backs a new multisig account. The function is private and
    /// `create_with_owners` is its only caller; `create` and `create_with_owners_then_remove_bootstrapper`
    /// reach it through `create_with_owners`. `create_with_existing_account*` do not call it.
    fun create_multisig_account(owner: &signer): (signer, SignerCapability) {
        // Implementation logic for Supra. The business logic is generally identical;
        // only the references and potentially some internal data structures have changed.
    }
}

Aside from updating the import paths and the domain separator, the business logic and error codes often remain the same. However, for advanced operations, check the Supra-specific documentation for changes in transaction handling or resource setup.

Additional Modules

Supra extends many functionalities to support a broader set of on-chain applications. Here’s a closer look at some specialized modules:

Governance & Voting

Aptos Governance: Typically found under aptos_framework::governance
Supra Governance: Mapped to supra_framework::supra_governance

Randomness

Aptos: May rely on external or manually configured randomness.
Supra: Supra offers its own Supra dVRF services for developers to integrate: Supra dVRF

The dVRF interface package is named SupraVrf, and the key of its dependency entry must be the same name. For Mainnet:


[dependencies.SupraVrf]
git = "https://github.com/Entropy-Foundation/vrf-interface"
subdir = "supra/mainnet"
rev = "master"

A key such as supra_vrf fails to resolve with “Name of dependency declared in package ‘supra_vrf’ does not match dependency’s package name ‘SupraVrf’”. The Testnet subdir and rev are listed in the dVRF documentation.

Link to Framework Repo

https://github.com/Entropy-Foundation/supra-framework/tree/mainnet/supra-framework