Audit of Aleo Multisig Wallet and its usage in Compliant Stablecoin and Bridges

Aleo Foundation • December 1st, 2025 • Technical Report

Introduction

On December 1st, 2025, Aleo Foundation tasked zkSecurity with auditing their Multisig Wallet program and its integration into several applications and protocols. The specific code to review was shared via both public and private GitHub repositories. The audit lasted one week with two consultants.

Scope

The main purpose of multisig wallet currently boils down to two use cases:

Requiring multiple signatures for program upgrades.
Requiring multiple signatures for admin-specific functions of several different applications and protocols.

For this reason, this audit not only focused on the multisig core engine, multisig_core, but also covered how this engine is utilized by other applications and protocols to gate upgrades (e.g., in test_upgrade) and admin functions (e.g., in Hyperlane’s warp tokens).

More specifically, we reviewed the following programs:

Repo: https://github.com/AleoNet/aleo-multisig

The multisig_core program, which is the core multisignature engine, at commit 940050959f5877ba59f2889430f5b0e7a6a6e96f.
The test_upgrades program, which shows how program upgrades can be gated behind a multisig operation, at commit 940050959f5877ba59f2889430f5b0e7a6a6e96f.

Repo: https://github.com/eranrund/hyperlane-aleo/tree/eran/multisig

The hyp_multisig program, which can be used to gate privileged operations on Hyperlane’s mailbox, ism_manager, and hook_manager programs, at commit a978035035900d72ea68073ccb23cda73bf5a68f.
The hyp_warp_multisig program, which represents the interface program between multisig_core and Hyperlane’s warp token programs, at commit a978035035900d72ea68073ccb23cda73bf5a68f.

Repo: https://github.com/sealance-io/compliant-transfer-aleo

The compliant_token_template program, which provides a token template that includes freeze list enforcement, at commit 052bbd9d26336ac3f9cefae2c9595df7c26bcaaf.
The sealance_freezelist_registry program, which is the freeze list registry used by the compliant_token_template, at commit 052bbd9d26336ac3f9cefae2c9595df7c26bcaaf.

Repo: private

The circle_bridge program, which handles cross-chain token transfers between Ethereum and Aleo, at commit 45e0aa94d6041cd0874c0c73eec697c53decc8ed.

Scope Variance

This section outlines several changes present in the deployed commit that were not included in the original audit scope, while noting that the deployed version continues to use multisig program upgrades covered in the audit.

More specifically, the differences are as follows:

The same multisig_core program, which differs only by the removal of the UPGRADER_ADDRESS constant. Instead, the UPGRADER_ADDRESS is stored in a mapping and is initialized as part of the init() transition. It can later be updated via the set_upgrader_address() transition (until upgrades are disabled by disallow_upgrades()).
The stablecoin_program, which is equivalent to the audited compliant_token_template, but differs by removing multisig administrative actions (not to be confused with multisig-controlled program upgrades, which remain intact), and removing multisig version of mint and burn.
The freezelist_program, which is equivalent to the audited sealance_freezelist_registry, which differs only by the removal of multisig administrative actions.
The same circle_bridge program, which incorporates the same difference as above: removal of multisig administrative actions.

Although these variants were not part of the original audit scope, they rely on the same multisig upgrade flow and structural assumptions evaluated in the audited codebase.

For completeness in the report, we also reference the corresponding commits in the Provable compliant-stablecoin repository (https://github.com/ProvableHQ/compliant-stablecoin) at commit d3dda6117c47d043f12b448e6c8f912f519bddb1 and note that these versions have been reviewed at a high level as part of this variance assessment.

Overview

Multisig core

multisig_core.aleo implements a reusable t-of-n threshold multi-signature engine for Aleo programs. It manages wallets (identified by Aleo addresses), tracks authorized signers (both Aleo signature and ECDSA), enforces signature thresholds for arbitrary operations, and exposes admin transitions to adjust signer sets or thresholds. State lives in the following mappings:

wallets_map: stores each wallet’s threshold and signer count
signers_map: tracks hashed signer identities
pending_signing_ops: tracks signing rounds
completed_signing_ops: tracks completion status

Program Flow

Wallet setup: Use create_wallet to register a wallet ID, threshold, and signer set. This populates wallets_map and hashes each signer into signers_map.
Operation initiation: A participant calls initiate_signing_op from their Aleo account. The transition hashes (wallet_id, signing_op_id) into wallet_signing_op_id_hash, ensures no active/completed round exists, creates a new pending_signing_op struct, and, if the caller is a registered signer, records their signature as the first confirmation.
Collect signatures: Each authorized signer calls sign (for Aleo signature) or sign_ecdsa (for ECDSA) with the same wallet_id and signing_op_id. The contract confirms the signer is registered, the pending op exists and hasn’t expired, the round value matches (if specified), and the signer hasn’t already signed this round. It increments confirmations, and once the count meets the current threshold, records the op in completed_signing_ops.
Execution in consuming program: Program can then call assert_signing_completed(wallet_id, signing_op_id) which checks if wallet_signing_op_id_hash exist in the completed_signing_ops, before performing any sensitive action. This ensures that the specific action (bound to the signing_op_id) is gated by the multisignature approval before proceeding.

In addition to the basic flow, the program also handles administrative actions for updating wallet policy — such as adding or removing signers and increasing or decreasing the signing threshold — following the same flow as normal wallet-signing operations. This ensures that governance updates are subject to the same multisig protections as any other action.

Note that during wallet setup, the program also supports a Guarded wallet configuration, where any call to create_wallet must be pre-approved by the “guard wallet,” which is simply the multisig_core.aleo program’s own address used as the wallet_id. This special wallet can only be created by the program deployer when the Guarded wallet setting is enabled.

Multisig Program Upgrades

The multisig functionality can be used to gate program upgrades behind multisignature approvals.

It is demonstrated in the test_upgrades example below:

program test_upgrades.aleo {
    struct ChecksumEdition {
        checksum: [u8; 32],
        edition: u16,
    }

    // A helper for calculating a signing_op_id from the program's checksum and edition.
    // By deriving the signing_op_id from both we ensure that downgrades cannot take place.
    transition get_signing_op_id_for_deploy(checksum: [u8; 32], edition: u16) -> field {
        return BHP256::hash_to_field(ChecksumEdition { checksum: checksum, edition: edition });
    }

    @custom
    async constructor() {
        // Only require multisig for upgrades - initial deployment has no checks.
        if self.edition > 0u16 {
            let signing_op_id = BHP256::hash_to_field(ChecksumEdition { checksum: self.checksum, edition: self.edition });

            let wallet_signing_op_id_hash = BHP256::hash_to_field(WalletSigningOpId { wallet_id: self.address, signing_op_id: signing_op_id });
            let signing_complete = multisig_core.aleo/completed_signing_ops.contains(wallet_signing_op_id_hash);
            assert(signing_complete);
        }
    }

    transition main(public a: u32, b: u32) -> u32 {
        let c: u32 = a + b;
        return c;
    }
}

Before deploying a new program edition, maintainers derive a signing_op_id from the target edition and the bytecode checksum, and then run a multisig round using a wallet_id equal to the program’s address.

Once enough signatures have accumulated, the constructor of the upgraded program checks completed_signing_ops for the corresponding wallet_signing_op_id_hash, which binds together the program address, program edition, and its checksum. If the signing operation has not been approved, the constructor rejects the deployment.

Hyperlane Multisig

The Hyperlane Protocol

Hyperlane is a permissionless cross-chain messaging protocol that enables applications to send arbitrary messages between blockchains.

Conceptually, the protocol has two main flows:

The Dispatch Flow (on the origin chain) An application calls dispatch to initiate the sending of a message from the origin chain to the destination chain.
The Process Flow (on the destination chain) An off-chain relayer collects that message and calls process to submit the message on the destination chain, where it is verified and then executed by a target application.

The Hyperlane protocol has three main actors: applications, validators, and relayers. Applications are the “users” of the protocol. They are the ones initiating and receiving cross-chain messages. On the origin chain, an application’s entry point for sending a message is Hyperlane’s Mailbox. This program records the message and triggers post-dispatch hooks such as an IGP Hook to charge and account for gas on the destination, and a Merkle Tree Hook to append the message to a Merkle tree whose root will later be signed by validators. Validators watch the Mailbox, compute Merkle roots over dispatched messages, sign these roots, and make these signatures available for the relayers. An off-chain relayer can then fetch the signed Merkle root and the corresponding message, and then provide these to the process function on the destination chain’s Mailbox. During that call, the relayer will additionally pass the address of an Interchain Security Module (ISM) that specifies verification rules for the message to be considered valid (e.g., what validator quorum is required). The Mailbox then delegates verification to the ISM, and on success, invokes the destination application to apply the message.

Lastly, it’s important to note that the architecture of Hyperlane’s Aleo integration differs slightly from the standard Hyperlane protocol due to constraints imposed by the Leo programming language. For instance, to dispatch messages, applications on Aleo don’t call dispatch directly on the mailbox but rather on a dedicated dispatch_proxy program. However, these Aleo-specific differences are not really relevant to this audit, so we omit them here. For a more detailed account on this topic, we refer the reader to our previous audit report for Hyperlane’s Aleo integration.

The `hyp_multisig` Program

The hyp_multisig program represents the multisig-controlled governance layer of Hyperlane’s core programs on Aleo. More specifically, it will become the owner of the mailbox, the ism_manager, and the hook_manager. Once in place, all privileged operations on these programs are routed through hyp_multisig and are only executed if a corresponding multisig operation has been correctly initialized and fully signed via multisig_core. The high-level usage pattern is as follows:

Wallet Setup After deployment, init is called to create a wallet in multisig_core with a specified threshold and signer set. The corresponding wallet_id is deterministically derived from self.address.
Operation Initialization To initialize a multisig operation, an admin proposes by calling init_multisig_op and providing a signing_op_id, an expiration block, and an op::Op struct that encodes what will eventually be executed (e.g., “set the default ISM to address X”).
Signing (off-program, in multisig_core) The signers sign the operation with multisig_core tracking the signatures and completion status.
Execution When enough signatures have been collected, an executor can call the corresponding exec_* transition (e.g., exec_mailbox_set_default_ism) to execute the proposed multisig operation.

Using this pattern, the following Hyperlane admin actions will be gated by multisig:

Mailbox

set_dispatch_proxy
set_owner
set_default_ism
set_default_hook
set_required_hook

ISM Manager

set_domain
remove_domain
transfer_routing_ism_ownership

Hook Manager

set_destination_gas_config
remove_destination_gas_config
transfer_igp_ownership
claim

The hook manager’s claim will send accumulated fees to the hyp_multisig program. To withdraw these funds, admins can use the exec_credits_transfer_to_caller transition, provided they first initiated and signed a corresponding multisig operation.

Lastly, the hyp_multisig program has a @custom constructor which enforces that program upgrades are gated by multisig: for editions beyond the initial deployment (i.e., self.edition > 0), the constructor checks that an associated signing operation has been completed in multisig_core.

The `hyp_warp_multisig` Program

Hyperlane Warp Routes (HWRs) are cross-chain asset bridges that enable the transfer of tokens between chains using Hyperlane. Developers can permissionlessly deploy HWRs to move assets between chains. Hyperlane’s Aleo integration currently provides three different program templates that can be used to create HWRs. These are:

The hyp_native template. This can be used to interact with the native currency of Aleo, i.e., the credits program.
The hyp_synthetic template. This enables bridging of synthetic (wrapped) representations of external assets on Aleo. On inbound transfers, synthetic tokens are minted to mirror the origin chain asset. On outbound transfers, they are burned before dispatch.
The hyp_collateral template. This enables bridging of existing assets that are already registered in the token_registry program. On inbound transfers, tokens are transferred from the hyp_collateral program to the recipient. On outbound transfers, they are transferred from the sender to the hyp_collateral program before dispatch.

The hyp_warp_multisig represents the interface program between multisig_core and any one of the above warp-token programs. This way, all admin-level operations on a given warp token can be gated by multisig logic. Developers will have to deploy an instance of hyp_warp_multisig for each warp token they are deploying.

The usage of hyp_warp_multisig follows the same “Setup-OpInit-Signing-Execution” pattern as in hyp_multisig, which is why we don’t repeat it here.

The specific warp-token actions that can be multisig-gated by hyp_warp_multisig are:

set_custom_hook
set_custom_ism
set_owner
enroll_remote_router
unroll_remote_router

As with hyp_multisig, the constructor enforces multisig-based upgrades: for program editions beyond the initial deployment, it checks that the upgrade has been approved as a completed signing operation in multisig_core.

Compliant Token Template

This token program is a token that allows addresses to transfer tokens between accounts, supporting public to public, public to private, private to public and private to private transfers.

In addition to the privacy-preserving transfers, the program has its compliance enforced with a freeze list, where frozen accounts cannot move funds. The latest pull request has multisig supported, where a completed signing request is required in order to:

Upgrade the compliant token program to the next edition,
Update the role of a wallet or an address, given that the operating wallet has the MANAGER_ROLE,
Mint publicly or privately given that the operating wallet has the MINTER_ROLE,
Burn publicly or privately given that the operating wallet has the BURNER_ROLE,
Pause (or unpause) the compliant token program, which disables (resp. enables) the exchange of tokens, given that the operating wallet has the PAUSE_ROLE.

Except program upgrade, each of the other functions already had a counterpart that allows an address with appropriate roles to perform the same action.

Freeze List

The freeze list is maintained as an ordered Merkle tree of frozen addresses in sealance_freezelist_registry.leo. Multisig is enabled in the latest pull request, where the below features are implemented:

Upgrade the freeze list program to the next edition,
Update the roles of a wallet or an address, given that the operating wallet has the MANAGER_ROLE,
Update the block height window given that the operating wallet has the FREEZELIST_MANAGER_ROLE, and
Update the freeze list, given that the operating wallet has the FREEZELIST_MANAGER_ROLE.

Bridge Program

The bridge program (circle_bridge.aleo) implements the integration of Circle’s XReserve protocol, enabling minting and burning of wrapped USDC in a way consistent with Circle’s attestation model. At its core, the contract processes deposit payloads signed by Circle, verifies freeze-list requirements, ensures replay protection through a deposit nonce, and initiates mint or burn operations in the downstream bridged_usdc.aleo program, which based from Compliant Token Template.

The integration of multisig in the current audit is to gate administrative actions behind multisignature approvals, which enforces correct binding, expiry, and role authorization before applying changes.

There are three administrative operations that utilize multisig:

Pause bridge: Pause/unpause bridge by the pause admin role.
Update Circle attester: Rotate and update Circle attester key used for ECDSA verification.
Update role: Allows reassignment of wallet roles by the manager role.

In addition to those administrative operations, the multisig is also used to gate program upgrades as explained in the multisig program upgrades section.

Findings

Below are listed the findings found during the engagement. High severity findings can be seen as so-called "priority 0" issues that need fixing (potentially urgently). Medium severity findings are most often serious findings that have less impact (or are harder to exploit) than high-severity findings. Low severity findings are most often exploitable in contrived scenarios, if at all, but still warrant reflection. Findings marked as informational are general comments that did not fit any of the other criteria.

ID	Component	Name	Risk
#00	bridge_program/src/main.leo	Role takeover in bridge program due to unbound target wallet	High
#01	hyp_multisig/src/main.leo	Multisig payout in `hyp_multisig` does not bind the recipient address	High
#02	multisig_core/src/main.leo	ECDSA signatures cannot be invalidated, allowing them to be replayed for incompleted operations	Medium
#03	multisig_core/src/main.leo	Incomplete binding of admin operation in the multisig_core	Medium
#04	bridge_program/src/main.leo	Incorrect role assertion in the update role for non-multisig bridge program	Medium
#05	bridge_program/src/main.leo	Missing request clearing in pause and attester update allow for replays	Medium
#06	multisig_core/src/main.leo	Initialization of upgrader address should not rely on manual updates of hardcoded constants	Low

#00 - Role takeover in bridge program due to unbound target wallet

Severity: High Location: bridge_program/src/main.leo

Description.

In the bridge program, the manager role can assign any roles to another wallet via the update_wallet_id_role call. However, the BridgeMultisigOp structure does not include the target_wallet_id, which causes the computed signing_op_id to remain the same even when different target_wallet_id values are used.

Because the approved init_multisig_op does not bind to a specific target_wallet_id, an adversary can take an already-approved multisig operation and call update_wallet_id_role with a different target_wallet_id.

Impact.

This enables unauthorized takeover of roles, including privileged roles such as the manager role, by allowing an attacker to redirect the approved operation to an arbitrary wallet they control.

Recommendation.

Include the target_wallet_id in the BridgeMultisigOp structure to ensure that the signing_op_id is uniquely and immutably tied to a specific target_wallet_id.

Client response.

Fixed in commit 57fc89ef59ca4918df452dc88875a9c4bfda17b0.

#01 - Multisig payout in `hyp_multisig` does not bind the recipient address

Severity: High Location: hyp_multisig/src/main.leo

Description.

The Hyperlane multisig records the intent of an operation by hashing an op::Op struct during init_multisig_op and later ensuring the same hash matches before execution. For op::CREDITS_TRANSFER_TO_CALLER the struct only captures the approved amount (arg_u128_0). During execution, the program pays credits.aleo/transfer_public(self.caller, amount), so the actual recipient is whoever calls the transition, not a value committed in the signed payload.

Impact.

An attacker can monitor for a completed signing operation approving a payout, front‑run the intended beneficiary, and receive the funds.

Recommendation.

Include the recipient address in the signed op::Op (e.g., store it in arg_addr_0) and, during execution, assert that it matches self.caller (or transfer to the signed recipient directly) so that signatures bind to a specific beneficiary.

Client response.

Fixed in commit 00e4000a83b200978cb4ddcb8b6ecbae945ae16e.

#02 - ECDSA signatures cannot be invalidated, allowing them to be replayed for incompleted operations

Severity: Medium Location: multisig_core/src/main.leo

Description.

In the multisig_core program, sign_ecdsa would take a signature to the tuple (wallet_id, signing_op_id) as a public input. It will then contribute to the number of confirmations if the signature is valid.

However, the finalize_initiate_signing_op function (used by the initiate signing operations) allows an expired, incomplete signing operation of the same (wallet_id, signing_op_id) pair to be created.

Impact.

This allows an adversary to replay the signing requests to increase the number of confirmations. In the unfortunate scenario where there are ECDSA signatures contributing to an incompleted signing operation, an adversary could dump the signatures and proceed with the operation if the threshold is decreased.

For operations that have no cryptographic bindings (for instance, the operations in hyp_multisig and hyp_warp_multisig), an adversary can create the same (wallet_id, signing_op_id) with an arbitrary operation. This might lead to loss of funds if either the threshold is decreased, or enough signatures are collected from multiple rounds of signing operations.

Recommendation.

Ensure that no signing operations have the same signing_op_ids. A nonce can be introduced if the operation is cryptographically tied to the operation ID.

Client response.

Fixed in commit 4bee24a276a7ff6a430b476357911811b3cced14.

#03 - Incomplete binding of admin operation in the multisig_core

Severity: Medium Location: multisig_core/src/main.leo

Description.

The wallet_signing_op_id_hash in multisig_core does not currently bind the associated AdminOp, allowing the operation to be silently swapped. When a pending admin operation expires, any caller can re-initialize the same signing_op_id, which overwrites pending_admin_ops while reusing the existing pending_signing_ops. Because the signing_op_id remains unchanged, signers will continue signing under the assumption that they are approving the original admin operation, while in reality the underlying AdminOp has been replaced.

Impact.

This enables a potential front-running scenario: an adversary can detect that a pending admin operation is about to expire, submit a re-initialization transaction with the same signing_op_id but a different AdminOp, and race ahead of the original re-init attempt. As a result, signers may be unknowingly tricked into approving an unintended admin operation.

Recommendation.

Bind the AdminOp into the wallet_signing_op_id_hash so that it is uniquely and immutably tied to a specific admin operation, and cannot be reused with different parameters.

Client response.

Fixed in commit 0e9076a2d36f870d43b423311f50371d8e559f97.

#04 - Incorrect role assertion in the update role for non-multisig bridge program

Severity: Medium Location: bridge_program/src/main.leo

Description.

The bridge program allows a single-admin configuration where role updates do not require a multisig operation and can be executed solely by the MANAGER_ROLE.

However, in f_update_wallet_id_role, the function asserts the ATTESTER_ROTATOR role instead of the MANAGER_ROLE, as shown in the snippet below:

assert_eq(multisig_op.salt, 0scalar);
let current_role: u16 = address_to_role.get(caller);
assert(current_role & ATTESTER_ROTATOR == ATTESTER_ROTATOR);

Impact.

This allows an ATTESTER_ROTATOR (whose responsibility should be limited to rotating attesters) to assign arbitrary wallet roles, which can lead to privilege escalation.

Recommendation.

Update the assertion to require the MANAGER_ROLE instead of ATTESTER_ROTATOR.

Client response.

Fixed in commit 2063af3121e7fbd393c75d3ebd6828384c189b0d.

#05 - Missing request clearing in pause and attester update allow for replays

Severity: Medium Location: bridge_program/src/main.leo

Description.

In the bridge program, a wallet with the PAUSE_ADMIN role can pause the bridge via multisig_pause_bridge. In the finalize function (f_update_bridge_pause), the program checks that the multisig operation is completed, has not expired, and is tied to the correct BridgeMultisigOp stored in pending_request.

However, the program does not remove the wallet_signing_op_id_hash from pending_request, which allows the function to be replayed indefinitely as long as the pending_request entry remains unexpired.

Note that the same issue also occurs in f_update_circle_attester.

Impact.

This enables indefinite replays of pause or attester-change requests, allowing an adversary to reuse stale approvals or toggle bridge settings long after signers intended those operations to expire.

Recommendation.

Add the following line after validation in both f_update_bridge_pause and f_update_circle_attester:

pending_requests.remove(wallet_signing_op_id_hash);

Client response.

Fixed in commit 8248bdac6b77d82c44a0a0f8bd802f126f4a6aca.

#06 - Initialization of upgrader address should not rely on manual updates of hardcoded constants

Severity: Low Location: multisig_core/src/main.leo

Description.

The program hardcodes DEPLOYER_ADDRESS and UPGRADER_ADDRESS to public test addresses, and expects the production deployer to manually update these constants before deployment. While the constructor guards against deployments from an unexpected DEPLOYER_ADDRESS, the UPGRADER_ADDRESS is not protected in the same way.

Impact.

If the production deployer forgets to replace the test upgrader address aleo1s3ws5tra87fjycnjrwsjcrnw2qxr8jfqqdugnf0xzqqw29q9m5pqem2u4t (whose private key is publicly known to be APrivateKey1zkp2RWGDcde3efb89rjhME1VYA8QMxcxep5DShNBR6n8Yjh) before deployment, any attacker can impersonate it to upgrade the program or permanently disable upgrades.

Recommendation.

Instead of hardcoding the UPGRADER_ADDRESS, consider storing an upgrader_address value in ProgramSettings during initialization (e.g., as done for guard_create_wallet), then enforcing it at every use. More specifically, assert

assert_eq(self.program_owner, program_settings.upgrader_address);

in the else branch of the constructor, and

assert_eq(caller, program_settings.upgrader_address);

in disallow_upgrades. This removes the reliance on the manual code edit for UPGRADER_ADDRESS and ensures the intended upgrader is explicitly configured during initialization.

Client response.

Fixed in commit f2b227185d94c32703f1e44cec5db424c16edeee.

← Back to Index

Audit of Aleo Multisig Wallet and its usage in Compliant Stablecoin and Bridges

Introduction

Scope

Scope Variance

Overview

Multisig core

Program Flow

Multisig Program Upgrades

Hyperlane Multisig

The Hyperlane Protocol

The hyp_multisig Program

The hyp_warp_multisig Program

Compliant Token Template

Freeze List

Bridge Program

The `hyp_multisig` Program

The `hyp_warp_multisig` Program