Argent Account & Multisig for StarkNet

1 Executive Summary

This report presents the results of our engagement with Argent to review Argent Account and Argent Multisig for StarkNet.

The review was conducted from May 29 to June 30, 2023, by Heiko Fisch and George Kobakhidze. A total of 8 person-weeks were spent.

Argent is a provider of wallets in the Ethereum ecosystem, including its L2s. This audit focuses on their smart contract wallet offering, Argent Account, and their multisig, Argent Multisig, as well as the auxiliary libraries used for these. Specifically, the code to be reviewed is for the StarkNet ecosystem, which is currently undergoing a lot of fundamental changes due to the release of Cairo 1.0 and compatible StarkNet contracts. Therefore, these are StarkNet contracts written in the Cairo 1.0 programming language.

We found the code exceptionally well-written, -documented, and extensively tested. As the StarkNet/Cairo ecosystem is evolving rapidly and Argent is trying to keep up with these changes, we accepted several code updates during the engagement. The findings described below refer to different versions of the codebase. They are all fixed in the final version d5b365b93f7342421cd4e7775998c91acb2d1a20.

Users of Argent Account should be aware that the time window to react to a malicious Guardian’s takeover attempt is only one week and should take appropriate precautions.

2 Scope

Our review initially focused on the commit hash 5be99f790267108e315022b60b00d9608093f514. Due to the changing state of the Cairo 1.0 programming language, there were several PRs and commits incorporated into this audit with the major ones being:

1. PR #159 to address a non-whitelisted function.
2. PR #160 to upgrade to Cairo v1.1.0.
3. PR #174 to be compliant with SNIP-5 spec.
4. PR #175 to migrate to the syntax required by the next Cairo compiler version (v2.0.0) that will become available on Starknet v0.12.0.
5. PR #182 to switch to the latest version of the IAccount interface.

After addressing found issues, the final commit for the repository was d5b365b93f7342421cd4e7775998c91acb2d1a20.

The list of files in scope can be found in the Appendix with file hashes related to the latest commit.

Backwards-compatibility with the Cairo 0 versions was not in scope for this engagement.

2.1 Objectives

Together with the Argent team, we identified the following priorities for our review:

1. Correctness of the implementation, consistent with the intended functionality and without unintended edge cases.
2. Identify known vulnerabilities particular to smart contract systems, as outlined in our Smart Contract Best Practices, and the Smart Contract Weakness Classification Registry as they would translate to Cairo 1.0 StarkNet contracts.
3. Address key risks:

• Assets (ERC20, ERC721, etc) owned by the account cannot be stolen or frozen by a malicious party.
• The account can never be in a bricked state.
• The impact of a malicious guardian is limited.

4. Verify invariants:

• The account has always an owner (signer is never 0).
• The guardian key can never be 0 when the guardian_backup is set.

3 System Overview

The two systems that this audit was focused on – Argent Account and Argent Multisig – can be assessed in isolation from one another. While their primary use case of providing a self-custodial smart contract wallet solution is shared, the details and target users are different.

3.1 Argent Account

Argent Account is a smart contract wallet intended to be used by individuals. This wallet allows users to sign their everyday transactions for things like asset transfers, smart contract interactions and so on. There is also a new concept of a Guardian, an optional entity that helps users increase the security and recoverability of their wallet. To achieve the increased security goals, Argent Accounts employ a few more layers of logical separation than what is usually found in wallets for transaction signing, ownership, and signer hierarchy.

To execute any transaction on behalf of the Argent Account, the account checks to see if enough valid signatures are present with the transaction. This always includes the owner signature, which is the signature created from the private key that corresponds to the address referred to as the owner in the Argent Account, and could also require a Guardian or the backup Guardian signature as well. In fact, if a Guardian is defined, most transactions on behalf of the Argent Account would require for the Guardian signature to be there. Guardians are third parties typically in the form of an off-chain monitoring service with a private key that would check if the transaction submitted by the user looks suspicious, and, in the case that it is, wouldn’t sign the transaction, preventing it from being executed on behalf of the Argent Account. This is done to offer a fail-safe layer to the users so they don’t accidentally sign something malicious or, for example, provide a monetary input greater than what the user has configured with the Guardian. There is also the concept of a “Backup Guardian”, which would have exactly the same privileges as the primary Guardian and exists to provide greater service availability to the user in case the first Guardian goes offline. It is important to note that most transactions need to be signed by both the owner and the Guardian, assuming the latter is defined; neither can execute arbitrary transactions alone. The exceptions would be the abilities to escape (and disable) the Guardian by the owner and escape the owner by the Guardian. It is critical to note that in these escape scenarios, the owner takes precedence. More on that below.

The ownership of the account itself in Argent Accounts is transferrable. If a user would like to change the private keys that have owner access to the Argent Account, they may do so by calling the change_owner function on their Argent wallet. This, however, requires a signature of the initial owner itself, which could be a problem if the ownership transfer needs to happen because the original private key is lost. However, the aforementioned Guardian entity, should it be enabled and defined, may also facilitate ownership transfer by itself via the escape_owner method. This functionality initiates a process, with the current length set to 7 days, at the end of which the ownership of the account may be transferred to the account the Guardian has defined. Should the original owner keys be found, this process can be overridden at any point by the original owner. In fact, the owner themselves may also call the change_guardian function to change or disable the Guardian, if they feel like they don’t need or want the Guardian service, though this would require the sign-off of the Guardian too. If the Guardian is compromised, meaning it wouldn’t sign its ownership away willingly, the owner may initiate the escape_guardian process, which acts similarly as the owner escape except that the Guardian can’t override or cancel this escape.

Finally, since Argent Accounts are smart contract wallets, they also allow for outside services to process transactions on behalf of the account should they have the necessary signatures. This is done through the execute_from_outside method. A feature like this would enable use cases such as sponsored transactions, gas subsidized UX and so on.

By spreading the ability to optionally sign and check transactions with multiple entities with different signing powers, the Argent Accounts allow for a safer self-custody experience than regular wallets. However, there are additional trust assumptions with respect to the Guardians and the escape period (currently a week) that do require strong consideration from users. For example, the user would need to make sure they monitor their wallet and its transactions to make sure that in case a Guardian is compromised and tries to escape the owner, they act swiftly within the security period and cancel the malicious ownership escape.

3.2 Argent Multisig

The Argent Multisig provides a typical feature implementation in Cairo 1.0 of an account that requires M-N signatures to process a transaction.

The contract contains typical multisig management functionality such as adding signers, removing signers, replacing one signer with another, changing thresholds for signature processing and so on. All the necessary invariants are enforced, such as ensuring that a 0 signer can’t be added and that the threshold isn’t greater than the total number of signers available. For efficiency purposes, the number of signers that can be registered is limited to 32, so users should be aware of this limit.

Like with the Argent Account, the Argent Multisig also allows third parties to execute transactions on behalf of the multisig via the execute_from_outside method, provided the third party has the necessary signatures.

3.3 Overall

Both of the above contracts utilize check_ecdsa_signature from the Cairo corelib::ecdsa library to verify the signatures against provided hashes. They do not utilize smart contract signatures at this moment.

Finally, both contract systems may be upgraded by their relevant signatory entities (owners and Guardians for the Argent Account, and signers for the Argent Multisig). The upgrade logic is utilizing Cairo 1.0 methodology with the new replace_class_syscall function along with custom logic as needed for each contract, such as verifying that the new class (implementation contract) supports relevant interfaces.

4 Security Specification

This section describes, from a security perspective, the expected behavior of the system under audit. It is not a substitute for documentation. The purpose of this section is to identify specific security properties that were validated by the audit team.

4.1 Actors

The relevant actors are listed below with their respective abilities:

• Argent Account – Owners. The primary user of the accounts. In the vast majority of cases, they initiate and sign off on the transactions. They also hold the most power over the account; should their access be compromised by a malicious actor, the account would be in trouble. In the case of a loss of access, Guardians may help.
• Argent Account – Guardians & Backup Guardians. Third parties that allow for fail-safe mechanisms for the Argent Account. These entities are optionally setup in Argent Accounts, and may be used to filter and sign off on all the transactions made by the Argent Account, as well as initiate ownership transfers if private keys to the primary owner are lost.
• Argent Multisig – Signers. The primary and only users of the Argent Multisig. These entities all hold the same power on the multisig, as defined throughout the multisig’s lifecycle. At least N signatures (the threshold) of M total number of signers is required to process any transaction on behalf of the Argent Multisig.

4.2 Trust Model

In any system, it’s important to identify what trust is expected/required between various actors. For this audit, we established the following trust model:

• Argent Account – Owners. As mentioned above, the owners are the primary users of Argent Accounts. As the name suggests, as the owner they have full control over the account. So, if the users have access to the private keys associated with the owner address, they don’t need to extend any trust assumptions for ownership.

• Argent Account – Guardians & Backup Guardians. Despite offering a safety layer to the Argent Accounts, Guardians and Backup Guardians are trusted to perform their job and not act maliciously, though the latter actions are quite limited. The Guardians do need to perform proper monitoring of transactions and act in accordance with the user agreement that they have made with the owner. For example, that could be checking for appropriate slippage limits set on swap transactions, ensuring daily limits of asset transfers aren’t exceeded and so on. On top of monitoring, the Guardians need to make sure they are available to sign off on transactions as well, otherwise the Argent Account wouldn’t be able to validate any transactions, and the owner would have to initiate a Guardian escape that would take a week.
  Finally, the Guardians are trusted not to be compromised by a malicious actor. If they are, they can perform a gas attack by spamming ownership escape. In StarkNet, gas for transactions is spent from the smart contract accounts that may have various ownership properties as opposed to public addresses directly derived from private keys. Therefore, a private key that has no coins for gas in their public address but is a signatory on a smart contract account may sign and execute a transaction that will spend gas costs from the account – in this case the Argent Account. Since it is possible for Guardians to initiate the escape owner transactions to start the escape process, they could spam this same transaction and waste assets stored in this account for gas. The damage would be limited, though, as the contract has limits on the maximum gas fee for escape transactions and on the number of escape attempts possible by Guardians. However, for a malicious Guardian only one ownership escape needs to go through to take over the account, and this would only take a week. If the owner falls ill or doesn’t have access to the internet or their account for just a week, a malicious Guardian could seize the account.

• Argent Multisig – Signers. Argent Multisig signers are the primary and only users of the multisig. All transactions require at least a threshold amount of signatures for them to be processed. As a result, all signers should be aware and trust at least M (total number of signers) - N (threshold of signers) + 1 other signers associated with the multisig to not sign malicious transactions.

5 Findings

Each issue has an assigned severity:

• Minor issues are subjective in nature. They are typically suggestions around best practices or readability. Code maintainers should use their own judgment as to whether to address such issues.
• Medium issues are objective in nature but are not security vulnerabilities. These should be addressed unless there is a clear reason not to.
• Major issues are security vulnerabilities that may not be directly exploitable or may require certain conditions in order to be exploited. All major issues should be addressed.
• Critical issues are directly exploitable security vulnerabilities that need to be fixed.

fn supports_interface(self: @ContractState, interface_id: felt252) -> bool {
    if interface_id == ERC165_IERC165_INTERFACE_ID {
        true
    } else if interface_id == ERC165_ACCOUNT_INTERFACE_ID {
        true
    } else if interface_id == ERC165_OUTSIDE_EXECUTION_INTERFACE_ID {
        true
    } else if interface_id == ERC165_IERC165_INTERFACE_ID_OLD {
        true
    } else if interface_id == ERC165_ACCOUNT_INTERFACE_ID_OLD_1 {
        true
    } else if interface_id == ERC165_ACCOUNT_INTERFACE_ID_OLD_2 {
        true
    } else {
        false
    }
}

const ERC165_ACCOUNT_INTERFACE_ID: felt252 =
    0x32a450d0828523e159d5faa1f8bc3c94c05c819aeb09ec5527cd8795b5b5067;

    fn __validate__(Array<Call>) -> felt252;
    fn __execute__(Array<Call>) -> Array<Span<felt252>>;
    fn is_valid_signature(felt252, Array<felt252>) -> bool;

// InterfaceID: 0x32a450d0828523e159d5faa1f8bc3c94c05c819aeb09ec5527cd8795b5b5067
trait IAccount<TContractState> {
    fn __validate__(ref self: TContractState, calls: Array<Call>) -> felt252;
    fn __execute__(ref self: TContractState, calls: Array<Call>) -> Array<Span<felt252>>;
    fn is_valid_signature(
        self: @TContractState, hash: felt252, signatures: Array<felt252>
    ) -> felt252;
}

fn is_valid_signature(
    self: @ContractState, hash: felt252, signatures: Array<felt252>
) -> felt252 {
    if self.is_valid_span_signature(hash, signatures.span()) {
        ERC1271_VALIDATED
    } else {
        0
    }
}

const ERC1271_VALIDATED: felt252 = 0x1626ba7e;

/// Interface ID: 0x3a8eb057036a72671e68e4bad061bbf5740d19351298b5e2960d72d76d34cb9
// get_outside_execution_message_hash is not part of the standard interface
#[starknet::interface]
trait IOutsideExecution<TContractState> {
    /// @notice This method allows anyone to submit a transaction on behalf of the account as long as they have the relevant signatures
    /// @param outside_execution The parameters of the transaction to execute
    /// @param signature A valid signature on the Eip712 message encoding of `outside_execution`
    /// @notice This method allows reentrancy. A call to `__execute__` or `execute_from_outside` can trigger another nested transaction to `execute_from_outside`.
    fn execute_from_outside(
        ref self: TContractState, outside_execution: OutsideExecution, signature: Array<felt252>
    ) -> Array<Span<felt252>>;

    /// Get the status of a given nonce, true if the nonce is available to use
    fn is_valid_outside_execution_nonce(self: @TContractState, nonce: felt252) -> bool;

    /// Get the message hash for some `OutsideExecution` following Eip712. Can be used to know what needs to be signed
    fn get_outside_execution_message_hash(
        self: @TContractState, outside_execution: OutsideExecution
    ) -> felt252;
}

const ERC165_OUTSIDE_EXECUTION_INTERFACE_ID: felt252 =
    0x3a8eb057036a72671e68e4bad061bbf5740d19351298b5e2960d72d76d34cb9;

starknet_keccak(
    'execute_from_outside(
        (ContractAddress,felt252,u64,u64,(@Array<(ContractAddress,felt252,Array<felt252>)>)),
        Array<felt252>
     )->Array<(@Array<felt252>)>'
) = 0x3c6e798a947887809ab7c506818dac2e3632acafa20cb51d2fff56b3577dc75

const CHANGE_OWNER_SELECTOR: felt252 =
    658036363289841962501247229249022783727527757834043681434485756469236076608; // starknet_keccak('change_owner')

fn test_selectors() {

fn execute_multicall(calls: Span<Call>) -> Array<Span<felt252>> {
    let mut result: Array<Span<felt252>> = ArrayTrait::new();
    let mut calls = calls;
    let mut idx = 0;
    loop {
        match calls.pop_front() {
            Option::Some(call) => {
                match call_contract_syscall(*call.to, *call.selector, call.calldata.span()) {
                    Result::Ok(mut retdata) => {
                        result.append(retdata);
                        idx = idx + 1;
                    },
                    Result::Err(revert_reason) => {
                        let mut data = ArrayTrait::new();
                        data.append('argent/multicall-failed');
                        data.append(idx);
                        data.append_all(revert_reason);
                        panic(data);
                    },
                }
            },
            Option::None(_) => {
                break ();
            },
        };
    };
    result
}

fn append_all(ref self: Array<T>, mut value: Array<T>) {
    loop {
        match value.pop_front() {
            Option::Some(reason) => {
                self.append(reason);
            },
            Option::None(()) => {
                break ();
            },
        };
    };
}

6 Recommendations

fn trigger_escape_owner(new_owner: felt252) {

/// Limit escape attempts by only one party
const MAX_ESCAPE_ATTEMPTS: u32 = 5;
/// Limits fee in escapes
const MAX_ESCAPE_MAX_FEE: u128 = 50000000000000000; // 0.05 ETH

Appendix 1 - Files in Scope

This audit covered the following files:

Note: The contracts/multisig/src/argent_multisig_storage.cairo file with the original SHA-1 hash 2702b447f5257a126b7bee3188f5fbf9bfc960d0, contracts/lib/src/erc1271.cairo file with the original SHA-1 hash 49dc11614809a07dc8362c0b8f927ff7da9454e2, and contracts/lib/src/span_serde.cairo file with the original SHA-1 hash a52d8526c5f3d5016d3893f88545e59728f12302 were removed from the final version of the audit repository.

Appendix 2 - Disclosure

ConsenSys Diligence (“CD”) typically receives compensation from one or more clients (the “Clients”) for performing the analysis contained in these reports (the “Reports”). The Reports may be distributed through other means, including via ConsenSys publications and other distributions.

The Reports are not an endorsement or indictment of any particular project or team, and the Reports do not guarantee the security of any particular project. This Report does not consider, and should not be interpreted as considering or having any bearing on, the potential economics of a token, token sale or any other product, service or other asset. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. No Report provides any warranty or representation to any Third-Party in any respect, including regarding the bugfree nature of code, the business model or proprietors of any such business model, and the legal compliance of any such business. No third party should rely on the Reports in any way, including for the purpose of making any decisions to buy or sell any token, product, service or other asset. Specifically, for the avoidance of doubt, this Report does not constitute investment advice, is not intended to be relied upon as investment advice, is not an endorsement of this project or team, and it is not a guarantee as to the absolute security of the project. CD owes no duty to any Third-Party by virtue of publishing these Reports.

PURPOSE OF REPORTS The Reports and the analysis described therein are created solely for Clients and published with their consent. The scope of our review is limited to a review of code and only the code we note as being within the scope of our review within this report. Any Solidity code itself presents unique and unquantifiable risks as the Solidity language itself remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond specified code that could present security risks. Cryptographic tokens are emergent technologies and carry with them high levels of technical risk and uncertainty. In some instances, we may perform penetration testing or infrastructure assessments depending on the scope of the particular engagement.

CD makes the Reports available to parties other than the Clients (i.e., “third parties”) – on its website. CD hopes that by making these analyses publicly available, it can help the blockchain ecosystem develop technical best practices in this rapidly evolving area of innovation.

LINKS TO OTHER WEB SITES FROM THIS WEB SITE You may, through hypertext or other computer links, gain access to web sites operated by persons other than ConsenSys and CD. Such hyperlinks are provided for your reference and convenience only, and are the exclusive responsibility of such web sites’ owners. You agree that ConsenSys and CD are not responsible for the content or operation of such Web sites, and that ConsenSys and CD shall have no liability to you or any other person or entity for the use of third party Web sites. Except as described below, a hyperlink from this web Site to another web site does not imply or mean that ConsenSys and CD endorses the content on that Web site or the operator or operations of that site. You are solely responsible for determining the extent to which you may use any content at any other web sites to which you link from the Reports. ConsenSys and CD assumes no responsibility for the use of third party software on the Web Site and shall have no liability whatsoever to any person or entity for the accuracy or completeness of any outcome generated by such software.

TIMELINESS OF CONTENT The content contained in the Reports is current as of the date appearing on the Report and is subject to change without notice. Unless indicated otherwise, by ConsenSys and CD.