Transaction V3

This includes the multisig (multisig-0.1.1) and also the the regular account (account-0.3.1)

Notable changes in the account since the previous version:

• Support for Transactions V3 that allows paying the transaction fees in STRK token
• Updated compiler version to v2.4.3
• New Audit by Consensys Diligence

Classhashes

Can be found here for the account and here for the multisig

Cairo 1

First release using Cairo 1.
This includes the multisig (multisig-0.1.0) and also the the regular account (account-0.3.0)

Notable changes in the account since v0.2.3.1:

• Renamed methods and events to follow Cairo 1 conventions. We also renamed signer to owner to make the role clearer
• Events also include more keys for indexing
• Implements the new SNIP5
• Recovery changes: For extra safety now you need to specify the new signer when triggering the escape. Escapes will automatically expire after a week if not completed
• Outside execution: There is a new method that allows metatransactions by leveraging offchain signatures
• This account can only declare Cairo 1 contracts, not allowed to declare Cairo 0 code

Multisig

Bringing multisig to Starknet. Read more about our new account here

Improving readability and coverage

What's Changed

• move version check by @juniset in #76
• Adding method descriptions and increasing test coverage by @juniset in #81

Declared class hash

• ArgentAccount.cairo: 0x033434ad846cdd5f23eb73ff09fe6fddd568284a0fb7d1be20ee482f044dabe2
• ArgentPluginAccount: 0x036360b6dc469deb485cf633371b3e8a0a1497dd7f816337d1bd6decd6411296

Full Changelog: v0.2.3...v0.2.3.1

Support for Cairo 0.10

Summary

Adding support for Cairo 0.10.
Adding experimental plugin account with support for session keys.

What's Changed

• Code consistency for list and list_len param order by @CremaFR in #47
• starknet_version in blockInfo for Cairo 0.9.1 by @CremaFR in #52
• fix by @janek26 in #55
• support for plugins by @juniset in #56
• support for Cairo 0.10.0 by @juniset in #58
• use camel case for external methods by @juniset in #59
• accept transaction with version = QUERY for simulation by @juniset in #63
• Update setup guide by @sgc-code in #65
• add validate_deploy to IAccount by @juniset in #61
• upgrade and call by @juniset in #64
• Upgrade and call improvements by @sgc-code in #66
• Fix validate deploy by using raw data by @sgc-code in #69
• Better typing for calls by @sgc-code in #70
• add nile-coverage plugin by @juniset in #71
• Release 0.2.3 by @sgc-code in #72

Declared class hash

• ArgentAccount.cairo: 0x01a7820094feaf82d53f53f214b81292d717e7bb9a92bb2488092cd306f3993f
• ArgentPluginAccount: 0x00ebe4b44d154bc07eacad202ee19757cdc73e7d4c672bc20d9031450c6db3ad

New Contributors

• @sgc-code made their first contribution in #65

Full Changelog: v0.2.2...v0.2.3

Support for Cairo 0.9

Summary

Adding support for Cairo 0.9.

What's Changed

• Preliminary audit report by @juniset in #40
• Use common.bool true and false by @pscott in #42
• Add return value to is_valid_signature by @pscott in #41
• Prevents Account reentrant signature reutilization by @juniset in #44
• Upgrade to Cairo v0.9.0 by @juniset in #45
• Audit report 16/05/2022 by @juniset in #46

New Contributors

• @pscott made their first contribution in #42

Full Changelog: v0.2.1...v0.2.2

Using `tx_hash` for transaction signing

Summary

This minor release updates to Cairo 0.8.1 which now exposes the transaction hash as part of the tx_info object. Following that change, it updates the ArgentAccount contract to use the transaction hash in the signature verification.

What's Changed

• Use transaction hash for signing by @juniset in #34
• Fix imports for 0.8.1 by @juniset in #36
• Removed unused import on test by @CremaFR in #38

New Contributors

• @CremaFR made their first contribution in #38

Full Changelog: v0.2.0...v0.2.1

Multicall and Proxy

Summary

This second release makes the account upgradable by implementing the proxy pattern. The account is a Proxy.cairo contract delegating all calls to an ArgentAccount.cairo implementation. This should enable users to keep their accounts while StarkNet evolves towards production.

In addition, ArgentAccount implements the new IAccount interface where the entry point is renamed __execute__ and the input is an array of calls that are executed in sequence. In addition, the hash of the transaction is updated to support multicalls and the new max_fee and version parameters introduced in Cairo 0.7.1.

To separate accounts from other contracts on StarkNet the ArgentAccount now implements EIP165 with the interface ID of 0xf10dbd44.

What's Changed

• feat: add struct hash by @janek26 in #19
• Cairo/v0.6.2 by @juniset in #20
• Prepare for account abstraction by @juniset in #21
• Add tests for backup guardian by @gergold in #22
• Feature: get_block_timestamp by @gergold in #23
• emit cairo events by @gergold in #25
• multicall by @juniset in #26
• error message by @juniset in #27
• Upgradable proxy and 0.7.1 by @juniset in #24
• Clean multicall by @juniset in #29
• Clean after multicall by @juniset in #30
• add account_upgrade and transaction_executed events by @juniset in #32

New Contributors

• @janek26 made their first contribution in #19
• @gergold made their first contribution in #22

Full Changelog: v0.1.0...v0.2.0

Mainnet Launch

This is the first release of the ArgentAccount to support the launch of StarNet to mainnet. StarkNet is still in alpha, so is the code of this release. In particular the ArgentAccount contract has not been audited yet and should not be used to store significant value.

The account is a 2-of-2 custom multisig where the signer key is typically stored on the user's phone and the guardian is an external contract that can validate the signatures of one or more keys. The guardian acts both as a co-validator for typical operations of the wallet, and as the trusted actor that can recover the wallet in case the signer key is lost or compromised.

Normal operations of the wallet (execute, change_signer, change_guardian, cancel_escape) require the approval of both parties to be executed.

Each party alone can trigger the escape mode (a.k.a. recovery) on the wallet if the other party is not cooperating or lost. An escape takes 7 days before being active, after which the non-cooperating party can be replaced. The wallet is always asymmetric in favor of one of the party depending on the weight of the guardian. The favoured party can always override an escape triggered by the other party.

A triggered escape can always be cancelled with the approval of both parties.

The account can be operated without a guardian. In that case it behaves exactly as the account defined in https://github.com/OpenZeppelin/cairo-contracts.