The old way to deploy contracts on StarkNet involved sending a deploy transaction, which is now deprecated. This flow did not go through an account contract and thus had to be amended in a way that would only allow existing accounts to deploy and also pay fees for the deployment. In recent weeks we, alongside the community, developed new flows to deploy a contract or an account that does not rely on the deploy transaction:
DEPLOY_ACCOUNT transaction, which solves the problem of paying for deployment while not having an account. This involves deciding on the account type (that is, class_hash) you want to deploy, computing your would-be account address off-chain, and sending funds to this address. Once the address has enough funds to pay for the deployment, the user can send a DEPLOY_ACCOUNT transaction.In the coming days, we will stop supporting DEPLOY transactions, this document describes what needs to be done in order to transition to the new way of deployment.
<aside> 💡 This section refers to manual deployment of accounts. If you’re using a wallet application such as ArgentX/Braavos, simply follow the instructions on the app.
</aside>
The short tutorial below will use starknet.js to communicate with StarkNet. Other SDKs, such as starknet.py, offer similar functionality.
The first step is to decide on your account class (the contract class of which your account will be an instance of). For example, you can use OZ’s latest account implementation, which at the time of writing, can be found here.
Next, you need to fund your would-be account address. To figure out your account address, you can call this function (note to set deployerAddress to 0). You can then use the StarkNet Testnet Faucet to get some Testnet ETH sent to your address, this would allow paying for the deployment of the account. In order to make sure that the transfer took place, you can query your balance in the ETH ERC20 contract (call the balanceOf function with your address as the argument).
Now you are ready to send your DEPLOY_ACCOUNT transaction. This would involve using a signer. Note that every account may have a different signing logic. Open-Zeppelin’s account is based on the STARK-friendly ECDSA, which would be compatible with the default signer. You can now setup your account and call the deployAccount function.
<aside> 💡 Note that the account choice in the above flow is up to the user. It is not for the SDK to provide a specific account logic. Different tools work with different accounts. For example, the StarkNet CLI works with a slight modification of OpenZeppelin’s contract. Nile works with the latest version of the OpenZeppelin implementation. As a developer, you should find the environment which is most suitable for you.
</aside>
This section relies on having an account already set up with enough ETH to pay fees for both the class declaration and the transaction interacting with the UDC.
<aside> đź’ˇ Note that now, you must first declare your contract class and only then deploy a new instance of it.
</aside>
To send a declare transaction, you should first have the compiled JSON of the contract’s Cairo code.
In starknet.js, you can send a declare transaction via the Account class declare function. Note that the class hash computation functionality doesn’t exist in starknet.js currently (this will change in the future, with more efficient js implementation for StarkNet’s native cryptography). In starknet.py the computation of the class hash is done under the hood upon declaring.
<aside> đź’ˇ You can also use external tools to compute the class hash. For example, starkli and nile
</aside>
We can now move on to the actual deployment via the universal deployer contract. The UDC address is the same across all networks, you can inspect it here. As you can see, it has a single external method, deployContract, which expects:
classHash - the class of the contract you want to deploy