Sealance Compliance Technology for Aleo and Provable CUR Bridge

Description. Neither the bridge contract nor the compliant token contract check the freeze list when minting or burning tokens.

In bridge_program/src/main.leo, the mint transition does not verify that the recipient is not on the freeze list before minting tokens. Similarly, the burn transition does not check whether the caller is frozen before allowing the burn operation.

In compliant_token_template.leo, the mint_private and burn_public functions are callable by the bridge without any freeze list enforcement. These functions lack inclusion checks when invoked through the bridge.

This allows frozen accounts to bypass freeze list restrictions by using the bridge to move funds in and out of the system.

Impact. Sanctioned addresses can receive bridged tokens via mint operations and can burn tokens to move funds back to Ethereum, completely bypassing the freeze list enforcement that is otherwise present in standard token transfers.

Recommendation. Add freeze list checks to bridge operations. For consistency with the compliant token policy, the most important invariant is that burning (moving funds out) should be restricted for frozen accounts, while minting (transfers to frozen accounts) is optional. The bridge side is the preferred location for these checks to allow for exceptional scenarios where frozen account funds might need to be burned to escrow addresses if required by compliance procedures.

Client response. Acknowledged and fixed on the bridge repository in commit 69a8db4, adding both private inclusion checks in the freeze list for minting and public checks for burning.

Description. The bridge’s mint function extracts the localToken field from the deposit payload but only validates that it is non-zero, not that it matches the expected Ethereum token address.

At lines 71-75:

// Ensure the local token contract address is not the zero address.
let local_token_contract_address: [u8; 32] = [0u8; 32];
for i in 0u8..32u8{
    local_token_contract_address[i] = deposit_input[108u8 + i];
}
assert (local_token_contract_address != [0u8; 32]);

The code only checks != 0 rather than comparing against an expected constant value representing the specific Ethereum token that should collateralize this bridge.

Impact. Without exact validation, the bridge could accept Circle attestations for deposits of the wrong Ethereum token. For example, test token attestations could be used on production bridges. While Circle’s attestation service likely has safeguards, the bridge contract should not rely solely on those to prevent mismatched tokens. Given that the information on the Ethereum token address is part of the deposit parameters, checking this on the Aleo contract follows the defense-in-depth principle and prevents minted Aleo tokens being backed by incorrect Ethereum collateral.

Recommendation. Define a constant for the expected Ethereum token address and validate exact equality:

const EXPECTED_LOCAL_TOKEN: [u8; 32] = [...];  // Expected Ethereum token address
assert_eq(local_token_contract_address, EXPECTED_LOCAL_TOKEN);

This ensures the bridge only accepts deposits for the specific Ethereum asset it is designed to bridge.

Client response. The client acknowledges this and is considering adding an expected constant value to address this finding.

Description. The update_role function allows a manager to accidentally remove their own MANAGER_ROLE without verifying that at least one manager remains in the system. A manager calling update_role on their own address with a role value that does not include MANAGER_ROLE will successfully demote themselves, potentially leaving the system without any managers. This affects both the token contract and the freeze list contract.

Impact. If the last manager accidentally removes their own role, the system’s role management becomes locked. While this is recoverable by having UPGRADE_ADDRESS deploy a new edition with a recovery function, the recovery process could be operationally cumbersome.

Recommendation. Add a self-demotion check to prevent managers from accidentally removing their own manager role:

if (caller == new_address) {
    assert(new_role & MANAGER_ROLE == MANAGER_ROLE);
}

This would prevent accidental self-demotion while still allowing intentional role transfers where Manager A grants manager role to Manager B, then B demotes A.

Client response. Acknowledged and fixed in PR #108, including adding test cases for this scenario.

Description. The README describes the deposit payload layout from the Ethereum sender’s perspective, while the Aleo bridge code parses it from the Aleo recipient’s perspective. This creates confusing variable names that don’t accurately reflect what the fields represent. The README field remoteRecipient at offset 76 (the Aleo address receiving tokens) is extracted into a variable named local_depositor_address at line 80:

// Ensure the local depositor address is not the zero address.
let local_depositor_address: [u8; 32] = [0u8; 32];
for i in 0u8..32u8{
    local_depositor_address[i] = deposit_input[76u8 + i];
}

This is later converted to depositor_address, but this field actually represents the Aleo recipient, not a depositor. A clearer name would be local_recipient_address. Similarly, the field names remote_token_contract_address (offset 44) and local_token_contract_address (offset 108) are also potentially confusing. If offset 76 is considered “local” from the Aleo bridge’s perspective, then the token addresses should follow the same convention: what the README calls remoteToken should be local_token_contract_address (the Aleo token), and localToken should be remote_token_contract_address (the Ethereum token).

Recommendation. Update variable names to be consistent and clear from the Aleo bridge’s perspective:

• Rename local_depositor_address to local_recipient_address (offset 76)
• Consider swapping the naming of remote_token_contract_address and local_token_contract_address to match the perspective used for the recipient address

Client response. The client acknowledged the issue and already fixed the local_depositor_address vs local_recipient_address issue in commit 2fbb807 and is considering renaming other variables for clarity.

Description. Some comments in the token contract do not accurately reflect the implementation:

Lines 99-100 - Initialize function comment. The initialize function comment states:

// Sets the block height window, the initial empty Merkle root,
// and initialize the freeze_list_last_index, freeze_list, and freeze_list_index with a ZERO_ADDRESS placeholder.

However, these operations are currently performed in the initialize function of sealance_freezelist_registry.leo and not here.

Line 648 - Transfer private to public comment. The transfer_private_to_public function comment states:

// A Credentials record is emitted for the sender

However, the function returns (ComplianceRecord, Token, Future) (no Credentials record).

Lines 471, 552 - Inconsistent parameter naming. In transfer_from_public and transfer_from_public_to_private, the parameter is named owner in the transition signature but referred to as sender in the finalize functions. While not a logical issue, unifying the naming would improve readability.

Burn and mint comments. Both functions have comments stating:

// Can be called by the admin, a minter (burner), or a supply manager.

However, the implementations only check MINTER_ROLE and BURNER_ROLE. No admin or supply_manager constants exist in the code.

Recommendation. Update comments to accurately reflect the implementation, or clarify the intended meaning where role composition is implied.

Client response. Acknowledged and fixed in PR #109.

Description. The constructor does not restrict who can deploy the first edition (number 0) of the contracts, despite comments suggesting otherwise.

In compliant_token_template.leo at line 57, a comment states:

// Only this address can deploy the program

referring to INITIAL_CONFIGURATION_ADDRESS. A similar comment appears in sealance_freezelist_registry.leo at line 14.

However, the constructor only enforces ownership restrictions for editions greater than 0:

async constructor() {
    if (self.edition > 0) {
        assert_eq(UPGRADE_ADDRESS, self.program_owner);
    }
}

This means any address can deploy edition 0. In the current upgrade.test.ts tests, edition 0 is deployed using the key corresponding to UPGRADE_ADDRESS, not the INITIAL_CONFIGURATION_ADDRESS. Different addresses, including the admin key, can also deploy edition 0.

The behavior for upgrades to editions > 0 is correct and properly restricted to UPGRADE_ADDRESS as verified by tests.

Impact. A malicious actor could front-run the legitimate deployment of edition 0 and deploy it under their own address. While operational procedures should verify the logic and owner of edition 0 anyway to prevent name squatting, allowing unrestricted deployment of edition 0 could enable the legitimate program logic to be owned by an incorrect address, which might be harder to detect than obvious name squatting.

Recommendation. Either restrict edition 0 deployment to INITIAL_CONFIGURATION_ADDRESS as suggested by the comment, or to UPGRADE_ADDRESS if that is the intended deployer. Alternatively, update the comments to accurately reflect that edition 0 deployment is unrestricted.

Client response. Acknowledged as a comment typo. The team discussed adding a role restriction to edition 0 but decided this is not critical. They would also like to keep the initial deployment actor not fixed, such that the deployer is independent from the initializer and the upgrade roles. Comment typo fixed in PR #106.

Description. The verify_non_inclusion function calculates the depth from two Merkle proofs (depth1 and depth2) and asserts that the roots match, but does not validate that the depths are equal.

The function computes both depths:

let (root1, depth1): (field, u32) = calculate_root_depth_siblings(merkle_proofs[0u32]);
let (root2, depth2): (field, u32) = calculate_root_depth_siblings(merkle_proofs[1u32]);

// Ensure the roots from the merkle proofs are the same
assert_eq(root1, root2);

However, depth2 is calculated but never used in subsequent validation. The function only checks that root1 == root2, not that depth1 == depth2.

This means an attacker could potentially provide two proofs with the same root but different tree depths. While finding such proofs is very unlikely, the check would be straightforward to add.

Impact. By construction, two valid sibling proofs for adjacent leaves in the same tree should always have matching depths. The missing depth comparison creates a theoretical validation gap, though exploiting this would be extremely difficult in practice.

Recommendation. Add a depth equality check after the root comparison:

assert_eq(root1, root2);
assert_eq(depth1, depth2);

Client response. Client acknowledged this issue and fixed it in PR #110.