├── .tool-versions ├── .gitignore ├── docker-compose.yml ├── .devcontainer.json ├── scripts └── multi-branch-commit.sh ├── LICENSE └── README.md /.tool-versions: -------------------------------------------------------------------------------- 1 | starknet-foundry 0.33.0 2 | scarb 2.8.5 3 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | node_modules 2 | 3 | target 4 | src 5 | 6 | .env 7 | .snfoundry_cache 8 | .DS_Store 9 | 10 | *.toml 11 | *.lock -------------------------------------------------------------------------------- /docker-compose.yml: -------------------------------------------------------------------------------- 1 | version: "3.8" 2 | services: 3 | test: 4 | image: starknetfoundation/starknet-dev:2.8.5 5 | volumes: 6 | - .:/app 7 | command: scarb test 8 | deploy: 9 | image: starknetfoundation/starknet-dev:2.8.5 10 | volumes: 11 | - .:/app 12 | command: npm run deploy 13 | -------------------------------------------------------------------------------- /.devcontainer.json: -------------------------------------------------------------------------------- 1 | { 2 | "name": "dev", 3 | "image": "starknetfoundation/starknet-dev:2.8.0", 4 | "customizations": { 5 | "vscode": { 6 | "extensions": [ 7 | "StarkWare.cairo1", 8 | "esbenp.prettier-vscode", 9 | "ms-azuretools.vscode-docker", 10 | "tamasfe.even-better-toml" 11 | ] 12 | } 13 | } 14 | } 15 | -------------------------------------------------------------------------------- /scripts/multi-branch-commit.sh: -------------------------------------------------------------------------------- 1 | #!/bin/bash 2 | 3 | # Prompt the user to enter the commit hash to cherry-pick 4 | read -p "Enter commit hash to cherry-pick: " COMMIT_HASH 5 | 6 | # List of branches to cherry-pick to 7 | BRANCHES=("step1" "step2" "step3" "step4" "step5" "step6" "step7" "step8" "step9" "step10" "step11" "step12" "step13" "step14" "step15-js") 8 | 9 | # Store the current branch to return to it later 10 | CURRENT_BRANCH=$(git rev-parse --abbrev-ref HEAD) 11 | 12 | # Loop through each branch and apply the cherry-pick 13 | for BRANCH in "${BRANCHES[@]}" 14 | do 15 | echo "Cherry-picking to $BRANCH" 16 | 17 | # Checkout the branch 18 | git checkout "$BRANCH" 19 | 20 | # Cherry-pick the commit 21 | git cherry-pick "$COMMIT_HASH" 22 | 23 | # Push the changes 24 | git push origin "$BRANCH" 25 | 26 | echo "Cherry-picked to $BRANCH successfully" 27 | done 28 | 29 | # Return to the original branch 30 | git checkout "$CURRENT_BRANCH" -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2023 starknet-edu 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Starknet's Counter Workshop 2 | 3 | In this workshop, you will learn how to create a simple Starknet smart contract, implement public functions, and events, access external contracts, and use OpenZeppelin's Ownable contract. 4 | 5 | After completing each step, run the associated script to verify it has been implemented correctly. 6 | 7 | Use the [Cairo book](https://book.cairo-lang.org/ch00-00-introduction.html) and the [Starknet docs](https://docs.starknet.io/documentation/) as a reference. 8 | 9 | ## Setup 10 | 11 | Clone this repository and choose whether you prefer using Docker to manage global dependencies or not in the following steps: 12 | 13 | ### Option 1: Without Docker 14 | 15 | 1. Install `asdf` ([instructions](https://asdf-vm.com/guide/getting-started.html)) 16 | 2. Install Scarb `2.8.5` via `asdf` ([instructions](https://docs.swmansion.com/scarb/download.html#install-via-asdf)) 17 | 3. Install Starknet Foundry `0.33.0` via `asdf` ([instructions](https://foundry-rs.github.io/starknet-foundry/getting-started/installation.html)) 18 | 4. Install Rust via ([instructions](https://www.rust-lang.org/tools/install)) 19 | 5. Install the Cairo 1.0 extension for VSCode ([marketplace](https://foundry-rs.github.io/starknet-foundry/getting-started/installation.html#installation-via-asdf)) 20 | 21 | ### Option 2: With Docker 22 | 23 | 4. Make sure Docker is installed and running 24 | 5. Install the Dev Containers extension for VSCode ([marketplace](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers)) 25 | 6. Launch an instance of VSCode inside of the container by going to **View -> Command Palette -> Dev Containers: Rebuild and Reopen in Container** 26 | 27 | > **Note:** All the commands shown from this point on will assume that you are using the integrated terminal of a VSCode instance running inside the container. If you want to run the tests on a different terminal you'll need to use the command `docker compose run test`. 28 | 29 | ## Step 1 30 | 31 | Switch to the `step1` branch to enable the verification tests: 32 | 33 | ```bash 34 | git checkout -b step1 origin/step1 35 | ``` 36 | 37 | ### Goal 38 | 39 | Initialize the project structure within the cloned repository by using the `Scarb` package manager and enable compilation of Starknet Contracts. 40 | 41 | ### Requirements 42 | 43 | - When initializing the project with `Scarb`, name the package as `workshop` 44 | - Create a new Cairo file under the `src` directory named `counter.cairo`, and add the following starting code: 45 | ```rust 46 | #[starknet::contract] 47 | pub mod counter_contract { 48 | #[storage] 49 | struct Storage {} 50 | } 51 | ``` 52 | - In the `lib.cairo` file remove the code and define the `counter` module 53 | 54 | ```rust 55 | pub mod counter; 56 | ``` 57 | 58 | > **Note:** Using any other name will disrupt upcoming steps. 59 | 60 | ### Verification 61 | 62 | When completed, build your project by running the following command: 63 | 64 | ```bash 65 | scarb build 66 | ``` 67 | 68 | ### Hints 69 | 70 | - Check out the `scarb init` command to initialize a project. In case you want to initialize the project with a specific name, you can use the `scarb init --name PACKAGE_NAME` command. 71 | - Refer to the [Cheat Sheet](https://docs.swmansion.com/scarb/docs/cheatsheet.html) for essential `Scarb` commands 72 | - To enable Starknet Contract compilation: 73 | - Target `starknet-contract`. 74 | - Specify the Cairo version in the `Scarb.toml`. 75 | - Learn more in the [Starknet Contract Target](https://docs.swmansion.com/scarb/docs/extensions/starknet/contract-target.html) documentation. 76 | 77 | ## Step 2 78 | 79 | Switch to the `step2` branch to enable the verification tests: 80 | 81 | ```bash 82 | git checkout -b step2 origin/step2 83 | ``` 84 | 85 | ### Goal 86 | 87 | Add `snforge` as a dependency within your `Scarb.toml` file to allow execution of tests with Starknet Foundry. 88 | 89 | ### Requirements 90 | 91 | - In your `Scarb.toml`, declare the `snforge_std` package as your project dependency and enable `casm` contract class generation 92 | - In your `Scarb.toml`, define a script named `test` to be able to run `snforge test` command 93 | - In your `Scarb.toml`, set your `edition` to target `2023_01` 94 | 95 | ### Verification 96 | 97 | When completed, execute the test suite to verify you've met all the requirements for this section. 98 | 99 | ```bash 100 | scarb test 101 | ``` 102 | 103 | ### Hints 104 | 105 | - Specify the version of Starknet Foundry that the project currently uses 106 | - Refer to the [Starknet Foundry Documention](https://foundry-rs.github.io/starknet-foundry/getting-started/first-steps.html#using-snforge-with-existing-scarb-projects) for more information. 107 | - Refer to the [Scarb Running Scripts Documentation](https://docs.swmansion.com/scarb/docs/reference/scripts.html#running-scripts) for more information. 108 | - `edition = "2024_07"` is a default configuration from Scarb that targets the July 2024 version of Cairo prelude. However, in our workshop we will work with `2023_01` for simplicity. Refer to the [Prelude Documentation](https://book.cairo-lang.org/appendix-04-cairo-prelude.html#prelude) for more information. 109 | 110 | ## Step 3 111 | 112 | Switch to the `step3` branch to enable the verification tests: 113 | 114 | ```bash 115 | git checkout -b step3 origin/step3 116 | ``` 117 | 118 | ### Goal 119 | 120 | Implement the constructor function to initialize an input number and store a variable named `counter` within the contract. 121 | 122 | ### Requirements 123 | 124 | - Store a variable named `counter` as `u32` type in the `Storage` struct. 125 | - Implement the constructor function that initializes the `counter` variable with a given input value. 126 | - The input variable of the constructor function should be named `initial_value` 127 | 128 | ### Verification 129 | 130 | When completed, execute the test suite to verify you've met all the requirements for this section. 131 | 132 | ```bash 133 | scarb test 134 | ``` 135 | 136 | ### Hints 137 | 138 | - Storage variables are the most common way to interact with your contract storage. You can read more about it in [Chapter 14 - Contract Storage](https://book.cairo-lang.org/ch14-01-00-contract-storage.html#contract-storage). 139 | - The constructor function is a special type of function that runs only once. You can read more about it in [Chapter 14 - Constructors](https://book.cairo-lang.org/ch14-02-contract-functions.html#1-constructors). 140 | 141 | ## Step 4 142 | 143 | Switch to the `step4` branch to enable the verification tests: 144 | 145 | ```bash 146 | git checkout -b step4 origin/step4 147 | ``` 148 | 149 | ### Goal 150 | 151 | Implement an interface for the contract which contains the `get_counter()` function. This function should return the value of the stored `counter` variable within the contract. 152 | 153 | ### Requirements 154 | 155 | - Implement an interface for a function named `get_counter()` which returns the value of the `counter` variable. 156 | - The `get_counter()` function must be within the contract's interface named `ICounter`. 157 | 158 | > **Note:** Any other given name to the contract's interface would break the test, be sure to have to correct name! 159 | 160 | ### Verification 161 | 162 | When completed, execute the test suite to verify you've met all the requirements for this section. 163 | 164 | ```bash 165 | scarb test 166 | ``` 167 | 168 | ### Hints 169 | 170 | - To create a contract interface, you will need to define a trait with the name `ICounter` (otherwise the tests will fail) and mark the trait with the `[starknet::interface]` attribute. You can read more about it in [Chapter 13 Anatomy of a Simple Contract](https://book.cairo-lang.org/ch13-02-anatomy-of-a-simple-contract.html#the-interface-the-contracts-blueprint). 171 | - The `get_counter()` function should only be able to read the state of the contract and not modify it. You can read more about it in [Chapter 14 - View Functions](https://book.cairo-lang.org/ch14-02-contract-functions.html#view-functions). 172 | 173 | ## Step 5 174 | 175 | Switch to the `step5` branch to enable the verification tests: 176 | 177 | ```bash 178 | git checkout -b step5 origin/step5 179 | ``` 180 | 181 | ### Goal 182 | 183 | Within the same interface created in the previous step, implement a function called `increase_counter()` that can increment the current value of the `counter` by `1` each time it is invoked. 184 | 185 | ### Requirements 186 | 187 | - Implement a function named `increase_counter()` which increments the `counter` value by `1`. 188 | - The `increase_counter()` function must be within the contract's interface named `ICounter`. 189 | 190 | ### Verification 191 | 192 | When completed, execute the test suite to verify you've met all the requirements for this section. 193 | 194 | ```bash 195 | scarb test 196 | ``` 197 | 198 | ### Hints 199 | 200 | - The `increase_counter()` function should be able to modify the state of the contract (also called an external function) and update the `counter` value within the `Storage`. You can read more about it in [Chapter 14 - External Functions](https://book.cairo-lang.org/ch14-02-contract-functions.html#external-functions). 201 | 202 | ## Step 6 203 | 204 | Switch to the `step6` branch to enable the verification tests: 205 | 206 | ```bash 207 | git checkout -b step6 origin/step6 208 | ``` 209 | 210 | ### Goal 211 | 212 | Implement an event named `CounterIncreased` that emits the current value of the `counter` variable, every time the value is increased. 213 | 214 | ### Requirements 215 | 216 | - Define a variant named `CounterIncreased` in the `Event` enum. 217 | - Defining the `value` variable within the `CounterIncrease` struct. 218 | - Emit the event in the `increase_counter()` function with the new value, once the `counter` value has been incremented. 219 | - Make them public to grant the test suite access (this includes the `Enum`, `struct` and `value`). 220 | 221 | ### Verification 222 | 223 | When completed, execute the test suite to verify you've met all the requirements for this section. 224 | 225 | ```bash 226 | scarb test 227 | ``` 228 | 229 | ### Hints 230 | 231 | - Events are custom data structures that are emitted by a contract. More information about Events can be found in [Chapter 14 - Contract Events](https://book.cairo-lang.org/ch14-03-contract-events.html). 232 | - To emit an event, you can use the `self.emit()` function as show [here](https://book.cairo-lang.org/ch14-03-contract-events.html#emitting-events). 233 | 234 | --- 235 | 236 | > **Note:** CHECKPOINT Reached ⛳️! Switch to the `step15-js` branch to get a deployment script based on starknet.js. 237 | > 238 | > ```bash 239 | > git checkout -b step15-js origin/step15-js 240 | > ``` 241 | 242 | --- 243 | 244 | ## Step 7 245 | 246 | Switch to the `step7` branch to enable the verification tests: 247 | 248 | ```bash 249 | git checkout -b step7 origin/step7 250 | ``` 251 | 252 | ### Goal 253 | 254 | In this step, we will introduce an external smart contract that acts as a kill switch for a specific function. Your task is to add the external `KillSwitch` contract as a dependency within your project. 255 | 256 | > **Note:** The `KillSwitch` contract can be found [here](https://github.com/starknet-edu/kill-switch). 257 | 258 | ### Requirements 259 | 260 | - In your `Scarb.toml` file, declare the `kill_switch` package as your project dependency under the `[dependencies]` section. 261 | - In your `Scarb.toml` file, to allow compilation of external contracts for Starknet Foundry, add the following line under the `[[target.starknet-contract]]` section. 262 | ```toml 263 | build-external-contracts = ["kill_switch::KillSwitch"] 264 | ``` 265 | 266 | ### Verification 267 | 268 | When completed, execute the test suite to verify you've met all the requirements for this section. 269 | 270 | ```bash 271 | scarb test 272 | ``` 273 | 274 | ### Hints 275 | 276 | - Refer to the [Scarb Managing Dependencies Documention](https://docs.swmansion.com/scarb/docs/guides/dependencies.html) for more information. 277 | - Refer to the [Compiling External Cotnract](https://docs.swmansion.com/scarb/docs/extensions/starknet/contract-target.html#compiling-external-contracts) for more information. 278 | 279 | ## Step 8 280 | 281 | Switch to the `step8` branch to enable the verification tests: 282 | 283 | ```bash 284 | git checkout -b step8 origin/step8 285 | ``` 286 | 287 | ### Goal 288 | 289 | Initialize the `KillSwitch` contract by storing the contract's address given as an input variable in the constructor function. 290 | 291 | ### Requirements 292 | 293 | 1. Store a variable named `kill_switch` as type `ContractAddress`. 294 | 2. Update the constructor function to initialize the `kill_switch` variable. 295 | 296 | ### Verification 297 | 298 | When completed, execute the test suite to verify you've met all the requirements for this section. 299 | 300 | ```bash 301 | scarb test 302 | ``` 303 | 304 | ### Hints 305 | 306 | - The task is similar to Step 3. Refer to it for more information. 307 | 308 | ## Step 9 309 | 310 | Switch to the `step9` branch to enable the verification tests: 311 | 312 | ```bash 313 | git checkout -b step9 origin/step9 314 | ``` 315 | 316 | ### Goal 317 | 318 | Implement the `KillSwitch` mechanism in the `increase_counter()` by calling the `is_active()` function from the `KillSwitch` contract. 319 | 320 | ### Requirements 321 | 322 | - If the function `is_active()` from the `KillSwitch` contract returns `false`, then allow the `increase_counter()` function to increment the value; otherwise, return without incrementing. 323 | 324 | > **Note:** Analyze the `KillSwitch` code to understand the interface and the contract structure from [here](https://github.com/starknet-edu/kill-switch/blob/master/src/lib.cairo). 325 | 326 | ### Verification 327 | 328 | When completed, execute the test suite to verify you've met all the requirements for this section. 329 | 330 | ```bash 331 | scarb test 332 | ``` 333 | 334 | ### Hints 335 | 336 | - You need to import the `Dispatcher` and `DispatcherTrait` of the `KillSwitch` contract. These dispatchers are automatically created and exported by the compiler. More information about Contract Dispatcher can be found in [Chapter 15.2 - Contract Dispatcher](https://book.cairo-lang.org/ch15-02-interacting-with-another-contract.html#calling-contracts-using-the-contract-dispatcher). 337 | - You can access the `is_active()` function from your `KillSwitch` contract dispatcher. 338 | - You can use an `if` expression to implement the mechanism. Refer to the [Cairo Book](https://book.cairo-lang.org/ch02-05-control-flow.html) to learn more. 339 | 340 | > **Note:** If you want to deploy the `Counter` contract, you can use the following deployed `KillSwitch` contract address. 341 | > 342 | > ## **Sepolia** 343 | > 344 | > Contract Address: `0x05f7151ea24624e12dde7e1307f9048073196644aa54d74a9c579a257214b542` 345 | > 346 | > - [Voyager](https://sepolia.voyager.online/contract/0x05f7151ea24624e12dde7e1307f9048073196644aa54d74a9c579a257214b542) 347 | > - [Starkscan](https://sepolia.starkscan.co/contract/0x05f7151ea24624e12dde7e1307f9048073196644aa54d74a9c579a257214b542) 348 | 349 | ## Step 10 350 | 351 | Switch to the `step10` branch to enable the verification tests: 352 | 353 | ```bash 354 | git checkout -b step10 origin/step10 355 | ``` 356 | 357 | ### Goal 358 | 359 | Protect the `increase_counter()` function by reverting the transaction if `KillSwitch` mechanism is enabled. 360 | 361 | ### Requirements 362 | 363 | - Create the condition to revert the transaction if the `KillSwith` contract is enabled 364 | - Revert the transaction with the following message `Kill Switch is active` 365 | 366 | ### Verification 367 | 368 | When completed, execute the test suite to verify you've met all the requirements for this section. 369 | 370 | ```bash 371 | scarb test 372 | ``` 373 | 374 | ### Hints 375 | 376 | - You can stop and revert a transaction with an error message using the `assert!()` macro. Refer to the [Cairo Book documentation](https://book.cairo-lang.org/ch10-01-how-to-write-tests.html#checking-results-with-the-assert-macro) to learn more. 377 | - You can replace the `if` expression with the `assert!()` macro instead. 378 | 379 | ## Step 11 380 | 381 | Switch to the `step11` branch to enable the verification tests: 382 | 383 | ```bash 384 | git checkout -b step11 origin/step11 385 | ``` 386 | 387 | ### Goal 388 | 389 | Add the external `OpenZeppelin` contracts as a dependency within your project. 390 | 391 | > **Note:** The `OpenZeppelin` contracts can be found [here](https://github.com/OpenZeppelin/cairo-contracts). 392 | 393 | ### Requirements 394 | 395 | - In your `Scarb.toml` file, declare the `openzeppelin` package as your project dependency under the `[dependencies]` section. 396 | 397 | ### Verification 398 | 399 | When completed, execute the test suite to verify you've met all the requirements for this section. 400 | 401 | ```bash 402 | $ scarb test 403 | ``` 404 | 405 | ### Hints 406 | 407 | - Specify the OpenZeppelin version as `0.19.0` in `Scarb.toml`. 408 | - Refer to the [OZ Contracts for Cairo Documention](https://docs.openzeppelin.com/contracts-cairo/0.19.0/) for more information. 409 | 410 | ## Step 12 411 | 412 | Switch to the `step12` branch to enable the verification tests: 413 | 414 | ```bash 415 | git checkout -b step12 origin/step12 416 | ``` 417 | 418 | ### Goal 419 | 420 | Initialize the `Ownable` component from the OpenZeppelin contracts. 421 | 422 | Before working on this step, make sure to read [Chapter 16.2: Composability and Components](https://book.cairo-lang.org/ch16-02-00-composability-and-components.html) and see how Components work. 423 | 424 | ### Requirements 425 | 426 | - Declare the component inside your contract using the `component!()` macro. 427 | - Add the path to the component's storage and events to the contract's `Storage` and `Event`. 428 | - Embed the component's logic into your contract by creating an instance of the component's generic implementation with a specific `ContractState`. 429 | 430 | ### Verification 431 | 432 | When completed, execute the test suite to verify you've met all the requirements for this section. 433 | 434 | ```bash 435 | scarb test 436 | ``` 437 | 438 | ### Hints 439 | 440 | - Refer to the [Using Components Inside a Contract](https://book.cairo-lang.org/ch16-02-00-composability-and-components.html#using-components-inside-a-contract) documentation to learn how to implement a component within a contract. 441 | 442 | ## Step 13 443 | 444 | Switch to the `step13` branch to enable the verification tests: 445 | 446 | ```bash 447 | git checkout -b step13 origin/step13 448 | ``` 449 | 450 | ### Goal 451 | 452 | Modify the constructor function to call the `initializer()` function within the `Ownable` component to initialize the owner. 453 | 454 | ### Requirements 455 | 456 | - The input variable of the constructor function should be named `initial_owner` 457 | 458 | ### Verification 459 | 460 | When completed, execute the test suite to verify you've met all the requirements for this section. 461 | 462 | ```bash 463 | scarb test 464 | ``` 465 | 466 | ### Hint 467 | 468 | - To call the `initializer()` function you can look at what functions `self.ownable` exposes. 469 | - Refer to the [Ownable Component](https://github.com/OpenZeppelin/cairo-contracts/blob/main/packages/access/src/ownable/ownable.cairo) to learn more about the accessible function. 470 | 471 | ## Step 14 472 | 473 | Switch to the `step14` branch to enable the verification tests 474 | : 475 | 476 | ```bash 477 | git checkout -b step14 origin/step14 478 | ``` 479 | 480 | ### Goal 481 | 482 | Protect the `increase_counter()` function so that only the owner of the contract can call this. 483 | 484 | ### Requirements 485 | 486 | - Use the `assert_only_owner()` function from the Ownable Component. 487 | 488 | ### Verification 489 | 490 | When completed, execute the test suite to verify you've met all the requirements for this section. 491 | 492 | ```bash 493 | scarb test 494 | ``` 495 | 496 | ### Hints 497 | 498 | - To call the `assert_only_owner()` function you can look at what functions `self.ownable` exposes. 499 | - Check out the `assert_only_owner()` function from the [Ownable Component](https://github.com/OpenZeppelin/cairo-contracts/blob/main/packages/access/src/ownable/ownable.cairo) for more information. 500 | 501 | ## Step 15 502 | 503 | Switch to the `step15-js` branch to get a deployment script based on [`starknet.js`](https://www.starknetjs.com/). 504 | 505 | ```bash 506 | git checkout -b step15-js origin/step15-js 507 | ``` 508 | 509 | ### Goal 510 | 511 | To deploy your account contract to Starknet's testnet using the `deploy.ts` script found in the `scripts` folder. 512 | 513 | ### Dependencies 514 | 515 | Run the command below from the project's root folder to install the deployment script dependencies. 516 | 517 | ```bash 518 | npm install 519 | ``` 520 | 521 | ### Deployer Wallet 522 | 523 | Create a wallet that the script can use to pay for the declaration of your account contract. 524 | 525 | ### Steps 526 | 527 | 1. Create a wallet on Starknet testnet using the [Argent X](https://www.argent.xyz/argent-x/) or [Braavos](https://braavos.app/) browser extension. 528 | 2. Fund the wallet by using the [Faucet](https://starknet-faucet.vercel.app/) or the [Bridge](https://sepolia.starkgate.starknet.io/). 529 | 3. Create a file in the project's root folder called `.env` 530 | 4. Export the private key of the funded wallet and paste it into the `.env` file using the key `DEPLOYER_PRIVATE_KEY`. 531 | 532 | ```bash 533 | DEPLOYER_PRIVATE_KEY= 534 | ``` 535 | 536 | 5. Export the public key of the funded wallet and paste it into the `.env` file using the key `DEPLOYER_ADDRESS` 537 | 538 | ```bash 539 | DEPLOYER_ADDRESS= 540 | ``` 541 | 542 | ### RPC Endpoint 543 | 544 | To successfully deploy the contract with the script on the Starknet Testnet, you will need to provide an RPC URL. For our workshop, we will use Blast's Public RPC Endpoint. 545 | 546 | Add the following line in your `.env` file: 547 | 548 | ```bash 549 | RPC_ENDPOINT=https://starknet-sepolia.public.blastapi.io/ 550 | ``` 551 | 552 | Refer to [Blast](https://blastapi.io/public-api/starknet) to learn more about their Starknet RPC Endpoints. 553 | 554 | ### Run the Script 555 | 556 | Run the script that will declare and deploy your smart contract on the Starknet Testnet and ensure that you adjust the constructor inputs in your `deploy.ts` file appropriately. 557 | 558 | > **Note:** If you are deploying the smart contract from the CHECKPOINT, in the `deploy.ts` file, you will only need the `initial_counter` in the `constructor` variable. Ensure that you remove or comment out the `kill_switch_address` and `initial_onwer` variables. 559 | > 560 | > Additionally, ensure that the variable names in the `deploy.ts` constructor are the same as in the `counter.cairo` constructor function. 561 | 562 | ```typescript 563 | const constructor = myCallData.compile("constructor", { 564 | initial_counter: 100, 565 | address: "0x05f7151ea24624e12dde7e1307f9048073196644aa54d74a9c579a257214b542", 566 | initial_owner: process.env.DEPLOYER_ADDRESS, 567 | }); 568 | ``` 569 | 570 | #### Steps 571 | 572 | 1. From the project's root folder run `npm run deploy` 573 | 2. Follow the instructions from the terminal 574 | 575 | If the script finishes successfully your smart contract is ready to be used on Starknet testnet. Congratulations! 576 | --------------------------------------------------------------------------------