-
-
-
-### Testing `unlockTime`
-
-Next, you include test cases after the `before` function.
-
-The first test case should verify that the `unlockTime` variable is correct.
-
-Reveal code
- -Start with the value locked, however you must set up a `before` function, which will run before each test case. - -Then, include some new imports and variables: - -```tsx -import { expect } from 'chai'; -import { ethers } from 'hardhat'; - -// A helper utility to get the timestamp. -import { time } from '@nomicfoundation/hardhat-network-helpers'; - -// We import this type to have our signers typed. -import { SignerWithAddress } from '@nomicfoundation/hardhat-ethers/signers'; - -// Types from typechain -import { Lock__factory, Lock } from '../typechain-types'; - -describe('Lock', function () { - // This represents the time in the future we expect to release the funds locked. - const UNLOCK_TIME = 10000; - - // The amount of ether we plan to lock. - const VALUE_LOCKED = ethers.parseEther('0.01'); - - // This variable will store the last block timestamp. - let lastBlockTimeStamp: number; - - // Typechain allow us to type an instance of the Lock contract. - let lockInstance: Lock; - - // This is the Signer of the owner. - let ownerSigner: SignerWithAddress; - - // A non owner signed is useful to test non owner transactions. - let otherUserSigner: SignerWithAddress; - - before(async () => { - // We get the latest block.timestamp using the latest function of time. - lastBlockTimeStamp = await time.latest(); - - // Hardhat provide us with some sample signers that simulate Ethereum accounts. - const signers = await ethers.getSigners(); - - // We simply assign the first signer to ownerSigner - ownerSigner = signers[0]; - - // We assign the second signer to otherUserSigner - otherUserSigner = signers[1]; - - // We estimate unlockTime to be the last time stamp plus UNLOCK_TIME - const unlockTime = lastBlockTimeStamp + UNLOCK_TIME; - - // Notice how we use the Lock__factory and pass a signer. Then we deploy by passing the unlockTime and the amount of ether we will lock. - lockInstance = await new Lock__factory(ownerSigner).deploy(unlockTime, { - value: VALUE_LOCKED, - }); - }); -}); -``` - -
-
-
-
-### Testing Ether balance
-
-In order to get the balance of your `Lock` contract, you simply call `ethers.provider.getBalance`.
-
-Create a new test case:
-
-Reveal code
- -```tsx -it('should get the unlockTime value', async () => { - // we get the value from the contract - const unlockTime = await lockInstance.unlockTime(); - - // We assert against the - expect(unlockTime).to.equal(lastBlockTimeStamp + UNLOCK_TIME); -}); -``` - -Notice how autocomplete appears after entering `lockInstance`: - - - - - -You can simply run `npx hardhat test` and then get: - -``` - Lock - ✔ should get the unlockTime value - - 1 passing (1s) -``` - -
-
-
-Reveal code
- -```tsx -it('should have the right ether balance', async () => { - // Get the Lock contract address - const lockInstanceAddress = await lockInstance.getAddress(); - - // Get the balance using ethers.provider.getBalance - const contractBalance = await ethers.provider.getBalance(lockInstanceAddress); - - // We assert the balance against the VALUE_LOCKED we initially sent - expect(contractBalance).to.equal(VALUE_LOCKED); -}); -``` - -- -Then, run `npx hardhat test` and you should get: - -``` - Lock - ✔ should get the unlockTime value - ✔ should have the right ether balance - - 2 passing (1s) -``` - -### Testing `owner` - -Similar to the previous test cases, you can verify that the owner is correct. - -
-
-
-Reveal code
- -```tsx -it('should have the right owner', async () => { - // Notice ownerSigned has an address property - expect(await lockInstance.owner()).to.equal(ownerSigner.address); -}); -``` - -- -Then, run `npx hardhat test` and you should get: - -``` - Lock - ✔ should get the unlockTime value - ✔ should have the right ether balance - ✔ should have the right owner - - 3 passing (1s) -``` - -### Testing withdraw - -Testing withdrawal is more complex because you need to assert certain conditions, such as: - -- The owner cannot withdraw before the unlock time. -- Only the owner can withdraw. -- The withdraw function works as expected. - -Hardhat allow you to test reverts with a set of custom matchers. - -For example, the following code checks that an attempt to call the function `withdraw` reverts with a particular message: - -```tsx -it('shouldn"t allow to withdraw before unlock time', async () => { - await expect(lockInstance.withdraw()).to.be.revertedWith("You can't withdraw yet"); -}); -``` - -In addition, Hardhat also allows you to manipulate the time of the environment where the tests are executed. You can think of it as a Blockchain that is running before the tests and then the tests are executed against it. - -You can modify `the block.timestamp` by using the time helper: - -```tsx -it('shouldn"t allow to withdraw a non owner', async () => { - const newLastBlockTimeStamp = await time.latest(); - - // We set the next block time stamp using this helper. - // We assign a value further in the future. - await time.setNextBlockTimestamp(newLastBlockTimeStamp + UNLOCK_TIME); - - // Then we try to withdraw using other user signer. Notice the .connect function that is useful - // to create and instance but have the msg.sender as the new signer. - const newInstanceUsingAnotherSigner = lockInstance.connect(otherUserSigner); - - // We attempt to withdraw, but since the sender is not the owner, it will revert. - await expect(newInstanceUsingAnotherSigner.withdraw()).to.be.revertedWith("You aren't the owner"); -}); -``` - -Finally, test that the owner can withdraw. You can manipulate the time similarly to the previous test case but you won't change the signer and will assert the new balances. - -
-
-
-
-Reveal code
- -```tsx -it('should allow to withdraw an owner', async () => { - const balanceBefore = await ethers.provider.getBalance(await lockInstance.getAddress()); - - // Its value will be the one we lock at deployment time. - expect(balanceBefore).to.equal(VALUE_LOCKED); - - const newLastBlockTimeStamp = await time.latest(); - - // We increase time - await time.setNextBlockTimestamp(newLastBlockTimeStamp + UNLOCK_TIME); - - // Attempt to withdraw - await lockInstance.withdraw(); - - // Get new balance and assert that is 0 - const balanceAfter = await ethers.provider.getBalance(await lockInstance.getAddress()); - expect(balanceAfter).to.equal(0); -}); -``` - -- -You can then run `npx hardhat test` and you should get: - -``` - Lock - ✔ should get the unlockTime value - ✔ should have the right ether balance - ✔ should have the right owner - ✔ shouldn"t allow to withdraw before unlock time (51ms) - ✔ shouldn"t allow to withdraw a non owner - ✔ should allow to withdraw an owner - - 6 passing (2s) -``` - -## Conclusion - -In this lesson, you've learned how to test smart contracts using Hardhat and Typechain. - ---- - -## See also - -[Solidity Docs](https://docs.soliditylang.org/en/v0.8.17/) -[Remix Project]: https://remix-project.org/ -[Hardhat]: https://hardhat.org/ diff --git a/docs/learn/hardhat/hardhat-testing/testing-overview-vid.mdx b/docs/learn/hardhat/hardhat-testing/testing-overview-vid.mdx deleted file mode 100644 index a4c4e6fa5..000000000 --- a/docs/learn/hardhat/hardhat-testing/testing-overview-vid.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Testing Overview -description: An overview of writing tests in Hardhat. -hide_table_of_contents: false ---- - -# Testing Overview - -import { Video } from '/snippets/VideoPlayer.mdx' - - diff --git a/docs/learn/hardhat/hardhat-testing/writing-tests-vid.mdx b/docs/learn/hardhat/hardhat-testing/writing-tests-vid.mdx deleted file mode 100644 index 4768b8e1e..000000000 --- a/docs/learn/hardhat/hardhat-testing/writing-tests-vid.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -title: Writing Tests -description: An introduction to writing tests. -hide_table_of_contents: false ---- - -# Writing Tests - -import { Video } from '/snippets/VideoPlayer.mdx' - - diff --git a/docs/learn/hardhat/hardhat-tools-and-testing/analyzing-test-coverage.mdx b/docs/learn/hardhat/hardhat-tools-and-testing/analyzing-test-coverage.mdx deleted file mode 100644 index 28ce7bd88..000000000 --- a/docs/learn/hardhat/hardhat-tools-and-testing/analyzing-test-coverage.mdx +++ /dev/null @@ -1,240 +0,0 @@ ---- -title: 'Hardhat: Analyzing the test coverage of smart contracts' -slug: /hardhat-test-coverage -description: A tutorial that teaches how to profile the test coverage of your smart contracts using Hardhat and the Solidity Coverage plugin. -author: Edson Alcala ---- - -# Analyzing the test coverage of smart contracts using Hardhat - -In this tutorial, you'll learn how to profile the test coverage of your smart contracts with [Hardhat] and the [Solidity Coverage] community plugin. - -## Objectives - -By the end of this tutorial, you should be able to: - -- Use the Solidity Coverage plugin to analyze the coverage of your test suite -- Increase the coverage of your test suite - -## Overview - -The Solidity Coverage plugin allows you to analyze and visualize the coverage of your smart contracts' test suite. This enables you to see what portions of your smart contract are being tested and what areas may have been overlooked. It's an indispensable plugin for developers seeking to fortify their testing practices and ensure robust smart contract functionality. - -## Setting up the Solidity Coverage plugin - -The Solidity Coverage plugin is integrated into the Hardhat toolbox package, which is installed by default when you use the `npx hardhat init` command. - -To install manually, run `npm install -D solidity-coverage`. - -Then, import `solidity-coverage` in `hardhat.config.ts`: - -```solidity -import "solidity-coverage" -``` - -Once the installation completes either manually or via the default Hardhat template, the task `coverage` becomes available via the `npx hardhat coverage` command. - -## My first test coverage - -Review the following contract and test suite (You'll recognize these if you completed the [Hardhat testing lesson] in our [Base Learn] series). - -Contract: - -```solidity -// SPDX-License-Identifier: UNLICENSED -pragma solidity ^0.8.19; - -contract Lock { - uint public unlockTime; - address payable public owner; - - event Withdrawal(uint amount, uint when); - - constructor(uint _unlockTime) payable { - require( - block.timestamp < _unlockTime, - "Unlock time should be in the future" - ); - - unlockTime = _unlockTime; - owner = payable(msg.sender); - } - - function withdraw() public { - require(block.timestamp >= unlockTime, "You can't withdraw yet"); - require(msg.sender == owner, "You aren't the owner"); - - emit Withdrawal(address(this).balance, block.timestamp); - - owner.transfer(address(this).balance); - } -} -``` - -`Lock.test.ts`: - -```solidity -import { expect } from "chai"; -import { ethers } from "hardhat"; -import { time } from "@nomicfoundation/hardhat-network-helpers"; -import { SignerWithAddress } from '@nomicfoundation/hardhat-ethers/signers' -import { Lock__factory, Lock} from '../typechain-types' - -describe("Lock Tests", function () { - const UNLOCK_TIME = 10000; - const VALUE_LOCKED = ethers.parseEther("0.01"); - - let lastBlockTimeStamp: number; - let lockInstance: Lock; - let ownerSigner: SignerWithAddress - let otherUserSigner: SignerWithAddress; - - before(async() => { - lastBlockTimeStamp = await time.latest() - const signers = await ethers.getSigners() - ownerSigner = signers[0] - otherUserSigner= signers[1] - - const unlockTime = lastBlockTimeStamp + UNLOCK_TIME; - - lockInstance = await new Lock__factory(ownerSigner).deploy(unlockTime, { - value: VALUE_LOCKED - }) - }) - - it('should get the unlockTime value', async() => { - const unlockTime = await lockInstance.unlockTime(); - - expect(unlockTime).to.equal(lastBlockTimeStamp + UNLOCK_TIME) - }) - - it('should have the right ether balance', async() => { - const lockInstanceAddress = await lockInstance.getAddress() - - const contractBalance = await ethers.provider.getBalance(lockInstanceAddress) - - expect(contractBalance).to.equal(VALUE_LOCKED) - }) - - it('should have the right owner', async()=> { - expect(await lockInstance.owner()).to.equal(ownerSigner.address) - }) - - it('should not allow to withdraw before unlock time', async()=> { - await expect(lockInstance.withdraw()).to.be.revertedWith("You can't withdraw yet") - }) - - it('should not allow to withdraw a non owner', async()=> { - const newLastBlockTimeStamp = await time.latest() - - await time.setNextBlockTimestamp(newLastBlockTimeStamp + UNLOCK_TIME) - - const newInstanceUsingAnotherSigner = lockInstance.connect(otherUserSigner) - - await expect(newInstanceUsingAnotherSigner.withdraw()).to.be.revertedWith("You aren't the owner") - }) - - it('should allow to withdraw a owner', async()=> { - const balanceBefore = await ethers.provider.getBalance(await lockInstance.getAddress()); - - expect(balanceBefore).to.equal(VALUE_LOCKED) - - const newLastBlockTimeStamp = await time.latest() - - await time.setNextBlockTimestamp(newLastBlockTimeStamp + UNLOCK_TIME) - - await lockInstance.withdraw(); - - const balanceAfter = await ethers.provider.getBalance(await lockInstance.getAddress()); - expect(balanceAfter).to.equal(0) - }) -}); -``` - -If you run `npx hardhat coverage`, you should get: - -```terminal - Lock Tests - ✔ should get the unlockTime value - ✔ should have the right ether balance - ✔ should have the right owner - ✔ shouldn't allow to withdraw before unlock time - ✔ shouldn't allow to withdraw a non owner - ✔ should allow to withdraw a owner - - 6 passing (195ms) - -------------|----------|----------|----------|----------|----------------| -File | % Stmts | % Branch | % Funcs | % Lines |Uncovered Lines | -------------|----------|----------|----------|----------|----------------| - contracts/ | 100 | 83.33 | 100 | 100 | | - Lock.sol | 100 | 83.33 | 100 | 100 | | -------------|----------|----------|----------|----------|----------------| -All files | 100 | 83.33 | 100 | 100 | | -------------|----------|----------|----------|----------|----------------| -``` - -Which then gives you a report of the test coverage of your test suite. Notice there is a new folder called `coverage`, which was generated by the `solidity-coverage` plugin. Inside the `coverage` folder there is a `index.html` file. Open it in a browser, you'll see a report similar to the following: - - - - - -## Increasing test coverage - -Although the coverage of the previous test suite is almost perfect, there is one missing branch when creating the contract. Because you have not tested the condition that the `_unlockTime` has to be greater than the `block.timestamp`: - -```solidity -require( - block.timestamp < _unlockTime, - "Unlock time should be in the future" - ); -``` - -In order to increase the coverage, include a new test with the following: - -```solidity - it('should verify the unlock time to be in the future', async () => { - const newLockInstance = new Lock__factory(ownerSigner).deploy(lastBlockTimeStamp, { - value: VALUE_LOCKED - }) - - await expect(newLockInstance).to.be.revertedWith("Unlock time should be in the future") - }) -``` - -Then, run `npx hardhat coverage` and you should get: - -```solidity - Lock Tests - ✔ should verify the unlock time to be in the future (39ms) - ✔ should get the unlockTime value - ✔ should have the right ether balance - ✔ should have the right owner - ✔ shouldn't allow to withdraw before unlock time - ✔ shouldn't allow to withdraw a non owner - ✔ should allow to withdraw a owner - - 7 passing (198ms) - -------------|----------|----------|----------|----------|----------------| -File | % Stmts | % Branch | % Funcs | % Lines |Uncovered Lines | -------------|----------|----------|----------|----------|----------------| - contracts/ | 100 | 100 | 100 | 100 | | - Lock.sol | 100 | 100 | 100 | 100 | | -------------|----------|----------|----------|----------|----------------| -All files | 100 | 100 | 100 | 100 | | -------------|----------|----------|----------|----------|----------------| -``` - -## Conclusion - -In this tutorial, you've learned how to profile and analyze the test coverage of your smart contracts' test suite. You learned how to visualize the coverage report and improve the coverage of the test suite by using the Solidity Coverage plugin. - -## See also - -[Hardhat]: https://hardhat.org/ -[Solidity Coverage]: https://github.com/sc-forks/solidity-coverage -[Hardhat testing lesson]: https://docs.base.org/base-learn/docs/hardhat-testing/hardhat-testing-sbs -[Base Learn]: https://base.org/learn - diff --git a/docs/learn/hardhat/hardhat-tools-and-testing/debugging-smart-contracts.mdx b/docs/learn/hardhat/hardhat-tools-and-testing/debugging-smart-contracts.mdx deleted file mode 100644 index 9d026404b..000000000 --- a/docs/learn/hardhat/hardhat-tools-and-testing/debugging-smart-contracts.mdx +++ /dev/null @@ -1,407 +0,0 @@ ---- -title: 'Hardhat: Debugging smart contracts' -slug: /hardhat-debugging -description: A tutorial that teaches how to debug your smart contracts using Hardhat. -author: Edson Alcala ---- - -# Debugging smart contracts using Hardhat - -In this tutorial, you'll learn how to debug your smart contracts using the built-in debugging capabilities of Hardhat. - -## Objectives - -By the end of this tutorial, you should be able to: - -- Use `console.log` to write debugging logs -- List common errors and their resolutions -- Determine if an error is a contract error or an error in the test - -## Overview - -Debugging smart contracts can be a challenging task, especially when dealing with decentralized applications and blockchain technology. Hardhat provides powerful tools to simplify the debugging process. - -In this tutorial, you will explore the essential debugging features offered by Hardhat and learn how to effectively identify and resolve common errors in your smart contracts. - -## Your first `console.log` - -One of the key features of Hardhat is the ability to use `console.log` for writing debugging logs in your smart contracts. In order to use it, you must include `hardhat/console.sol` in the contract you wish to debug. - -In the following contract `Lock.sol` for example, you include `hardhat/console.sol` by importing it and adding a few `console.log`s in the constructor with the text "Creating" and the Ether balance of the contract. This can help you not only with tracking that the contract was created successfully but also, more importantly, with the ability to include additional logs such as the balance of the contract after it was created: - -```solidity -// SPDX-License-Identifier: UNLICENSED -pragma solidity ^0.8.19; - -import "hardhat/console.sol"; - -contract Lock { - uint256 public unlockTime; - address payable public owner; - - constructor(uint _unlockTime) payable { - require( - block.timestamp < _unlockTime, - "Unlock time should be in the future" - ); - - unlockTime = _unlockTime; - owner = payable(msg.sender); - - console.log("Creating"); - console.log("Balance", address(this).balance); - } -} -``` - -In order to test it, you need to create a new file in the `test` folder called `Lock.test.ts` with the following content: - -```solidity -import { expect } from "chai"; -import { ethers } from "hardhat"; - -import { time } from "@nomicfoundation/hardhat-network-helpers"; -import { SignerWithAddress } from '@nomicfoundation/hardhat-ethers/signers' - -import { Lock__factory, Lock } from '../typechain-types' - -describe("Lock Tests", function () { - const UNLOCK_TIME = 10000; - const VALUE_LOCKED = ethers.parseEther("0.01"); - - let lastBlockTimeStamp: number; - let lockInstance: Lock; - let ownerSigner: SignerWithAddress - - before(async () => { - lastBlockTimeStamp = await time.latest() - - const signers = await ethers.getSigners() - ownerSigner = signers[0] - - lockInstance = await new Lock__factory().connect(ownerSigner).deploy(lastBlockTimeStamp + UNLOCK_TIME, { - value: VALUE_LOCKED - }) - }) - - it('should get the unlockTime value', async () => { - expect(await lockInstance.unlockTime()).to.equal(lastBlockTimeStamp + UNLOCK_TIME) - }) -}); -``` - -Notice that a single test is included in order to get proper logs. However, you're only interested in the creation process that happens in the `before` hook. Then, you can run: - -```bash -npx hardhat test -``` - -You should see the following in the terminal: - -```bash - Lock -Creating -Balance 10000000000000000 - ✔ should get the unlockTime value -``` - -The terminal shows the text "Creating" and the balance (which is 0.01 Ether) because during the creation, you are depositing Ether in the smart contract via the `value` property. - -### A note about `console.log` - -In the previous example, you used `console.log` to include some debugging logs. Be aware that the `console.log` version of Solidity is limited compared to the ones that are provided in other programming languages, where you can log almost anything. - -`Console.log` can be called with up to four parameters of the following types: - -- uint -- string -- bool -- address - -Hardhat includes other `console` functions, such as: - -- console.logInt(int i) -- console.logBytes(bytes memory b) -- console.logBytes1(bytes1 b) -- console.logBytes2(bytes2 b) -- ... -- console.logBytes32(bytes32 b) - -These log functions are handy when the type you intend to log doesn't fall within the default accepted types of `console.log`. For further details, refer to the official [console.log] documentation. - -## Identifying common errors - -While debugging your smart contracts, it's crucial to be familiar with common errors that can arise during development. Recognizing these errors and knowing how to resolve them is an important skill. - -In our [Base Learn] series of tutorials, we cover a few compile-time errors in [Error Triage]. Other errors, such as `reverts` or `index out of bounds errors` can be unexpected during the runtime of the smart contract. - -The following explores typical techniques to debug these types of errors. - -### Revert errors - -When a transaction fails due to a `require` or `revert` statement, you'll need to diagnose why the condition isn't met and then resolve it. Typically, this involves verifying input parameters, state variables, or contract conditions. - -The following is the `Lock.sol` contract with a require statement that validates that the parameter you are passing (`_unlockTime`) must be greater than the current `block.timestamp`. - -A simple solution to troubleshoot this error is to log the value of `block.timestamp` and `_unlockTime`, which will help you compare these values and then ensure that you are passing the correct ones: - -```solidity -// SPDX-License-Identifier: UNLICENSED -pragma solidity ^0.8.19; - -import "hardhat/console.sol"; - -contract Lock { - uint public unlockTime; - address payable public owner; - - // event Withdrawal(uint amount, uint when); - - constructor(uint _unlockTime) payable { - console.log("_unlockTime",_unlockTime); - console.log("block.timestamp",block.timestamp); - require( - block.timestamp < _unlockTime, - "Unlock time should be in the future" - ); - - unlockTime = _unlockTime; - owner = payable(msg.sender); - - console.log("Creating"); - console.log("Balance", address(this).balance); - } -} -``` - -When you run the tests with `npx hardhat test`, you'll then see the following: - -```bash -Lock Tests -_unlockTime 1697493891 -block.timestamp 1697483892 -Creating -Balance 10000000000000000 - ✔ should get the unlockTime value -``` - -You are now able to see the `block.timestamp` and the value you are passing, which makes it easier to detect the error. - -### Unintended behavior errors - -Unintended behavior errors occur when you introduce unexpected behavior into the codebase due to a misunderstanding in the way Solidity works. - -In the following example, `LockCreator` is a contract that allows anybody to deploy a `Lock.sol` instance. However, the `LockCreator` contains an error: the `createLock` functions are able to accept Ether to be locked but the amount sent is not being transferred to the `Lock` contract: - -```solidity -// SPDX-License-Identifier: UNLICENSED -pragma solidity ^0.8.19; - -import "hardhat/console.sol"; - -import {Lock} from "./Lock.sol"; - -contract LockCreator { - - Lock[] internal locks; - - // Example of bad code, do not use - function createLock(uint256 _unlockTime) external payable { - Lock newLock = new Lock(_unlockTime); - locks.push(newLock); - } -} -``` - -You can create a test file `LockCreator.test.ts` that can identify the error and then solve it: - -```solidity -import { ethers } from "hardhat"; - -import { time } from "@nomicfoundation/hardhat-network-helpers"; -import { SignerWithAddress } from '@nomicfoundation/hardhat-ethers/signers' - -import { LockCreator, LockCreator__factory } from '../typechain-types' - -describe("LockCreator Tests", function () { - const UNLOCK_TIME = 10000; - const VALUE_LOCKED = ethers.parseEther("0.01"); - - let lastBlockTimeStamp: number; - let lockInstance: LockCreator; - let ownerSigner: SignerWithAddress - - before(async () => { - const signers = await ethers.getSigners() - ownerSigner = signers[0] - - lockInstance = await new LockCreator__factory().connect(ownerSigner).deploy() - }) - - it('should create a lock', async () => { - lastBlockTimeStamp = await time.latest() - await lockInstance.createLock(lastBlockTimeStamp + UNLOCK_TIME, { - value: VALUE_LOCKED - }) - }) -}); -``` - -The following appears in the terminal where you can see the balance is `0`: - -```bash - LockCreator Tests -Creating -Balance 0 - ✔ should create a lock (318ms) -``` - -Although this issue can be avoided by adding more test cases with proper assertions, the re-transfer of Ether from the `LockCreator` was something you may have overlooked. - -The solution is to modify the `createLock` function with: - -```solidity -function createLock(uint256 _unlockTime) external payable { - Lock newLock = new Lock{ value: msg.value}(_unlockTime); - locks.push(newLock); -} -``` - -### Out-of-bounds errors - -Attempting to access arrays at an invalid position can also cause errors. - -If you wish to retrieve all the `Lock` contract instances being created in the previous example, you can make the `locks` array public. In order to illustrate this example, though, you can create a custom function called `getAllLocks`: - -```solidity -contract LockCreator { - // - // rest of the code.. - // - function getAllLocks() external view returns(Lock[] memory result) { - result = new Lock[](locks.length); - for(uint i = 0; i <= locks.length; i++){ - result[i] = locks[i]; - } - } -} -``` - -The function can be tested with the following test: - -```solidity -describe("LockCreator Tests", function () { - const UNLOCK_TIME = 10000; - const VALUE_LOCKED = ethers.parseEther("0.01"); - - let lastBlockTimeStamp: number; - let lockInstance: LockCreator; - let ownerSigner: SignerWithAddress - - before(async () => { - const signers = await ethers.getSigners() - ownerSigner = signers[0] - - lockInstance = await new LockCreator__factory().connect(ownerSigner).deploy() - - lastBlockTimeStamp = await time.latest() - - await lockInstance.createLock(lastBlockTimeStamp + UNLOCK_TIME, { - value: VALUE_LOCKED - }) - }) - - it('should get all locks', async () => { - const allLocks = await lockInstance.getAllLocks() - - console.log("all locks", allLocks) - }) -}); -``` - -Which will then throw an error: - -```bash -LockCreator Tests -Creating -Balance 10000000000000000 - 1) should get all locks - - 0 passing (3s) - 1 failing - - 1) LockCreator Tests - should get all locks: - Error: VM Exception while processing transaction: reverted with panic code 0x32 (Array accessed at an out-of-bounds or negative index) -``` - -You can include some debugging logs to identify the issue: - -```solidity - function getAllLocks() external view returns(Lock[] memory result) { - result = new Lock[](locks.length); - - console.log("locks length %s", locks.length); - - for(uint i = 0; i <= locks.length; i++){ - console.log("Locks index %s", i); - result[i] = locks[i]; - } -} -``` - -Then, you see the following in the terminal: - -```bash - LockCreator Tests -Creating -Balance 10000000000000000 -locks length 1 -Locks index 0 -Locks index 1 -1) LockCreator Tests - should get all locks: - Error: VM Exception while processing transaction: reverted with panic code 0x32 (Array accessed at an out-of-bounds or negative index) -``` - -Since arrays are 0 index based, an array with 1 item will store that item at the 0 index. In the above example, the `if` statement compares `<=` against the length of the array, so it tries to access the element in position 1, and crashes. - -Here's the simple solution: - -```solidity - function getAllLocks() external view returns(Lock[] memory result) { - result = new Lock[](locks.length); - - console.log("locks length %s", locks.length); - - for(uint i = 0; i < locks.length; i++){ - console.log("Locks index %s", i); - result[i] = locks[i]; - } -} -``` - -Which immediately solves the problem: - -```bash - LockCreator Tests -Creating -Balance 10000000000000000 -locks length 1 -Locks index 0 -all locks Result(1) [ '0x83BA8C2028EE8a6476396145C7692fBD09337acD' ] - ✔ should get all locks - - 1 passing (3s) -``` - -## Conclusion - -In this tutorial, you've learned some techniques about how to debug smart contracts using Hardhat. You explored some common cases of various errors and how by simply using `console.log` and a proper test, you can identify and solve the problem. - -## See also - -[Console.log]: https://hardhat.org/hardhat-network/docs/reference#console.log -[Error Triage]: https://docs.base.org/learn/error-triage/error-triage -[Base Learn]: https://base.org/learn - diff --git a/docs/learn/hardhat/hardhat-tools-and-testing/deploy-with-hardhat.mdx b/docs/learn/hardhat/hardhat-tools-and-testing/deploy-with-hardhat.mdx deleted file mode 100644 index e1418d4a2..000000000 --- a/docs/learn/hardhat/hardhat-tools-and-testing/deploy-with-hardhat.mdx +++ /dev/null @@ -1,405 +0,0 @@ ---- -title: Deploying a smart contract using Hardhat -slug: /deploy-with-hardhat -description: "A tutorial that teaches how to deploy a smart contract on the Base test network using Hardhat. Includes instructions for setting up the environment, compiling, and deploying the smart contract." -author: taycaldwell ---- - -This section will guide you through deploying an NFT smart contract (ERC-721) on the Base test network using [Hardhat](https://hardhat.org/). - -Hardhat is a developer tool that provides a simple way to deploy, test, and debug smart contracts. - - - -## Objectives - -By the end of this tutorial, you should be able to do the following: - -- Setup Hardhat for Base -- Create an NFT smart contract for Base -- Compile a smart contract for Base -- Deploy a smart contract to Base -- Interact with a smart contract deployed on Base - - - -## Prerequisites - -### Node v18+ - -This tutorial requires you have Node version 18+ installed. - -- Download [Node v18+](https://nodejs.org/en/download/) - -If you are using `nvm` to manage your node versions, you can just run `nvm install 18`. - -### Coinbase Wallet - -In order to deploy a smart contract, you will first need a web3 wallet. You can create a wallet by downloading the Coinbase Wallet browser extension. - -- Download [Coinbase Wallet](https://chrome.google.com/webstore/detail/coinbase-wallet-extension/hnfanknocfeofbddgcijnmhnfnkdnaad?hl=en) - -### Wallet funds - -Deploying contracts to the blockchain requires a gas fee. Therefore, you will need to fund your wallet with ETH to cover those gas fees. - -For this tutorial, you will be deploying a contract to the Base Sepolia test network. You can fund your wallet with Base Sepolia ETH using one of the faucets listed on the Base [Network Faucets](https://docs.base.org/base-chain/tools/network-faucets) page. - - - -## Creating a project - -Before you can begin deploying smart contracts to Base, you need to set up your development environment by creating a Node.js project. - -To create a new Node.js project, run: - -```bash -npm init --y -``` - -Next, you will need to install Hardhat and create a new Hardhat project - -To install Hardhat, run: - -```bash -npm install --save-dev hardhat -``` - -To create a new Hardhat project, run: - -```bash -npx hardhat init -``` - -Select `Create a TypeScript project` then press _enter_ to confirm the project root. - -Select `y` for both adding a `.gitignore` and loading the sample project. It will take a moment for the project setup process to complete. - - - -## Configuring Hardhat with Base - -In order to deploy smart contracts to the Base network, you will need to configure your Hardhat project and add the Base network. - -To configure Hardhat to use Base, add Base as a network to your project's `hardhat.config.ts` file: - -```tsx -import { HardhatUserConfig } from 'hardhat/config'; -import '@nomicfoundation/hardhat-toolbox'; - -require('dotenv').config(); - -const config: HardhatUserConfig = { - solidity: { - version: '0.8.23', - }, - networks: { - // for mainnet - 'base-mainnet': { - url: 'https://mainnet.base.org', - accounts: [process.env.WALLET_KEY as string], - gasPrice: 1000000000, - }, - // for testnet - 'base-sepolia': { - url: 'https://sepolia.base.org', - accounts: [process.env.WALLET_KEY as string], - gasPrice: 1000000000, - }, - // for local dev environment - 'base-local': { - url: 'http://localhost:8545', - accounts: [process.env.WALLET_KEY as string], - gasPrice: 1000000000, - }, - }, - defaultNetwork: 'hardhat', -}; - -export default config; -``` - -### Install Hardhat toolbox - -The above configuration uses the `@nomicfoundation/hardhat-toolbox` plugin to bundle all the commonly used packages and Hardhat plugins recommended to start developing with Hardhat. - -To install `@nomicfoundation/hardhat-toolbox`, run: - -```bash -npm install --save-dev @nomicfoundation/hardhat-toolbox -``` - -### Loading environment variables - -The above configuration also uses [dotenv](https://www.npmjs.com/package/dotenv) to load the `WALLET_KEY` environment variable from a `.env` file to `process.env.WALLET_KEY`. You should use a similar method to avoid hardcoding your private keys within your source code. - -To install `dotenv`, run: - -```bash -npm install --save-dev dotenv -``` - -Once you have `dotenv` installed, you can create a `.env` file with the following content: - -``` -WALLET_KEY="
-
- );
-};
-
-export default App;
-```
-
-With everything complete, you're ready to run your application to test it. To do so, go through the following process:
-
-1. Navigate to the root of your project.
-2. Run either `npm run start` or `yarn start`.
-3. Once running, log in with either your Google or Twitter.
-4. Fund the address displayed on the wallet modal in the bottom right.
-5. Click "Execute User Operation".
-
-## Conclusion
-
-Congratulations! You've just built an application from scratch, onboarding users into smart accounts through social logins using Particle Network.
-
-To learn more about using Particle Network on Base, take a look at the following resources:
-
-- [Biconomy Guide (which uses Particle Network)]
-- [Account Abstraction on Base]
-- [Particle Network Documentation]
-- [Particle Network 101: Developer Experience]
-
-[create-react-app]: https://create-react-app.dev
-[Base Faucets]: https://docs.base.org/base-chain/tools/network-faucets
-[Web3Auth]: https://web3auth.io
-[Privy]: https://docs.base.org/tutorials/account-abstraction-with-privy-and-base-paymaster/
-[Magic]: https://magic.link
-[ERC-4337]: https://eips.ethereum.org/EIPS/eip-4337
-[Biconomy]: https://docs.base.org/guides/account-abstraction-with-biconomy
-[external infrastructure and components]: https://blog.particle.network/announcing-our-smart-wallet-as-a-service-modular-stack-upgrading-waas-with-erc-4337
-[Introduction to Account Abstraction]: https://docs.base.org/cookbook/account-abstraction/account-abstraction-on-base-using-privy-and-the-base-paymaster
-[Particle dashboard]: https://dashboard.particle.network
-[Biconomy Guide (which uses Particle Network)]: https://docs.base.org/cookbook/account-abstraction/account-abstraction-on-base-using-biconomy
-[Account Abstraction on Base]: https://docs.base.org/tools/account-abstraction
-[Particle Network Documentation]: https://developers.particle.network
-[Particle Network 101: Developer Experience]: https://blog.particle.network/particle-network-101-developer-experience-edition
-
diff --git a/docs/learn/onchain-app-development/account-abstraction/account-abstraction-on-base-using-privy-and-the-base-paymaster.mdx b/docs/learn/onchain-app-development/account-abstraction/account-abstraction-on-base-using-privy-and-the-base-paymaster.mdx
deleted file mode 100644
index 5f86a1aa9..000000000
--- a/docs/learn/onchain-app-development/account-abstraction/account-abstraction-on-base-using-privy-and-the-base-paymaster.mdx
+++ /dev/null
@@ -1,737 +0,0 @@
----
-title: 'Account Abstraction on Base using Privy and the Base Paymaster'
-slug: /account-abstraction-with-privy-and-base-paymaster
-description: A tutorial that teaches how to implement Account Abstraction into a Base project using Privy and the Base paymaster.
-author: Brian Doyle and Aaron Hayslip
----
-
-# Account Abstraction on Base using Privy and the Base Paymaster
-
-This tutorial shows you how to use [Privy], [Alchemy's Account Kit], and the [Base Paymaster] to enable your users to use onchain apps without creating a wallet on their own, or even needing to pay for gas fees!
-
-## Objectives
-
-By the end of this tutorial, you should be able to:
-
-### Intro to Account Abstraction
-
-- Explain how Account Abstraction can improve user experience for onchain apps
-- Describe the difference between contract accounts and EOAs, the limitations of contract accounts, and how EIP-4337 uses `UserOperation`s to mitigate these limitations
-- Outline how Account Abstraction works, and how users interact with smart contract wallets
-
-### Intro to Privy
-
-- Implement Privy's quick start to add onchain authentication to a NextJS application
-- Compare Privy's progressive authentication strategy with traditional wallet-based authentication
-- Use Privy's `PrivyProvider` context and `usePrivy` hook to implement basic authentication via an email address, SMS, EOA, and/or social auth
-- Utilize Privy's Embedded Wallets to enable users to utilize wallet-based actions without having to connect to an external wallet or leave your application
-
-### Implementing the Paymaster
-
-- Describe how a third party can use a _paymaster_ to sponsor gas
-- Modify Privy's Base [paymaster example] example to work in another app, using an EOA to allow a user to call a smart contract function without requiring the user to pay any gas
-
-## Prerequisites
-
-### 1. Be familiar with modern, frontend web development
-
-In this tutorial, we'll be working with a React frontend built with [Next.js]. While you don't need to be an expert, we'll assume that you're comfortable with the basics.
-
-### 2. Possess a general understanding of the EVM and smart contract development
-
-This tutorial assumes that you're reasonably comfortable writing basic smart contracts. If you're just getting started, jump over to our [Base Learn] guides and start learning!
-
-## Intro do Account Abstraction
-
-[ERC-4337], also known as _Account Abstraction_, is a standard that allows smart contracts to initiate transactions, thus enabling any logic that users want to implement to be encoded into the smart contract wallet itself for execution on Ethereum.
-
-Account Abstraction has the potential to be a massive game-changer for onchain user experience and many believe it will play a key role in bringing the next billion users onchain.
-
-### The Problem Account Abstraction Solves
-
-Onchain applications are difficult to use for many people, as they require a lengthy onboarding process for the average internet user who already onchain.
-
-For example,the preliminary steps a user needs to go through before they can use an onchain app are:
-
-1. Create a wallet (Coinbase Wallet, Metamask, etc)
-1. Store the wallet mnemonic safely, without losing it or compromising it
-1. Sign a slightly frightening message to connect to an onchain app
-1. Try to do anything with the app and get a popup asking them to approve a transaction
-1. Attempt to do so, learn transactions cost gas, and that they don't have any
-1. Learn that gas is a fee that users must pay in ETH to use onchain apps
-1. Attempt to buy ETH, possibly buying the wrong flavor of ETH in the wrong location
-1. Try the transaction again
-1. Repeat until they finally find the correct path
-
-For widespread adoption of onchain applications, this confusing and alienating process has to change.
-
-That's where Account Abstraction comes in. It allows you to improve the onboarding and usage flow for your users:
-
-1. User goes to the onchain app and authenticates (using email, EOA, or social auth)
-2. User uses the app
-3. Transactions happen under the hood via a smart contract wallet and the app developer sponsors the user's gas fees until after they're onboarded.
-
-To summarize, Account Abstraction enables smart contract accounts to initiate user operations, similar to how an EOA would initiate a transaction. However, unlike EOAs, smart contract accounts are programmable and can enable a number of incredible features, such as:
-
-- **Sponsored Transactions**: Allow application owners to cover the users gas fees with a paymaster or allow a user to use something other than ETH (USDC, for example) to cover gas
-- **Arbitrary Verification Logic**: Verify transactions with custom logic
-- **Account Recovery**: Create account recovery features for when user lose private keys
-- **Batching Transactions**: Change the user experience so that multiple transactions can be submitted at once
-
-### Overview of ERC-4337 - Account Abstraction
-
-"Account Abstraction" comes from [ERC-4337]. The proposal itself is a dense read, but one of stated goals of the proposal is to:
-
-> allow users to use smart contract wallets containing arbitrary verification logic instead of EOAs as their primary account. Completely remove any need at all for users to also have EOAs (as status quo SC wallets and EIP-3074 both require)
-
-In other words, the proposal seeks to allow users to use _smart contract wallets_ **instead** of EOAs to transact onchain.
-
-
- 
- 
-
- {!userInfo ? (
-
-
-
-
-
-
- ) : (
-
-
- )}
- {userInfo.name}
-
-
-
-
- - Your Smart Wallet Address -
- - {smartAccountAddress} - -- Your Signer Address -
- - {eoa?.address} - -``` - -Paste it above the `` for the `User Object` window.
-
-You'll need to import `BASE_GOERLI_SCAN_URL` from `constants.ts`. The `useSmartAccount` hook returns `smartAccountProvider` and `eoa`. Import it and add it under the `usePrivy` hook. You don't need them just yet, but go ahead and decompose `smartAccountProvider` and `sendSponsoredUserOperation` as well:
-
-```tsx
-const router = useRouter();
-const {
- ready,
- authenticated,
- user,
- logout,
- linkEmail,
- linkWallet,
- unlinkEmail,
- linkPhone,
- unlinkPhone,
- unlinkWallet,
- linkGoogle,
- unlinkGoogle,
- linkTwitter,
- unlinkTwitter,
- linkDiscord,
- unlinkDiscord,
-} = usePrivy();
-const { smartAccountAddress, smartAccountProvider, sendSponsoredUserOperation, eoa } =
- useSmartAccount();
-```
-
-Run the app. You'll now see your familiar wallet address as `YOUR SIGNER ADDRESS`!
-
-
{'Mint failed with error: ' + error}
); - } -}; -``` - -Finally, above where you added the addresses, add a button to call the function, and display the link to the transaction: - -```tsx -; -{ - transactionLink; -} -``` - -Run it and confirm it works. You need the full transaction receipt for the process to finish, so expect to wait as long as 10 or 15 seconds. - -
- {/* ... other sections ... */}
-
-
-
-
-);
-```
-
-Sweet! Now our conditional rendering is in full force. If a user clicks on the `+ Add funds to transact` button they will be given three options for topping up their smart wallet:
-
-
-
-
-
-## Conclusion
-
-Congratulations! You've built a app that checks a user's smart wallet balance and provides appropriate options based on their funds.
-This app can serve as a foundation for more complex onchain applications that require users to have funded smart wallets.
-
-[Onchain Kit]: https://github.com/coinbase/onchainkit
-[Viem]: https://viem.sh/
-[Smart Wallets]: https://keys.coinbase.com/onboarding
-[viem]: https://viem.sh/docs/introduction
-[react hooks]: https://react.dev/reference/react/hooks
-[Onramp config page]: https://portal.cdp.coinbase.com/products/onramp
-[official documentation]: https://react.dev/
-
diff --git a/docs/learn/onchain-app-development/frontend-setup/building-an-onchain-app.mdx b/docs/learn/onchain-app-development/frontend-setup/building-an-onchain-app.mdx
deleted file mode 100644
index 99ddd07f9..000000000
--- a/docs/learn/onchain-app-development/frontend-setup/building-an-onchain-app.mdx
+++ /dev/null
@@ -1,219 +0,0 @@
----
-title: Building an Onchain App
-description: Learn step-by-step how to turn a regular template app into an onchain app with a wallet connection.
-hide_table_of_contents: false
----
-
-import { Danger } from "/snippets/danger.mdx";
-
-# Building an Onchain App
-
-While it's convenient and fast to start from a template, the template may not fit your needs. Whether you prefer a different stack, or have already started building the traditional web components of your app, it's common to need to manually add onchain libraries to get your app working.
-
-In this guide, you'll build the beginnings of an app similar to the one created by the [RainbowKit] quick start, but you'll do it piece by piece. You can follow along, and swap out any of our library choices with the ones you prefer.
-
----
-
-## Objectives
-
-By the end of this guide you should be able to:
-
-- Identify the role of a wallet aggregator in an onchain app
-- Debate the pros and cons of using a template
-- Add a wallet connection to a standard template app
-
----
-
-## Creating the Traditional App
-
-Start by running the [Next.js] script to create a Next.js app:
-
-```bash
-npx create-next-app@latest --use-yarn
-```
-
-This script will accept `.`, if you want to add the project to the root of a folder you've already created. Otherwise, name your project. Select each option in the generation script as you see fit. We recommend the following selections:
-
-- Use Typescript?: Yes
-- Use ESLint?: Yes
-- Use Tailwind?: Your preference
-- Use `src/` directory?: Yes
-- Use App Router?: Yes
-- Customize the default import alias?: No
-
-
-
- {address ? (
- parseFloat(walletBalance) > 0 ? (
-
-
- - Your Wallet has {walletBalance} ETH -
-`:
-
-```tsx
-// This function has been simplified to save space.
-export default function Home() {
- return (
-
-
- );
-}
-```
-
-Run your app with `yarn dev`, and you should be able to use the RainbowKit connect button to connect with your wallet and switch between networks.
-
-You use the [Connect Button] props to modify its properties, or you can [customize the connect button] extensively. Some users dislike having the connect button display their token balance. Try disabling it with:
-
-```tsx
-
-New onchain devs sometimes get the impression that there are free options for connecting their apps to the blockchain. Unfortunately, this is not really true. Blockchain data is still 1's and 0's, fetched by computation and served to the internet via servers.
-
-It costs money to run these, and you will eventually need to pay for the service.
-
-
-You'll encounter providers divided into three general categories: Public Providers, Wallet Providers, and Vendor Providers
-
-### Public Providers
-
-Many tutorials and guides, including the getting started guide for [wagmi], use a _Public Provider_ as the default to get you up and running. Public means that they're open, permissionless, and free, so the guides will also usually warn you that you need to add another provider if you don't want to run into rate limiting. Listen to these warnings! The rate-limits of public providers are severe, and you'll start getting limited very quickly.
-
-In wagmi, a public client is automatically included in the default config. This client is just a wrapper setting up a [JSON RPC] provider using the `chain` and `rpcUrls` listed in Viem's directory of chain information. You can view the [data for Base Sepolia here].
-
-Most chains will list this information in their docs as well. For example, on the network information pages for [Base] and [Optimism]. If you wanted, you could manually set up a `jsonRpcProvider` in wagmi using this information.
-
-### Wallet Providers
-
-Many wallets, including Coinbase Wallet and MetaMask, inject an Ethereum provider into the browser, as defined in [EIP-1193]. The injected provider is accessible via `window.ethereum`.
-
-Under the hood, these are also just JSON RPC providers. Similar to public providers, they are rate-limited.
-
-Older tutorials for early libraries tended to suggest using this method for getting started, so you'll probably encounter references to it. However, it's fallen out of favor, and you'll want to use the public provider for your initial connection experiments.
-
-### Vendor Providers
-
-A growing number of vendors provide access to blockchain nodes as a service. Visiting the landing pages for [QuickNode], [Alchemy], or [Coinbase Developer Platform (CDP)] can be a little confusing. Each of these vendors provides a wide variety of services, SDKs, and information.
-
-Luckily, you can skip most of this if you're just trying to get your frontend connected to your smart contracts. You'll just need to sign up for an account, and get an endpoint, or a key, and configure your app to connect to the provider(s) you choose.
-
-It is worth digging in to get a better understanding of how these providers charge you for their services. The table below summarizes some of the more important API methods, and how you are charged for them by each of the above providers.
-
-Note that the information below may change, and varies by network. Each provider also has different incentives, discounts, and fees for each level of product. They also have different allowances for calls per second, protocols, and number of endpoints. Please check the source to confirm!
-
-| | [Alchemy Costs] | [QuickNode Costs] | [CDP Costs] |
-| :-------------- | :--------------- | :---------------- | :----------------- |
-| Free Tier / Mo. | 3M compute units | 50M credits | 500M billing units |
-| Mid Tier / Mo. | 1.5B CUs @ $199 | 3B credits @ $299 | Coming soon |
-| eth_blocknumber | 10 | 20 | 30 |
-| eth_call | 26 | 20 | 30 |
-| eth_getlogs | 75 | 20 | 100 |
-| eth_getbalance | 19 | 20 | 30 |
-
-To give you an idea of usage amounts, a single wagmi `useContractRead` hook set to watch for changes on a single `view` via a TanStack query and `useBlockNumber` will call `eth_blocknumber` and `eth_call` one time each, every 4 seconds.
-
-## Connecting to the Blockchain
-
-[RainbowKit] is a popular library that works with [wagmi] to make it easy to connect, disconnect, and change between multiple wallets. It's batteries-included out of the box, and allows for a great deal of customization of the list of wallets and connect/disconnect button.
-
-You'll be using RainbowKit's [quick start] to scaffold a new project for this tutorial. Note that at the time of writing, it does **not** use the Next.js app router. See [Building an Onchain App] if you wish to set this up instead.
-
-
-The script doesn't allow you to use `.` to create a project in the root of the folder you run it from, so you'll want to run it from your `src` directory, or wherever you keep your project folders.
-
-It will create a folder with the project name you give, and create the files inside.
-
-
-Open up a terminal and run:
-
-```bash
-yarn create @rainbow-me/rainbowkit
-```
-
-Give your project a name, and wait for the script to build it. It will take a minute or two.
-
-
-If you get an error because you are on the wrong version of node, change to the correct version then **delete everything** and run the script again.
-
-
-### Scaffolded App
-
-Open your new project in the editor of your choice, and open `pages/_app.tsx`. Here, you'll find a familiar Next.js app wrapped in [context providers] for the TanStack QueryProvider, RainbowKit, and wagmi.
-
-```tsx
-function MyApp({ Component, pageProps }: AppProps) {
- return (
-
-
-
-
-
-
- );
-}
-```
-
-Note that these providers are using React's context feature to pass the blockchain providers and configuration into your app. It can be confusing to have the word _provider_ meaning two different things in the same file, or even the same line of code!
-
-Before you can do anything else, you need to obtain a _WalletConnect_ `projectId`.
-
-Open up the [WalletConnect] homepage, and create an account, and/or sign in using the method of your choice.
-
-Click the `Create` button in the upper right of the `Projects` tab.
-
-
-
-
-
-Enter a name for your project, select the `App` option, and click `Create`.
-
-
-
-
-
-Copy the _Project ID_ from the project information page, and paste it in as the `projectId` in `getDefaultWallets`.
-
-```tsx
-const { connectors } = getDefaultWallets({
- appName: 'RainbowKit App',
- projectId: 'YOUR_PROJECT_ID',
- chains,
-});
-```
-
-
-Remember, anything you put on the frontend is public! That includes this id, even if you use environment variables to better manage this type of data. Next.js reminds you of the risk, by requiring you to prepend `NEXT_PUBLIC_` to any environment variables that can be read by the browser.
-
-Before you deploy, make sure you configure the rest of the items in the control panel to ensure only your site can use this id.
-
-
-### Public Provider
-
-By default, the setup script will configure your app to use the built-in public provider, and connect to a number of popular chains. To simply matters, remove all but `mainnet` and `base`.
-
-```tsx
-const config = getDefaultConfig({
- appName: 'RainbowKit App',
- projectId: 'YOUR_APP_ID_HERE',
- chains: [mainnet, base],
- ssr: true,
-});
-```
-
-Open the terminal and start the app with:
-
-```bash
-yarn run dev
-```
-
-Click the `Connect Wallet` button, select your wallet from the modal, approve the connection, and you should see your network, token balance, and address or ENS name at the top of the screen. Select your wallet from the modal.
-
-
-
-
-
-You've connected with the Public Provider!
-
-
-
-
-
-### QuickNode
-
-To select your provider(s), you'll use [`createConfig`] instead of `getDefaultConfig`. The [`transports`] property allows you to configure how you wish to connect with multiple networks. If you need more than one connector for a given network, you can use [`fallbacks`].
-
-First, set up using [QuickNode] as your provider. Replace your import of the default config from RainbowKit with `createConfig` and `http` from wagmi:
-
-```tsx
-import { createConfig, http, WagmiProvider } from 'wagmi';
-// ...Chains import
-import { RainbowKitProvider } from '@rainbow-me/rainbowkit';
-```
-
-You'll need an RPC URL, so open up [QuickNode]'s site and sign up for an account if you need to. The free tier will be adequate for now, you may need to scroll down to see it. Once you're in, click `Endpoints` on the left side, then click `+ Create Endpoint`.
-
-On the next screen, you'll be asked to select a chain. Each endpoint only works for one. Select `Base`, click `Continue`.
-
-
-
-
-
-For now, pick `Base Mainnet`, but you'll probably want to delete this endpoint and create a new one for Sepolia when you start building. The free tier only allows you to have one at a time.
-
-If you haven't already picked a tier, you'll be asked to do so, then you'll be taken to the endpoints page, which will display your endpoints for HTTP and WSS.
-
-
-As with your WalletConnect Id, these endpoints will be visible on the frontend. Be sure to configure the allowlist!
-
-
-Use this endpoint to add an `http` `transport` to your config:
-
-```tsx
-const config = createConfig({
- chains: [mainnet, base],
- ssr: true,
- transports: {
- [base.id]: http('YOUR PROJECT URL'),
- [mainnet.id]: http('TODO'),
- },
-});
-```
-
-Now, the app will use your QuickNode endpoint for the Base network. Note that you don't need an app name or WalletConnect Id, because you are no longer using WalletConnect.
-
-To test this out, switch networks a few times. You'll know it's working if you see your balance when Base is the selected network. You haven't added mainnet, so you'll get an error in the console and no balance when you switch to that.
-
-### Alchemy
-
-[Alchemy] is [no longer baked into wagmi], but it still works the same as any other RPC provider. As with QuickNode, you'll need an account and a key. Create an account and/or sign in, navigate to the `Apps` section in the left sidebar, and click `Create new app`.
-
-
-
-
-
-Select Base Mainnet, and give your app a name.
-
-
-Once again, remember to configure the [allowlist] when you publish your app, as you'll be exposing your key to the world!
-
diff --git a/docs/learn/onchain-app-development/frontend-setup/overview.mdx b/docs/learn/onchain-app-development/frontend-setup/overview.mdx
deleted file mode 100644
index af693f4b9..000000000
--- a/docs/learn/onchain-app-development/frontend-setup/overview.mdx
+++ /dev/null
@@ -1,53 +0,0 @@
----
-title: 'Overview'
-description: An overview of this course.
-hide_table_of_contents: false
----
-
-# Overview
-
-Welcome! The course you are about to begin will rapidly introduce you to frontend web development for onchain apps and enable you to write websites that can call your smart contract functions in a similar way to how traditional sites interact with APIs.
-
-## Prerequisites
-
-Before these lessons, you should:
-
-- Be comfortable with traditional frontend development using React, ideally with NextJS
-- Possess a general understanding of the EVM and smart contracts
-
----
-
-## Objectives
-
-By the end of this course, you should be able to:
-
-- **Frontend Setup**
- - Identify the role of a wallet aggregator in an onchain app
- - Debate the pros and cons of using a template
- - Scaffold a new onchain app with RainbowKit
- - Add a wallet connection to a standard template app
-- **Connecting to the Blockchain**
- - Compare and contrast public providers vs. vendor providers vs. wallet providers
- - Select the appropriate provider for several use cases
- - Set up a provider in wagmi and use it to connect a wallet
- - Protect API keys that will be exposed to the front end
-- **Reading and Displaying Data**
- - Implement the `useAccount` hook to show the user's address, connection state, network, and balance
- - Implement an `isMounted` hook to prevent hydration errors
- - Implement wagmi's `useReadContract` hook to fetch data from a smart contract
- - Convert data fetched from a smart contract to information displayed to the user
- - Identify the caveats of reading data from automatically-generated getters
- - Enable the `watch` feature of `useReadContract` to automatically fetch updates from the blockchain
- - Describe the costs of using the `watch` feature, and methods to reduce those costs
- - Configure arguments to be passed with a call to a `pure` or `view` smart contract function
- - Call an instance of `useReadContract` on demand
- - Utilize `isLoading` and `isFetching` to improve user experience
-- **Writing to Contracts**
- - Implement wagmi's `useWriteContract` hook to send transactions to a smart contract
- - Configure the options in `useWriteContract`
- - Display the execution, success, or failure of a function with button state changes, and data display
- - Implement Wagmi's `usePrepareContractWrite` and `useWriteContract` to send transactions to a smart contract
- - Configure the options in `useSimulateContract` and `useWriteContract`
- - Call a smart contract function on-demand using the write function from `useWriteContract`, with arguments and a value
-
----
diff --git a/docs/learn/onchain-app-development/frontend-setup/viem.mdx b/docs/learn/onchain-app-development/frontend-setup/viem.mdx
deleted file mode 100644
index 19a231df6..000000000
--- a/docs/learn/onchain-app-development/frontend-setup/viem.mdx
+++ /dev/null
@@ -1,107 +0,0 @@
----
-title: viem
-slug: /tools/viem
-description: Documentation for using Viem, a TypeScript interface for EVM-compatible blockchains. This page covers installation, setup, and various functionalities such as reading and writing blockchain data and interacting with smart contracts on Base.
----
-
-# viem
-
-
-Viem is currently only available on Base Sepolia testnet.
-
-
-[viem](https://viem.sh/) a TypeScript interface for Ethereum that provides low-level stateless primitives for interacting with Ethereum.
-
-You can use viem to interact with smart contracts deployed on Base.
-
-## Install
-
-To install viem run the following command:
-
-```bash
-npm install --save viem
-```
-
-## Setup
-
-Before you can start using viem, you need to setup a [Client](https://viem.sh/docs/clients/intro.html) with a desired [Transport](https://viem.sh/docs/clients/intro.html) and [Chain](https://viem.sh/docs/chains/introduction).
-
-```javascript
-import { createPublicClient, http } from 'viem';
-import { base } from 'viem/chains';
-
-const client = createPublicClient({
- chain: base,
- transport: http(),
-});
-```
-
-
-To use Base, you must specify `base` as the chain when creating a Client.
-
-To use Base Sepolia (testnet), replace `base` with `baseSepolia`.
-
-
-## Reading data from the blockchain
-
-Once you have created a client, you can use it to read and access data from Base using [Public Actions](https://viem.sh/docs/actions/public/introduction.html)
-
-Public Actions are client methods that map one-to-one with a "public" Ethereum RPC method (`eth_blockNumber`, `eth_getBalance`, etc.)
-
-For example, you can use the `getBlockNumber` client method to get the latest block:
-
-```javascript
-const blockNumber = await client.getBlockNumber();
-```
-
-## Writing data to the blockchain
-
-In order to write data to Base, you need to create a Wallet client (`createWalletClient`) and specify an [`Account`](https://ethereum.org/en/developers/docs/accounts/) to use.
-
-```javascript
-import { createWalletClient, custom } from 'viem'
-import { base } from 'viem/chains'
-
-//highlight-start
-const [account] = await window.ethereum.request({ method: 'eth_requestAccounts' })
-//highlight-end
-
-const client = createWalletClient({
- //highlight-next-line
- account,
- chain: base,
- transport: custom(window.ethereum)
-})
-
-client.sendTransaction({ ... })
-```
-
-
-In addition to making a JSON-RPC request (`eth_requestAccounts`) to get an Account, viem provides various helper methods for creating an `Account`, including: [`privateKeyToAccount`](https://viem.sh/docs/accounts/local/privateKeyToAccount), [`mnemonicToAccount`](https://viem.sh/docs/accounts/local/mnemonicToAccount), and [`hdKeyToAccount`](https://viem.sh/docs/accounts/local/hdKeyToAccount).
-
-To use Base Sepolia (testnet), replace `base` with `baseSepolia`.
-
-
-## Interacting with smart contracts
-
-You can use viem to interact with a smart contract on Base by creating a `Contract` instance using [`getContract`](https://viem.sh/docs/contract/getContract.html) and passing it the contract ABI, contract address, and [Public](https://viem.sh/docs/clients/public.html) and/or [Wallet](https://viem.sh/docs/clients/wallet.html) Client:
-
-```javascript
-import { getContract } from 'viem';
-import { wagmiAbi } from './abi';
-import { publicClient } from './client';
-
-// 1. Create contract instance
-const contract = getContract({
- address: 'CONTRACT_ADDRESS',
- abi: wagmiAbi,
- publicClient,
-});
-
-// 2. Call contract methods, listen to events, etc.
-const result = await contract.read.totalSupply();
-```
-
-
-`CONTRACT_ADDRESS` is the address of the deployed contract.
-
diff --git a/docs/learn/onchain-app-development/frontend-setup/wallet-connectors.mdx b/docs/learn/onchain-app-development/frontend-setup/wallet-connectors.mdx
deleted file mode 100644
index fa45223f2..000000000
--- a/docs/learn/onchain-app-development/frontend-setup/wallet-connectors.mdx
+++ /dev/null
@@ -1,94 +0,0 @@
----
-title: Wallet Connectors
-description: Learn about how wallet connector libraries aggregate wallets and make it easier to connect to them from your app.
-hide_table_of_contents: false
----
-
-# Wallet Connectors
-
-One of the most intimidating tasks when building an onchain app is making that initial connection between your users' wallets, and your app. Initial research often surfaces a bewildering number of wallets, each with their own SDKs, and own methods to manage the connection. Luckily, you don't actually need to manage all of this on your own. There are a number of wallet connector libraries specialized in creating a smooth and beautiful user experience to facilitate this connection.
-
-To further add to the confusion and difficulty, [Smart wallets] are growing in popularity. These advanced wallets allow users to create and manage wallets with [passkeys], and support, or will soon support, a growing array of features including session keys, account recovery, and more!
-
-[RainbowKit], the aggregator you'll use for this lesson, works with the Coinbase Smart Wallet out of the box, but you'll need to do a little bit of extra configuration to support users of both traditional wallets and smart wallets.
-
----
-
-## Objectives
-
-By the end of this guide you should be able to:
-
-- Identify the role of a wallet aggregator in an onchain app
-- Debate the pros and cons of using a template
-- Scaffold a new onchain app with RainbowKit
-- Support users of EOAs and the Coinbase Smart Wallet with the same app
-
----
-
-## Connecting to the Blockchain
-
-One of the many challenging tasks of building a frontend that can interface with your smart contracts is managing the user's connection between your onchain app and their [EOA] wallet. Not only is there an ever-growing suite of different wallets, but users can (and probably should!) use several different addresses within the same wallet app.
-
-[Rainbowkit] is one of several options that makes this a little bit easier by serving as an aggregator of wallets, and handling some of the details of connecting them. Alternatives include [ConnectKit], and [Dynamic], which are both excellent choices as well.
-
-Each of these include customizable UI/UX components for inviting the user to connect, displaying connection status, and selecting which wallet they wish to use.
-
-### Using the Quick Start
-
-If you're just trying to get up and running as quickly as possible, you can use RainbowKit's [quick start] script to scaffold an app from their template, with a single command. If you're using Yarn:
-
-```bash
-yarn create @rainbow-me/rainbowkit
-```
-
-
-The script doesn't accept `.` as a project name, so you'll want to run this script in your `src` directory, or wherever you keep your projects. It will create a folder with the same name as your project, and install the project files inside.
-
-
-
-Once it's done, simply run the app with:
-
-```bash
-yarn run dev
-```
-
-Using the script is fast, but it does mean less choice. In this case, it builds the app on top of [Next.js], which is great if you want to use it, but not helpful if you prefer to work from a different framework, such as [Create React App], or [Remix] (the React framework, not the Solidity IDE). The script also doesn't help you if you want to add an onchain integration to an existing site.
-
-
-The Rainbowkit template has been updated to wagmi 2.X, but it does **not** use the Next.js app router. You'll need to install it manually if you wish to use the latest patterns.
-
-The [Building an Onchain App] tutorial will show you how to do this!
-
-
-
-### Coinbase Smart Wallet
-
-If you have the Coinbase Wallet extension, you might be wondering where the smart wallet can be found. By default, the smart wallet will only be invoked if you click the `Coinbase Wallet` button to log in **and** you **don't** have the browser extension. To test, open a private window with extensions disabled and try to log in.
-
-Selecting `Rainbow`, `MetaMask`, or `WalletConnect` will display a QR code so that the user can log in with their phone. Picking `Coinbase Wallet` will instead invoke the smart wallet login.
-
-This flow can be improved upon, as new crypto users won't know that digging for the smart wallet is the best path forward, and existing users who are trying to migrate to the smart wallet don't have that option.
-
-See our tutorial on how to [Use the Coinbase Smart Wallet and EOAs with OnchainKit] for more details!
-
----
-
-## Conclusion
-
-In this article, you've learned how libraries such as [Rainbowkit], [ConnectKit], and [Dynamic], aggregate wallets and make it easier for you to connect your app to your users' wallet of choice. You've also learned how you can use a template to quickly create the foundation of your app. Finally, you've learned that the cost of using a template is that it does make some choices for you.
-
----
-
-[RainbowKit]: https://www.rainbowkit.com/
-[wagmi]: https://wagmi.sh/
-[wallet]: https://ethereum.org/en/developers/docs/accounts/
-[ConnectKit]: https://ethereum.org/en/developers/docs/accounts/
-[Dynamic]: https://www.dynamic.xyz/
-[quick start]: https://www.rainbowkit.com/docs/installation
-[Next.js]: https://nextjs.org/
-[Create React App]: https://create-react-app.dev/
-[Remix]: https://remix.run/
-[Building an Onchain App]: ./building-an-onchain-app
-[Smart wallets]: https://www.coinbase.com/wallet/smart-wallet
-[passkeys]: https://safety.google/authentication/passkey/
-[Use the Coinbase Smart Wallet and EOAs with OnchainKit]: https://docs.base.org/tutorials/smart-wallet-and-eoa-with-onchainkit
diff --git a/docs/learn/onchain-app-development/frontend-setup/web3.mdx b/docs/learn/onchain-app-development/frontend-setup/web3.mdx
deleted file mode 100644
index ff726add9..000000000
--- a/docs/learn/onchain-app-development/frontend-setup/web3.mdx
+++ /dev/null
@@ -1,108 +0,0 @@
----
-title: web3.js
-description: Documentation for using web3.js, a JavaScript library for interacting with EVM-compatible blockchains. This page covers installation, setup, connecting to the Base network and interacting with smart contracts.
----
-
-# web3.js
-
-[web3.js](https://web3js.org/) is a JavaScript library that allows developers to interact with EVM-compatible blockchain networks.
-
-You can use web3.js to interact with smart contracts deployed on the Base network.
-
-## Install
-
-To install web3.js run the following command:
-
-```bash
-npm install web3
-```
-
-## Setup
-
-Before you can start using web3.js, you need to import it into your project.
-
-Add the following line of code to the top of your file to import web3.js:
-
-```javascript
-//web3.js v1
-const Web3 = require('web3');
-
-//web3.js v4
-const { Web3 } = require('web3');
-```
-
-## Connecting to Base
-
-You can connect to Base by instantiating a new web3.js `Web3` object with a RPC URL of the Base network:
-
-```javascript
-const { Web3 } = require('web3');
-
-const web3 = new Web3('https://mainnet.base.org');
-```
-
-
-To alternatively connect to Base Sepolia (testnet), change the above URL from `https://mainnet.base.org` to `https://sepolia.base.org`.
-
-
-## Accessing data
-
-Once you have created a provider, you can use it to read data from the Base network.
-
-For example, you can use the `getBlockNumber` method to get the latest block:
-
-```javascript
-async function getLatestBlock(address) {
- const latestBlock = await web3.eth.getBlockNumber();
- console.log(latestBlock.toString());
-}
-```
-
-## Deploying contracts
-
-Before you can deploy a contract to the Base network using web3.js, you must first create an account.
-
-You can create an account by using `web3.eth.accounts`:
-
-```javascript
-const privateKey = "PRIVATE_KEY";
-const account = web3.eth.accounts.privateKeyToAccount(privateKey);
-```
-
-
-`PRIVATE_KEY` is the private key of the wallet to use when creating the account.
-
-
-## Interacting with smart contracts
-
-You can use web3.js to interact with a smart contract on Base by instantiating a `Contract` object using the ABI and address of a deployed contract:
-
-```javascript
-const abi = [
-... // ABI of deployed contract
-];
-
-const contractAddress = "CONTRACT_ADDRESS"
-
-const contract = new web3.eth.Contract(abi, contractAddress);
-```
-
-Once you have created a `Contract` object, you can use it to call desired methods on the smart contract:
-
-```javascript
-async function setValue(value) {
- // write query
- const tx = await contract.methods.set(value).send();
- console.log(tx.transactionHash);
-}
-
-async function getValue() {
- // read query
- const value = await contract.methods.get().call();
- console.log(value.toString());
-}
-```
-
-
-For more information on deploying contracts on Base, see [Deploying a Smart Contract](../smart-contract-development/hardhat/deploy-with-hardhat.md).
-
diff --git a/docs/learn/onchain-app-development/reading-and-displaying-data/configuring-useReadContract.mdx b/docs/learn/onchain-app-development/reading-and-displaying-data/configuring-useReadContract.mdx
deleted file mode 100644
index 4a0b2bd5c..000000000
--- a/docs/learn/onchain-app-development/reading-and-displaying-data/configuring-useReadContract.mdx
+++ /dev/null
@@ -1,212 +0,0 @@
----
-title: Configuring `useReadContract`
-description: Configure the properties of the `useReadContract` hook.
-hide_table_of_contents: false
----
-
-# Configuring `useReadContract`
-
-The [`useReadContract`] hook has a number of configurable properties that will allow you to adapt it to your needs. You can combine the functionality of TanStack queries with [`useBlockNumber`] to watch the blockchain for changes, although doing so will consume a number of API calls.
-
----
-
-## Objectives
-
-By the end of this guide you should be able to:
-
-- Use `useBlockNumber` and the `queryClient` to automatically fetch updates from the blockchain
-- Describe the costs of using the above, and methods to reduce those costs
-- Configure arguments to be passed with a call to a `pure` or `view` smart contract function
-- Call an instance of `useReadContract` on demand
-- Utilize `isLoading` and `isFetching` to improve user experience
-
----
-
-## Fetching Updates from the Blockchain
-
-You'll continue with the project you've been building and last updated while learning about the [`useReadContract` hook].
-
-Once the excitement of your accomplishment of finally reading from your own contract subsides, try using BaseScan to add another issue, or vote on an existing issue. You'll notice that your frontend does **not** update. There are a few ways to handle this.
-
-
-
-Use `useBlockNumber` with the `watch` feature to automatically keep track of the block number, then use the `queryClient` to update when that changes. **Make sure** you decompose the `queryKey` from the return of `useReadContract`.
-
-```tsx
-import { useEffect, useState } from 'react';
-import { useReadContract, useBlockNumber } from 'wagmi';
-import { useQueryClient } from '@tanstack/react-query';
-
-// Other Code
-
-export function IssueList() {
- // Other Code
-
- const queryClient = useQueryClient();
- const { data: blockNumber } = useBlockNumber({ watch: true });
-
- const {
- data: issuesData,
- isError: issuesIsError,
- isPending: issuesIsPending,
- queryKey: issuesQueryKey,
- } = useReadContract({
- address: contractData.address as `0x${string}`,
- abi: contractData.abi,
- functionName: 'getAllIssues',
- });
-
- useEffect(() => {
- queryClient.invalidateQueries({ queryKey: issuesQueryKey });
- }, [blockNumber, queryClient, issuesQueryKey]);
-
- // Return code
-}
-```
-
-Don't do this, either use multi-call via [`useReadContracts`], or consolidate your `view`s into a single function that fetches all the data you need in one call.
-
-
-
-Stop watching the blockchain if the website doesn't have focus. Add a state variable to count how many times the function has settled, and one for if the page is focused. Set up event listeners to set the state of the latter when the page is focused or blurred.
-
-```tsx
-const [timesCalled, setTimesCalled] = useState(0);
-const [pageIsFocused, setPageIsFocused] = useState(true);
-
-useEffect(() => {
- const onFocus = () => setPageIsFocused(true);
- const onBlur = () => setPageIsFocused(false);
-
- window.addEventListener('focus', onFocus);
- window.addEventListener('blur', onBlur);
-
- return () => {
- window.removeEventListener('focus', onFocus);
- window.removeEventListener('blur', onBlur);
- };
-}, []);
-```
-
-Update the `watch` for `useBlockNumber` so that it only does so if `pageIsFocused`.
-
-```tsx
-const { data: blockNumber } = useBlockNumber({ watch: pageIsFocused });
-```
-
-Add a line to the `useEffect` for `blockNumber` and increment your counter as well.
-
-```tsx
-useEffect(() => {
- setTimesCalled((prev) => prev + 1);
- queryClient.invalidateQueries({ queryKey: issuesQueryKey });
-}, [blockNumber, queryClient]);
-```
-
-Finally, surface your counter in the component.
-
-```tsx
-return (
-
-
-Adjust your [`pollingInterval`] by setting it in `getDefaultConfig` in `_app.tsx`:
-
-```tsx
-const config = getDefaultConfig({
- appName: 'RainbowKit App',
- projectId: 'YOUR_PROJECT_ID',
- chains: [baseSepolia],
- ssr: true,
- pollingInterval: 30_000,
-});
-```
-
-Setting it to 30 seconds, or 30,000 milliseconds, will reduce your API calls dramatically, without negatively impacting members of the DAO.
-
-
-Use a similar system to call your update function on demand. Add a button, a handler for that button, and a state variable for it to set:
-
-```tsx
-const [triggerRead, setTriggerRead] = useState(false);
-
-const handleTriggerRead = () => {
- setTriggerRead(true);
-};
-```
-
-```tsx
-return (
-
-
-Use the "is" return values to set UI elements depending on the status of the hook as it attempts to call a function on the blockchain.
-
-```tsx
-
-```
-You'll probably see the button flicker very quickly since the call doesn't take very long. For a production app, you'd need to add additional handling to smooth out the experience.
-
-
-Arguments are passed into a `useReadContract` hook by adding an array of arguments, in order, to the `args` property. Common practice is to use React state variables set by UI elements to enable the arguments to be set and modified. For example, you might create a drop-down to set `issueNumber`, then fetch that issue with:
-
-```tsx
-const [issueNumber, setIssueNumber] = useState(0);
-
-const { isLoading: getIssueIsLoading } = useReadContract({
- address: contractData.address as `0x${string}`,
- abi: contractData.abi,
- functionName: 'getIssue',
- args: [issueNumber],
-});
-```
-
-
-
----
-
-## Conclusion
-
-In this guide, you've learned how to use the `watch` feature of `useBlockNumber` combined with `useEffect` and `queryClient.invalidateQueries` to enable your frontend to see updates to your smart contract. You've also learned the costs of doing so, and some strategies for mitigation. You've learned how to pass arguments to your functions. Finally, you've learned how to use the properties returned by `useReadContract` to adjust your UI to improve the experience for your users.
-
----
-
-[wagmi]: https://wagmi.sh/
-[`useReadContract`]: https://wagmi.sh/react/hooks/useReadContract
-[`useReadContract` hook]: ./useReadContract
-[`useBlockNumber`]: https://wagmi.sh/react/api/hooks/useBlockNumber
-[removed]: https://wagmi.sh/react/guides/migrate-from-v1-to-v2#removed-watch-property
-[`useReadContracts`]: https://wagmi.sh/react/hooks/useReadContracts
-[`pollingInterval`]: https://wagmi.sh/react/api/createConfig#pollinginterval
diff --git a/docs/learn/onchain-app-development/reading-and-displaying-data/useAccount.mdx b/docs/learn/onchain-app-development/reading-and-displaying-data/useAccount.mdx
deleted file mode 100644
index 52d09e3b2..000000000
--- a/docs/learn/onchain-app-development/reading-and-displaying-data/useAccount.mdx
+++ /dev/null
@@ -1,226 +0,0 @@
----
-title: The `useAccount` Hook
-description: Learn how to access information about the connected user's wallet.
-hide_table_of_contents: false
----
-
-# The `useAccount` Hook
-
-[wagmi] is a library that provides React hooks that trade a somewhat complex setup process for a great developer experience when building a frontend around the constraints and quirks of onchain building. One of the hooks, `useAccount`, provides access to information about your users' wallet and connection information.
-
-You can use this for connection-status-based rendering, to enable or disable controls or views based on address, and many other useful tasks.
-
----
-
-## Objectives
-
-By the end of this guide you should be able to:
-
-- Implement the `useAccount` hook to show the user's address, connection state, network, and balance
-- Implement an `isMounted` hook to prevent hydration errors
-
----
-
-## Displaying Connection Information
-
-We'll be working from an app generated by RainbowKit's [quick start]. Either open the one you created when we were exploring [Wallet Connectors], or create a new one for this project.
-
-Either way, change the list of chains to only include `baseSepolia` as the network option. You don't want to accidentally spend real money while developing!
-
-You can set up your providers as described in [Introduction to Providers], or use the default from RainbowKit:
-
-```tsx
-const config = getDefaultConfig({
- appName: 'RainbowKit App',
- projectId: 'YOUR APP ID',
- chains: [baseSepolia],
- ssr: true,
-});
-```
-
-Either way, be sure to set `ssr` to `true`, or you will get a [hydration error] from Next.js.
-
-### The `useAccount` Hook
-
-The [`useAccount`] hook allows you to access account and connection data from within any of your components.
-
-Add a folder for `components` and a file called `ConnectionWindow.tsx` in that folder. Add the below component to the file, and replace the boilerplate text in `index.tsx` with an instance of it.
-
-```tsx
-// ConnectionWindow.tsx
-export function ConnectionWindow() {
- return (
-
-
-
-
-);
-```
-Number of times called
-{timesCalled.toString()}
-{'Has focus: ' + pageIsFocused}
-All Issues
-{renderIssues()}
-
-
-
-);
-```
-
-Finally, set `watch` to equal `triggerRead`, instead of `pageIsFocused`, and reset `triggerRead` in the `useEffect`.
-
-```tsx
-const { data: blockNumber } = useBlockNumber({ watch: triggerRead });
-
-// Other code...
-
-useEffect(() => {
- setTriggerRead(false);
- queryClient.invalidateQueries({ queryKey: issuesQueryKey });
-}, [blockNumber, queryClient]);
-```
-Number of times called
-{timesCalled.toString()}
-{'Has focus: ' + pageIsFocused}
-All Issues
-{renderIssues()}
-
-
- );
-}
-```
-
-```tsx
-// index.tsx
-import { ConnectButton } from '@rainbow-me/rainbowkit';
-import type { NextPage } from 'next';
-import Head from 'next/head';
-import styles from '../styles/Home.module.css';
-import { ConnectionWindow } from '../components/ConnectionWindow';
-
-const Home: NextPage = () => {
- return (
- Connection Status
-
-
-
-
- );
-};
-
-export default Home;
-```
-
-For the purposes of this exercise, open `styles/Home.module.css` and **delete or comment out** `.main`. Doing so will move the content to the top of the page, which will prevent the RainbowKit modal from blocking your ability to see changes.
-
-Return to `ConnectionWindow.tsx` and add the `useAccount` hook to the top, where you'd add any state variables. The general pattern for wagmi hooks is you decompose the properties you want to use from a function call of the name of the hook. For some, you'll add a config object to that call, but it's not needed for this one.
-
-```tsx
-import { useAccount } from 'wagmi';
-
-export function ConnectionWindow() {
- const { address, isConnected, isConnecting, isDisconnected } = useAccount();
-
- return (
-
-
- );
-}
-```
-
-You can see all the deconstructable return options in the [UseAccountReturnType]:
-
-Update your `Connection Status
-` to show the address of the connected wallet:
-
-```tsx
-
-
-Change the list of chains to only include `baseSepolia` as the network option. You can set up your providers as described in [Introduction to Providers], or use the default from RainbowKit:
-
-```tsx
-const config = getDefaultConfig({
- appName: 'RainbowKit App',
- projectId: 'YOUR APP ID',
- chains: [baseSepolia],
- ssr: true,
-});
-```
-
-Be sure to set `ssr` to `true`, or you will get a [hydration error] from Next.js.
-
-
-
-Add the [`useAccount`] hook to the top of your component, where you'd add any state variables. The general pattern for wagmi hooks is you decompose the properties you want to use from a function call of the name of the hook. For some, you'll add a config object to that call, but it's not needed for this one.
-
-```tsx
-import { useAccount } from 'wagmi';
-
-export function ConnectionWindow() {
- const { address, isConnected, isConnecting, isDisconnected } = useAccount();
-
- return (
-
-
-Update your `
-
-```
-
-Test it out by connecting and disconnecting with your wallet. You should see your full address when you are connected, and the address will be `undefined` when you are disconnected.
-
-### Connection Status Conditional Rendering
-
-It isn't very nice to display a value of `undefined` to the user, so let's use the connection status values for conditional rendering depending on whether the user is disconnected, connected, or connecting.
-
-A common pattern is to use the conditional directly in the html return of a component or render function. For example, we could add a line to show that we're connecting as demonstrated:
-
-```
-Connection Status
-
-
-{'Address: ' + address}
-
-
-```
-
-Connect and disconnect your wallet a few times. The `isConnecting` state is true while the _Connect to website_ wallet UI is open.
-
-Autoconnect is enabled by default, so you'll need to clear the connection from your wallet settings to see this more than once. Otherwise, it will briefly flash as the auto-connect processes.
-
-Use the `connected` property in the same way to only render the wallet address if there is a wallet connected. Similarly, use the `isDisconnected` property to show a message asking the user to connect.
-
-```
-Connection Information
-
- {!isConnecting &&
-Please click Connect in your wallet...
} -{"Address: " + address}
-
-
-```
-
----
-
-## Conclusion
-
-In this guide, you've learned how the `useAccount` hook gives you access to information about the user's connection status and wallet. It can be used in any part of your app that is wrapped by the wagmi context provider. You've also learned a technique for conditional rendering based on connection status. Finally, you've learned to set the `ssr` flag to prevent hydration errors due to the client and server possessing different information about the user's connection status.
-
----
-
-[RainbowKit]: https://www.rainbowkit.com/
-[wagmi]: https://wagmi.sh/
-[quick start]: https://www.rainbowkit.com/docs/installation/
-[Wallet Connectors]: ../frontend-setup/wallet-connectors/
-[`useAccount`]: https://wagmi.sh/react/hooks/useAccount
-[hydration error]: https://nextjs.org/docs/messages/react-hydration-error
-[Introduction to Providers]: https://docs.base.org/cookbook/client-side-development/introduction-to-providers
-[UseAccountReturnType]: https://wagmi.sh/react/api/hooks/useAccount#return-type
-
-Connection Information
-
- {isConnecting &&
-Please click Connect in your wallet...
} - {isConnected &&{"Address: " + address}
} - {isDisconnected &&Please connect your wallet to use this app.
} -
-
- );
-}
-```
-Connection Status
-` to show the address of the connected wallet:
-
-```tsx
-
-Use the connection status values for conditional rendering depending on whether the user is disconnected, connected, or connecting.
-
-```tsx
-
-
-
diff --git a/docs/learn/onchain-app-development/reading-and-displaying-data/useReadContract.mdx b/docs/learn/onchain-app-development/reading-and-displaying-data/useReadContract.mdx
deleted file mode 100644
index 52e36ed11..000000000
--- a/docs/learn/onchain-app-development/reading-and-displaying-data/useReadContract.mdx
+++ /dev/null
@@ -1,463 +0,0 @@
----
-title: The `useReadContract` Hook
-description: Learn how to call view and pure functions from a smart contract.
-hide_table_of_contents: false
----
-
-# The `useReadContract` Hook
-
-The `useReadContract` hook is [wagmi]'s method of calling `pure` and `view` functions from your smart contracts. As with `useAccount`, `useReadContract` contains a number of helpful properties to enable you to manage displaying information to your users.
-
----
-
-## Objectives
-
-By the end of this guide you should be able to:
-
-- Implement wagmi's `useReadContract` hook to fetch data from a smart contract
-- Convert data fetched from a smart contract to information displayed to the user
-- Identify the caveats of reading data from automatically-generated getters
-
----
-
-## Contract Setup
-
-For this guide, you'll be continuing from the project you started for the [`useAccount` hook]. You'll work with an upgrade to the contract that you may have created if you completed the [ERC 20 Tokens Exercise]. See below for an example you can use if you don't already have your own!
-
-The contract creates a very simple DAO, in which users can create issues and vote for them, against them, or abstain. Anyone can `claim` 100 tokens. This is an insecure system for demonstration purposes, since it would be trivial to claim a large number of tokens with multiple wallets, then transfer them to a single address and use that to dominate voting.
-
-But it makes it much easier to test!
-
-
-If you're using your own contract, please redeploy it with the following `view` functions:
-
-```solidity
-function numberOfIssues() public view returns(uint) {
- return issues.length;
-}
-
-function getAllIssues() public view returns(ReturnableIssue[] memory) {
- ReturnableIssue[] memory allIssues = new ReturnableIssue[](issues.length);
-
- for(uint i = 0; i < issues.length; i++) {
- allIssues[i] = getIssue(i);
- }
-
- return allIssues;
-}
-```
-
-**You also need to make the `getIssue` function `public`. The original spec called for it to be `external`.**
-
-
-### Create Demo Issues
-
-To start, you'll need to put some data into your contract so that you can read it from your frontend. Open [Sepolia BaseScan], find your contract, connect with your wallet, and call the `claim` function.
-
-Add the following two issues:
-
-```text
-_issueDesc: We should enable light mode by default.
-_quorum: 2
-```
-
-```text
-_issueDesc: We should make inverted mouse controls the default selection.
-_quorum: 2
-```
-
-Switch to a **different wallet address**. Claim your tokens with the new address, and add one more issue:
-
-```text
-_issueDesc: Two spaces, not four, not tabs!
-_quorum: 2
-```
-
-Call the `getAllIssues` function under the `Read Contract` tab to make sure all three are there.
-
----
-
-## Reading from your Smart Contract
-
-To be able to read from your deployed smart contract, you'll need two pieces of information: the address and [ABI]. These are used as parameters in the `useReadContract` hook.
-
-If you're using [Hardhat], both of these can be conveniently found in a json file in the `deployments/` folder, named after your contract. For example, our contract is called `FEWeightedVoting`, so the file is `deployments/base-sepolia/FEWeightedVoting.json`.
-
-If you're using something else, it should produce a similar artifact, or separate artifacts with the [ABI] and address. If this is the case, make the adjustments you need when you import this data.
-
-Either way, add a folder called `deployments` and place a copy of the artifact file(s) inside.
-
-### Using the `useReadContract` Hook
-
-Add a file for a new component called `IssueList.tsx`. You can start with:
-
-```tsx
-import { useReadContract } from 'wagmi';
-
-export function IssueList() {
- return (
-
-Be very careful here! `bigint` is the name of the type, `BigInt` is the name of the constructor for that type. If you incorrectly use the constructor as the type, much of your code will still work, but other parts will express very confusing bugs.
-
-
-Now, import `useState` and add a state variable to hold your list of `Issue`s.
-
-```tsx
-const [issues, setIssues] = useState([]);
-```
-
-You'll also need to import your contract artifact:
-
-```tsx
-import contractData from '../deployments/FEWeightedVoting.json';
-```
-
-Finally, the moment you've been waiting for: Time to read from your contract! Add an instance of the [`useReadContract`] hook. It works similarly to the [`useAccount`] hook. Configure it with:
-
-```tsx
-const {
- data: issuesData,
- isError: issuesIsError,
- isPending: issuesIsPending,
-} = useReadContract({
- address: contractData.address as `0x${string}`,
- abi: contractData.abi,
- functionName: 'getAllIssues',
-});
-```
-
-You can use `useEffect` to do something when the call completes and the data. For now, just log it to the console:
-
-```tsx
-useEffect(() => {
- if (issuesData) {
- const issuesList = issuesData as Issue[];
- console.log('issuesList', issuesList);
- setIssues(issuesList);
- }
-}, [issuesData]);
-```
-
-Add in instance of your new component to `index.tsx`:
-
-```tsx
-
-
-```
-
-Run your app, and you should see your list of issues fetched from the blockchain and displayed in the console!
-
-
-
-
-
-Breaking down the hook, you've:
-
-- Renamed the properties decomposed from `useReadContract` to be specific for our function. Doing so is helpful if you're going to read from more than one function in a file
-- Configured the hook with the address and ABI for your contract
-- Made use of `useEffect` to wait for the data to be returned from the blockchain, log it to the console, and set the list of `Issue`s in state.
-
-### Displaying the Data
-
-Now that you've got the data in state, you can display it via your component. One strategy to display a list of items is to compile a `ReactNode` array in a render function.
-
-```tsx
-function renderIssues() {
- return issues.map((issue) => (
-
-If you use your own contract, redeploy it with the `numberOfIssues` and `getAllIssues` functions from the bottom of the contract below. We'll need this for our first pass solution for getting all the `Issues` in the contract.
-
-**You also need to make the `getIssue` function `public`. The original spec called for it to be `external`.**
-
-
-```Solidity
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.17;
-
-import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
-import "@openzeppelin/contracts/utils/structs/EnumerableSet.sol";
-
-contract FEWeightedVoting is ERC20 {
- using EnumerableSet for EnumerableSet.AddressSet;
-
- mapping(address => bool) claimed;
- uint public maxSupply = 1000000;
- uint totalClaimed;
-
- uint constant claimAmount = 100;
-
- error TokensClaimed();
- error AllTokensClaimed();
- error NoTokensHeld();
- error QuorumTooHigh(uint);
- error AlreadyVoted();
- error VotingClosed();
-
- enum Vote {
- AGAINST,
- FOR,
- ABSTAIN
- }
-
- struct Issue {
- EnumerableSet.AddressSet voters;
- string issueDesc;
- uint votesFor;
- uint votesAgainst;
- uint votesAbstain;
- uint totalVotes;
- uint quorum;
- bool passed;
- bool closed;
- }
-
- // EnumerableSets are mappings and cannot be returned outside a contract
- struct ReturnableIssue {
- address[] voters;
- string issueDesc;
- uint votesFor;
- uint votesAgainst;
- uint votesAbstain;
- uint totalVotes;
- uint quorum;
- bool passed;
- bool closed;
- }
-
- Issue[] issues;
-
- constructor(
- string memory _name,
- string memory _symbol
- ) ERC20(_name, _symbol) {
- // Burn Issue 0
- issues.push();
- }
-
- function claim() public {
- if (claimed[msg.sender] == true) {
- revert TokensClaimed();
- }
-
- if (totalSupply() >= maxSupply) {
- revert AllTokensClaimed();
- }
-
- _mint(msg.sender, claimAmount);
- claimed[msg.sender] = true;
- }
-
- function createIssue(
- string memory _issueDesc,
- uint _quorum
- ) public returns (uint) {
- if (balanceOf(msg.sender) == 0) {
- revert NoTokensHeld();
- }
-
- if (_quorum > totalSupply()) {
- revert QuorumTooHigh(_quorum);
- }
-
- Issue storage newIssue = issues.push();
- newIssue.issueDesc = _issueDesc;
- newIssue.quorum = _quorum;
- return issues.length - 1;
- }
-
- function getIssue(uint _id) public view returns (ReturnableIssue memory) {
- Issue storage issue = issues[_id];
- return
- ReturnableIssue(
- issue.voters.values(),
- issue.issueDesc,
- issue.votesFor,
- issue.votesAgainst,
- issue.votesAbstain,
- issue.totalVotes,
- issue.quorum,
- issue.closed,
- issue.passed
- );
- }
-
- function vote(uint _issueId, Vote _vote) public {
- Issue storage issue = issues[_issueId];
- if (issue.voters.contains(msg.sender)) {
- revert AlreadyVoted();
- }
- if (issue.closed) {
- revert VotingClosed();
- }
- issue.voters.add(msg.sender);
-
- if (_vote == Vote.FOR) {
- issue.votesFor += balanceOf(msg.sender);
- } else if (_vote == Vote.AGAINST) {
- issue.votesAgainst += balanceOf(msg.sender);
- } else if (_vote == Vote.ABSTAIN) {
- issue.votesAbstain += balanceOf(msg.sender);
- } else {
- revert("Error...");
- }
-
- issue.totalVotes += balanceOf(msg.sender);
-
- if (issue.totalVotes >= issue.quorum) {
- issue.closed = true;
- if (issue.votesFor > issue.votesAgainst) {
- issue.passed = true;
- }
- }
- }
-
- function numberOfIssues() public view returns(uint) {
- return issues.length;
- }
-
- function getAllIssues() public view returns(ReturnableIssue[] memory) {
- ReturnableIssue[] memory allIssues = new ReturnableIssue[](issues.length);
-
- for(uint i = 0; i < issues.length; i++) {
- allIssues[i] = getIssue(i);
- }
-
- return allIssues;
- }
-}
-```
-
----
-
-[RainbowKit]: https://www.rainbowkit.com/
-[wagmi]: https://wagmi.sh/
-[quick start]: https://www.rainbowkit.com/docs/installation/
-[Wallet Connectors]: ../frontend-setup/wallet-connectors/
-[`useAccount`]: https://wagmi.sh/react/hooks/useAccount
-[hydration error]: https://nextjs.org/docs/messages/react-hydration-error
-[ERC 20 Tokens Exercise]: https://docs.base.org/base-learn/docs/erc-20-token/erc-20-exercise
-[Sepolia BaseScan]: https://sepolia.basescan.org/
-[`useAccount` hook]: ./useAccount
-[Hardhat]: https://hardhat.org/
-[ABI]: https://docs.soliditylang.org/en/latest/abi-spec.html
-[`useReadContract`]: https://wagmi.sh/react/hooks/useReadContract
diff --git a/docs/learn/onchain-app-development/writing-to-contracts/useSimulateContract.mdx b/docs/learn/onchain-app-development/writing-to-contracts/useSimulateContract.mdx
deleted file mode 100644
index e16b217f8..000000000
--- a/docs/learn/onchain-app-development/writing-to-contracts/useSimulateContract.mdx
+++ /dev/null
@@ -1,110 +0,0 @@
----
-title: The `useSimulateContract` hook
-description: Improve your user experience with the `useSimulateContract` hook.
-hide_table_of_contents: false
----
-
-# The `useSimulateContract` hook
-The [`useSimulateContract`] hook simulates and validates a contract interaction without actually sending a transaction to the blockchain. Using it allows you to detect and respond to potential errors before the user tries to send a transaction.
-
----
-
-## Objectives
-
-By the end of this guide you should be able to:
-
-- Implement wagmi's `useSimulateContract` and `useWriteContract` to send transactions to a smart contract
-- Configure the options in `useSimulateContract` and `useWriteContract`
-- Call a smart contract function on-demand using the write function from `useWriteContract`, with arguments and a value
-
----
-
-## Refining the Claim Component
-
-In the previous step-by-step, you used [`useWriteContract`] to set up a hook you can use to call the `claim` function in your smart contract when the user clicks a button. The component works well enough, but it can take a long time for the wallet to pop up, particularly if there is network congestion. You also have no way of responding to a problem with the transaction inputs until after the user tries to initiate a transaction.
-
-### Using `useSimulateContract`
-
-The `useSimulateContract` can be used in partnership with `useWriteContract`. To do so, you set up the transaction parameters in `useSimulateContract`, then use the `data?.request` returned by it as an argument in the call to write to the contract. Modify your `TokenInfo` component to test it:
-
-```tsx
-const {
- data: claimData,
- isFetching: claimIsFetching,
- isError: claimIsError,
-} = useSimulateContract({
- address: contractData.address as `0x${string}`,
- abi: contractData.abi,
- functionName: 'claim',
-});
-
-useEffect(() => {
- if (claimIsError) {
- alert('Unable to claim'); // TODO: Better error handling
- }
-}, [claimIsError]);
-
-const { writeContract: claim, isPending: claimIsPending } = useWriteContract();
-
-const handleClaimClick = () => {
- claim(claimData?.request);
-};
-```
-
-You'll also need to update your handler to use the TypeScript pre-check feature, because the claim function will be briefly `undefined`.
-
-```tsx
-const handleClaimClick = () => {
- claim(claimData!.request);
-};
-```
-
-Reload the site and observe that the `alert` is triggered on load if you're signed in with an address that has already claimed tokens. You'll also see that the button is disabled, as though the user had clicked it and a transaction is loading in the wallet.
-
-### Making Adjustments
-
-The reason for this is a subtle difference in how `useWriteContract` and `useSimulateContract` work.
-
-In the last step-by-step, you saw how viem runs a simulation of the transaction when the `write` function is called. `useSimulateContract` eagerly runs this simulation and updates it's variables.
-
-You'll need to make some modifications for it to work. The `claimIsError` variable is being triggered when the data for the call is **simulated**, not when the call has settled. As a result, it immediately generates the error, and triggers the `alert` without requiring the user to click the button.
-
-You can solve this a number of ways, including simply not rendering the button if the user has already claimed. You could also modify the code, and combine it with `isError`, to share this information to the user.
-
-```tsx
-const {
- data: claimData,
- isFetching: claimIsFetching,
- isError: claimIsError,
-} = useSimulateContract({
- address: contractData.address as `0x${string}`,
- abi: contractData.abi,
- functionName: 'claim',
-});
-
-const { writeContract: claim, isPending: claimIsPending } = useWriteContract();
-
-return (
-
-In this step-by-step, you're going to start with the [`useWriteContract`] hook. You probably won't want to use this method in production. In the next step-by-step, we'll show you the [`useSimulateContract`] hook, how it works with `useWriteContract`, and how you can use it to create a better user experience.
-
-Exploring them separately will highlight the functionality provided by the prepare hook.
-
-
-
-In this module, you'll extend the onchain app you build in the previous module, [Reading and Displaying Data].
-
-
-You've built an app that can read from your Simple DAO smart contract, but so far, you've used BaseScan to send transactions that call your write functions. You can use the [`useWriteContract`] hook in a similar way to call those functions directly from your app.
-
-### Setting up the Component
-
-Add a new component called `TokenInfo` to the project, and a state variable for `tokenBalance`.
-
-```tsx
-import { useState } from 'react';
-
-export function TokenInfo() {
- const [tokenBalance, setTokenBalance] = useState(0);
-}
-```
-
-### Reading the Token Balance
-
-You'll need to know how many tokens the user has to be able to make decisions on what UI controls to display, so start by adding a `useReadContract`. You don't have a function for this directly in your contract, but your contract inherits from the [OpenZeppelin ERC20] contract, which has a function called `balanceOf` that takes an address and returns the balance for that address.
-
-You'll need the user's address to use in `args`, which you can conveniently get from the [`useAccount`] hook using the pattern below.
-
-```tsx
-const { data: balanceData, queryKey: balanceQueryKey } =
- useReadContract({
- address: contractData.address as `0x${string}`,
- abi: contractData.abi,
- functionName: "balanceOf",
- args: [useAccount().address],
- });
-
-useEffect(() => {
- if (balanceData) {
- setTokenBalance(balanceData as number);
- }
-}, [balanceData]);
-
-useEffect(() => {
- queryClient.invalidateQueries({ queryKey: balanceQueryKey });
-}, [blockNumber, queryClient]);
-```
-
-
-Remember, this is an expensive method to watch for data to change on the blockchain. In this case, a more production-suitable solution might be to call `balanceOf` after the user has done something that might change the balance.
-
-
-Set the `return` for your component to display this balance to the user:
-
-```tsx
-return (
-
-
-```
-Test it out by connecting and disconnecting with your wallet. You should see your full address when you are connected, and the address will be `undefined` when you are disconnected.
-
-Connection Status
-
-
-{'Address: ' + address}
-
-
-```
-Connection Information
-
- {isConnecting &&
-Please click Connect in your wallet...
} - {isConnected &&{"Address: " + address}
} - {isDisconnected &&Please connect your wallet to use this app.
} -
-
- );
-}
-```
-
-You'll need to do some prepwork to enable Typescript to more easily interpret the data returned from your contract. Add an `interface` called `Issue` that matches with the `ReturnableIssue` type:
-
-```tsx
-interface Issue {
- voters: string[];
- issueDesc: string;
- votesFor: bigint;
- votesAgainst: bigint;
- votesAbstain: bigint;
- totalVotes: bigint;
- quorum: bigint;
- passed: boolean;
- closed: boolean;
-}
-```
-
-All Issues
-{/* TODO: List each issue */}
-
-
- ));
-}
-```
-
-Then, call the render function in the return for your component:
-
-```tsx
-return (
- {issue.issueDesc}
-{'Voters: ' + issue.voters.toString()}
-{'Votes For: ' + issue.votesFor.toString()}
-{'Votes Against: ' + issue.votesAgainst.toString()}
-{'Votes Abstain: ' + issue.votesAbstain.toString()}
-{'Quorum: ' + issue.quorum.toString()}
-{'Passed: ' + issue.passed}
-{'Closed: ' + issue.closed}
-
-
-);
-```
-
-You'll now see your list of issues rendered in the browser! Congrats, you've finally made a meaningful connection between your smart contract and your frontend!
-
-### A Caveat with Automatic Getters
-
-Remember how the Solidity compiler creates automatic getters for all of your public state variables? This feature is very helpful, but it can create bewildering results when you use it for `struct`s that contain `mapping`s. Remember, nesting mappings **cannot** be returned outside the blockchain. The `enumerableSet` protects you from this problem, because it has private variables inside it, which prevents setting `issues` as `public`. Had we instead used a mapping, we'd lose this protection:
-
-```solidity
- // Code for demo only
- struct Issue {
- mapping(address => bool) voters;
- string issueDesc;
- uint votesFor;
- uint votesAgainst;
- uint votesAbstain;
- uint totalVotes;
- uint quorum;
- bool passed;
- bool closed;
- }
-```
-
-Redeploy with the above change, and add a second `useReadContract` to fetch an individual issue using the getter:
-
-```tsx
-// Bad code for example, do not use
-const {
- data: getOneData,
- isError: getOneIsError,
- isPending: getOneIsPending,
-} = useReadContract({
- address: contractData.address as `0x${string}`,
- abi: contractData.abi,
- functionName: 'issues',
- args: [1],
-});
-
-useEffect(() => {
- if (getOneData) {
- console.log('getOneData', getOneData);
- const issueOne = getOneData as Issue;
- console.log('Issue One', issueOne);
- }
-}, [getOneData]);
-```
-
-Everything appears to be working just fine, but how is `issueOne.desc` undefined? You can see it right there in the log!
-
-
-
-
-
-If you look closely, you'll see that `voters` is missing from the data in the logs. What's happening is that because the nested `mapping` cannot be returned outside the blockchain, it simply isn't. TypeScript then gets the `data` and does the best it can to cast it `as` an `Issue`. Since `voters` is missing, this will fail and it instead does the JavaScript trick of simply tacking on the extra properties onto the object.
-
-Take a look at the working example above where you retrieved the list. Notice that the keys in your `Issue` type are in that log, but are missing here. The assignment has failed, and all of the `Issue` properties are `null`.
-
----
-
-## Conclusion
-
-In this guide, you've learned how to use the `useReadContract` hook to call `pure` and `view` functions from your smart contracts. You then converted this data into React state and displayed it to the user. Finally, you explored a tricky edge case in which the presence of a nested `mapping` can cause a confusing bug when using the automatically-generated getter.
-
----
-
-## Simple DAO Contract Example
-
-Use this contract if you don't have your own from the [ERC 20 Tokens Exercise]. You can also use this if you want to cheat to get that badge. Doing so would be silly though!
-
-All Issues
-{renderIssues()}
-
-
-);
-```
-
----
-
-## Conclusion
-
-In this step-by-step, you updated your app to use the `useSimulateContract` hook to provide a speedier wallet interaction for your users. You've also learned how you can predict and respond to potential errors without the user needing to attempt to send a transaction. You could use this functionality to let them know a username is already taken, a bid amount is not large enough, or an item is no longer available.
-
----
-
-[wagmi]: https://wagmi.sh/
-[`useWriteContract`]: https://wagmi.sh/react/hooks/useWriteContract
-[`useSimulateContract`]: https://wagmi.sh/react/hooks/useSimulateContract
-
diff --git a/docs/learn/onchain-app-development/writing-to-contracts/useWriteContract.mdx b/docs/learn/onchain-app-development/writing-to-contracts/useWriteContract.mdx
deleted file mode 100644
index da013c86a..000000000
--- a/docs/learn/onchain-app-development/writing-to-contracts/useWriteContract.mdx
+++ /dev/null
@@ -1,155 +0,0 @@
----
-title: The `useWriteContract` hook
-description: Write to your smart contracts with the `useWriteContract` hook.
-hide_table_of_contents: false
----
-
-# The `useWriteContract` hook
-
-The [`useWriteContract`] hook allows you to call your `public` and `external` smart contract functions that write to state and create a permanent modification to the data on chain.
-
----
-
-## Objectives
-
-By the end of this guide you should be able to:
-
-- Implement wagmi's `useWriteContract` hook to send transactions to a smart contract
-- Configure the options in `useWriteContract`
-- Display the execution, success, or failure of a function with button state changes, and data display
-
----
-
-## Sending a Transaction to the Blockchain
-
-{claimIsFetching.toString()}
-{'Token Balance: ' + tokenBalance}
- -{claimIsError ? 'Unable to claim tokens.' : 'Claim your tokens!'}
-
-
-);
-```
-
-Then, add the component to your app in `index.tsx`.
-
-```tsx
-return (
- {'Token Balance: ' + tokenBalance}
-
-
-
-);
-```
-
-Run the app and make sure you see the expected balance displayed on the page.
-
-### Setting up `useWriteContract`
-
-The [`useWriteContract`] hook is configured similarly to the [`useReadContract`] hook, with one important difference. You'll need to decompose the `write` property from the function call. This is a function that you can use to call your smart contract function whenever you'd like!
-
-```tsx
-const { writeContract: claim, isPending: claimIsPending } = useWriteContract();
-```
-
-Add an event handler function and a button. As with the `useReadContract` hook, you can use `isPending` and other state helpers to adjust your UI. The name of this one is a little misleading. `isPending` will be `true` starting from the moment the transaction gets sent to the user's wallet.
-
-You can use this to nudge them to look to their wallet to complete the transaction. Additionally, add a `useEffect` to watch for an error state.
-
-```tsx
-const handleClaimClick = () => {
- claim({
- abi: contractData.abi,
- address: contractData.address as `0x${string}`,
- functionName: 'claim',
- });
-};
-
-return (
-
-**AI + Blockchain Challenge**: AI agents can read the web, but they typically can't manage crypto or execute onchain tasks.
-
-
-
-**AgentKit Solution**: Gives AI agents "economic agency" by integrating them with onchain wallets, letting them deploy contracts, transfer tokens, and carry out tasks on Base autonomously. Bridge AI (LLMs) with crypto in a secure, straightforward way.
-
diff --git a/docs/learn/onchain-concepts/building-onchain-frontend-development.mdx b/docs/learn/onchain-concepts/building-onchain-frontend-development.mdx
deleted file mode 100644
index 2f4b780c9..000000000
--- a/docs/learn/onchain-concepts/building-onchain-frontend-development.mdx
+++ /dev/null
@@ -1,34 +0,0 @@
----
-title: "Connecting Your Frontend"
-description: "Learn how onchain frontends differ from Web2 by managing wallet connections, displaying real-time onchain data, and handling transaction flows using OnchainKit, wagmi, and Viem."
----
-
-Unlike Web2 frontends that primarily handle user input and REST API calls, onchain frontends must manage wallet connections, display onchain data in real time, and handle transaction flows. Fortunately, libraries like OnchainKit, wagmi, and Viem help you abstract away much of the complexity. Here, you'll learn how to easily support multiple wallet types, show transaction status, and seamlessly integrate onchain actions into a modern UI.
-
-## What's Unique for Onchain Frontends?
-
-
-Onchain frontends must handle unique requirements that don't exist in traditional Web2 applications:
-- Wallet connections (Coinbase Wallet,MetaMask, Smart Wallet, etc.)
-- Contract calls and transaction state management
-- Token and NFT interactions
-
-
-## OnchainKit
-
-OnchainKit provides a comprehensive set of React components and TypeScript utilities for building onchain applications:
-
-
-**Wallet Connection Flows**: Supporting multiple wallet types seamlessly
-
-
-
-**Common Onchain Actions**: Swapping tokens, minting NFTs, sending transactions
-
-
-
-**Integration Ready**: Works with popular client libraries like [wagmi](https://wagmi.sh/react/getting-started) and [Viem](https://viem.sh/docs/getting-started), connecting to the Base Node under the hood so you don't worry about low-level RPC details
-
-
-[wagmi]: https://wagmi.sh/react/getting-started
-[Viem]: https://viem.sh/docs/getting-started
diff --git a/docs/learn/onchain-concepts/building-onchain-gas.mdx b/docs/learn/onchain-concepts/building-onchain-gas.mdx
deleted file mode 100644
index d5e50468b..000000000
--- a/docs/learn/onchain-concepts/building-onchain-gas.mdx
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: "Paying for Onchain Transactions (Gas)"
-description: "Learn how Paymaster services address gas fee barriers by sponsoring transactions or allowing users to pay fees in alternative tokens, improving user onboarding on Base."
----
-
-Transactions on blockchain networks typically require "gas" fees, which can be a major hurdle for new users without pre-funded wallets. Paymaster services address this by letting developers sponsor gas or allowing users to pay fees in tokens other than ETH. In this sub-section, we explore how Paymaster works on Base, how it improves user onboarding, and how you can implement it in your own application.
-
-## The Challenge
-
-
-**Gas Fee Barriers**: Users must have gas tokens (ETH on Base) to pay fees. This can be a significant hurdle for newcomers who have zero crypto.
-
-
-## Paymaster Solution
-
-
-Paymaster is a service that sponsors gas fees on behalf of users, enabling gasless transactions. This allows your users to transact without needing ETH in their wallet, or to pay gas in alternative tokens like USDC.
-
-
-
-Base's [Paymaster solution](https://www.coinbase.com/developer-platform/products/paymaster) (via CDP) streamlines onboarding and can significantly improve user experience.
-
diff --git a/docs/learn/onchain-concepts/building-onchain-identity.mdx b/docs/learn/onchain-concepts/building-onchain-identity.mdx
deleted file mode 100644
index 2482ea9eb..000000000
--- a/docs/learn/onchain-concepts/building-onchain-identity.mdx
+++ /dev/null
@@ -1,41 +0,0 @@
----
-title: "Giving Onchain Accounts an Identity"
-description: "Learn how Basenames and onchain verifications make blockchain addresses human-readable and trustworthy, improving user experience and app functionality."
----
-
-While blockchains publicly display wallet addresses by default, these long strings are not friendly for everyday use. Onchain naming systems like Basenames solve this by letting users register human-readable names (for example, "alice.base"). Beyond simple naming, onchain identity can be extended through verifications and attestations that prove additional facts (e.g., that a user is a verified account holder or resides in a specific country). Here, you'll learn how Basenames and onchain verifications work together to make your app more user-friendly and trustworthy.
-
-## Why Identity Matters
-
-
-**Address Readability**: By default, wallet addresses are long, unreadable hex strings. Onchain names (like "alice.base") make it easier to identify recipients or users.
-
-
-
-**Trust Without Privacy Risk**: Attestations/Verifications allow your app to trust certain user attributes—without exposing personal data offchain.
-
-
-## Basenames
-
-
-**Human-Readable Names** for addresses on Base (akin to DNS for IPs)
-
-
-
-**Unified Identity**: Users can register names, add a profile picture, and display them across all apps they connect to
-
-
-
-**Reduced Friction**: Helps unify an onchain identity and reduce user friction
-
-
-## Onchain Verifications
-
-
-**The Challenge**: The chain can't natively see offchain data (e.g., your nationality or membership status).
-
-
-
-**The Solution**: Verifications let you post attestations **onchain** so other contracts can read them without privacy risks. For example, prove you're a Coinbase user, or a resident of a certain country, and automatically unlock special privileges in dapps.
-
-
diff --git a/docs/learn/onchain-concepts/building-onchain-nodes.mdx b/docs/learn/onchain-concepts/building-onchain-nodes.mdx
deleted file mode 100644
index fca22af15..000000000
--- a/docs/learn/onchain-concepts/building-onchain-nodes.mdx
+++ /dev/null
@@ -1,75 +0,0 @@
----
-title: "Interacting with the Chain (Node Access)"
-description: "Learn how blockchain node access works via RPC endpoints, comparing self-hosted vs hosted options, and how to integrate Base Node for stable onchain interactions."
----
-
-Every time you read or write data on Base, you're making calls to a blockchain node via RPC (Remote Procedure Call) endpoints. You can host your own node or rely on a service like Base Node (via CDP). This sub-section explains why node access is crucial, compares self-hosted vs. hosted node options, and shows you how to integrate an RPC endpoint in your application for stable, scalable onchain interactions.
-
-## Why You Need a Node
-
-
-Under the hood, apps read/write onchain data by making RPC calls to a blockchain node. You can self-host or use a managed service.
-
-
-Every blockchain interaction requires communication with a node that maintains the complete blockchain ledger. Whether you're checking wallet balances, sending transactions, or reading smart contract state, your application communicates through standardized JSON-RPC methods like `eth_getBalance`, `eth_sendTransaction`, and `eth_call`.
-
-## RPC Endpoints Overview
-
-Base provides public RPC endpoints for development and testing:
-
-| Network | RPC Endpoint | Chain ID | Use Case |
-| :------ | :----------- | :------- | :------- |
-| Base Mainnet | `https://mainnet.base.org` | 8453 | Development only |
-| Base Sepolia | `https://sepolia.base.org` | 84532 | Testing only |
-
-
-These public endpoints are **rate-limited** and **not suitable for production systems**. For production applications, use a dedicated node provider or run your own node.
-
-
-## Hosted Node Providers
-
-For production applications, choose from Base's ecosystem of trusted node providers:
-
-### Coinbase Developer Platform (CDP)
-**Base Node** (via CDP) provides high-throughput access with a free tier available, plus enterprise-grade options. Built on the same infrastructure powering Coinbase's retail exchange for maximum reliability.
-
-### Popular Provider Options
-- **Alchemy**: Enhanced features, SDKs, free tier with robust JSON-RPC APIs
-- **QuickNode**: Discover Plan with optional "Trace Mode" and "Archive Mode" add-ons
-- **Chainstack**: Elastic RPC nodes with geographically diverse, protected API endpoints
-- **Ankr**: Globally distributed decentralized network with free and paid tiers
-- **OnFinality**: High-performance archive access with generous free tier and high rate limits
-- **Dwellir**: Archive RPC access with a 25 million response free tier
-
-
-Most providers offer both mainnet and testnet (Sepolia) access. Compare pricing, rate limits, and features like archive data access when selecting a provider.
-
-
-## Self-Hosted Base Node
-
-### When to Run Your Own Node
-Consider self-hosting when you need:
-- Complete control over node configuration
-- No external dependencies or rate limits
-- Archive data access for historical queries
-- Custom monitoring and analytics
-
-### Hardware Requirements
-Running a Base node requires significant resources:
-
-- **CPU**: 8-Core processor with good single-core performance
-- **RAM**: Minimum 16 GB (32 GB recommended)
-- **Storage**: NVMe SSD with adequate capacity for chain data plus snapshots
- - Calculate: `(2 × current_chain_size) + snapshot_size + 20% buffer`
-- **Network**: Stable internet connection with good bandwidth
-
-
-Running a node is **time-consuming**, **resource-expensive**, and **potentially costly**. Syncing can take days and consume significant bandwidth.
-
-
-### Performance Considerations
-- **Reth vs Geth**: Reth provides significantly better performance in Base's high-throughput environment
-- **Archive Nodes**: Geth archive nodes are no longer supported; use Reth for archive functionality
-- **Snapshots**: Weekly snapshots available to accelerate initial sync process
-- **Storage**: Local NVMe SSDs strongly recommended over networked storage
-
diff --git a/docs/learn/onchain-concepts/building-onchain-onramps.mdx b/docs/learn/onchain-concepts/building-onchain-onramps.mdx
deleted file mode 100644
index 6eb488154..000000000
--- a/docs/learn/onchain-concepts/building-onchain-onramps.mdx
+++ /dev/null
@@ -1,22 +0,0 @@
----
-title: "Funding Wallets (Onramps)"
-description: "Learn how onramps like MagicSpend and CDP Onramp solve the fiat-to-crypto conversion challenge, enabling smooth user onboarding with FundButton components."
----
-
-Before users can transact on Base, they need crypto in their wallets. Historically, this required lengthy steps via exchanges and bank transfers. Now, onramps like MagicSpend and CDP Onramp (and the drop-in FundButton components from OnchainKit) make this process faster and smoother. In this sub-section, discover how to integrate user-friendly fiat-to-crypto solutions directly into your app, reducing churn and lowering barriers to entry.
-
-## The Funding Challenge
-
-
-**User Barrier**: A user can't easily transact unless they have some crypto in their wallet. Traditional workflows are clunky (bank → CEX → withdraw to wallet).
-
-
-## Base Onramp Solutions
-
-
-**MagicSpend** and **CDP Onramp** enable quick conversions from fiat to onchain funds without forcing users to leave your app.
-
-
-
-**Easy Integration**: Components like **FundButton** or **FundCard** in OnchainKit let you drop in funding flows directly into your user interface.
-
diff --git a/docs/learn/onchain-concepts/building-onchain-social-networks.mdx b/docs/learn/onchain-concepts/building-onchain-social-networks.mdx
deleted file mode 100644
index c31dfcf40..000000000
--- a/docs/learn/onchain-concepts/building-onchain-social-networks.mdx
+++ /dev/null
@@ -1,52 +0,0 @@
----
-title: "Onchain Social Networks"
-description: "Discover how onchain social networks like Farcaster enable apps to tap into existing social graphs, solving the 'empty network' problem for new social applications."
----
-
-Traditional social media apps must build their user bases from scratch and can risk losing access to platform APIs. In contrast, onchain social networks (e.g., Farcaster) allow your app to tap into existing social graphs and user relationships immediately. This part covers how open social protocols foster collaboration, prevent centralized gatekeeping, and eliminate the "empty network" problem for new social apps.
-
-## Open Social Layers
-
-
-**Instant Network Effect**: Rather than building siloed social graphs from scratch, you can tap into existing onchain social networks like Farcaster.
-
-
-
-**Immediate Access**: If your user is on Farcaster, your app automatically gains access to their followers, social feed, and social connections.
-
-
-
-**Solves Empty Network Problem**: This provides content and user relationships from day one, eliminating the classic "empty network" challenge.
-
-
-## Mini Apps
-
-Mini Apps are lightweight web applications that run natively within Farcaster clients, providing rich interactive experiences without requiring users to leave their social feeds.
-
-### What Makes Mini Apps Powerful
-- **Native Integration**: Launch instantly from social posts without downloads or redirects
-- **Social Context**: Automatic access to user identity, connections, and social graph
-- **Onchain Capabilities**: Direct wallet connections and blockchain interactions
-- **Cross-Platform**: Works in Farcaster clients like Farcaster and Coinbase Wallet
-
-
-### Mini App Capabilities
-**User Interactions**
-- Send notifications to users who have added your app
-- Access user's Farcaster identity and social connections
-- Enable users to share content back to their feeds
-
-**Onchain Integration**
-- Direct wallet connections within the social context
-- Execute transactions without leaving the app
-- Integration with Base blockchain and DeFi protocols
-
-**Social Features**
-- Compose and share casts from within your app
-- View and interact with user profiles
-- Access social graph data for personalized experiences
-
-
-**Viral Distribution**: Mini Apps spread organically through social sharing, providing built-in user acquisition as users share their experiences directly in their social feeds.
-
-
diff --git a/docs/learn/onchain-concepts/building-onchain-wallets.mdx b/docs/learn/onchain-concepts/building-onchain-wallets.mdx
deleted file mode 100644
index 1f84b0f76..000000000
--- a/docs/learn/onchain-concepts/building-onchain-wallets.mdx
+++ /dev/null
@@ -1,46 +0,0 @@
----
-title: "Onchain Accounts (Wallets)"
-description: "Learn about onchain accounts, from traditional EOAs using private keys to modern Smart Wallets with passkeys, and how Base's Smart Wallet SDK simplifies integration."
----
-
-Onchain accounts, often called "wallets", are the starting point for any onchain interaction. Unlike traditional accounts that store credentials in a database, onchain accounts authenticate and authorize transactions on the public network with credentials held by the user. The original onchain accounts (EOA's) use private keys backed up by a sequence of 24 random words. Recently, with the introduction of modern accounts like Smart Wallet, the credentials are Passkeys which provide improved security and recoverability. This sub-section covers these two main wallet types, the differences in user experience and security, and how Base's Smart Wallet SDK makes them easier to integrate.
-
-## What's Different?
-
-
-Every onchain action requires an account (a wallet) to sign transactions. Onchain accounts can **hold funds** and also **authorize** transactions on a blockchain.
-
-
-## Types of Onchain Accounts
-
-### Externally Owned Accounts (EOAs)
-
-
-**Traditional Model**: Private key + seed phrase model (e.g., MetaMask, Rabby, Ledger)
-
-
-
-**User Experience**: Commonly used today but can be cumbersome or risky for new users
-
-
-
-**Capabilities**: Holds digital assets but has no account level logic. Required for deploying smart contracts.
-
-
-### Smart Wallets
-
-
-**Modern Approach**: Modern accounts with their own logic enabling improved security, recoverability, and functionality.
-
-
-
-**Enhanced Features**: Built-in recovery features, passkey authentication, and improved onboarding experience for users
-
-
-
-**Advanced Permissions**: Can include features like "SpendPermissions" for fine-grained security and improved user experience
-
-
-## Learn More
-
-If you'd like a deeper dive on EOAs vs. smart wallets, check out our [Smart Wallet docs](/smart-wallet/concepts/what-is-smart-wallet) and recommended reading on [Account Abstraction](https://www.alchemy.com/learn/account-abstraction). Base provides an [SDK](/smart-wallet/technical-reference/sdk) to help you integrate Smart Wallets easily.
diff --git a/docs/learn/onchain-concepts/continue-building-onchain.mdx b/docs/learn/onchain-concepts/continue-building-onchain.mdx
deleted file mode 100644
index 18fc36d7c..000000000
--- a/docs/learn/onchain-concepts/continue-building-onchain.mdx
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: "Final Thoughts & Next Steps"
-description: "Take your next steps in building onchain with Base's tools including Base Node, OnchainKit, Paymaster, AgentKit, and Basenames for complete onchain development."
----
-
-Building onchain with Base brings a new dimension to your apps—trust-minimized logic, global accessibility, and open integrations with existing ecosystems (DeFi, social, AI, etc.). Now that you have the big picture, here are some suggested next steps:
-
-* [Spin up your first Base Node endpoint](https://portal.cdp.coinbase.com/products/node)
-* [Use OnchainKit to build a basic wallet connection flow](https://onchainkit.xyz/)
-* [Integrate Paymaster for gasless transactions](https://docs.cdp.coinbase.com/paymaster/docs/welcome)
-* [Explore AI Onchain with AgentKit](https://docs.cdp.coinbase.com/agentkit/docs/welcome)
-* [Set up your Basename for a friendlier identity](https://www.base.org/names)
-
-Happy Building!
diff --git a/docs/learn/onchain-concepts/core-concepts.mdx b/docs/learn/onchain-concepts/core-concepts.mdx
deleted file mode 100644
index 4f4c6bec0..000000000
--- a/docs/learn/onchain-concepts/core-concepts.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-title: "Core Concepts"
-description: "Learn the unique aspects of building onchain applications with Base's tools like OnchainKit, Paymaster, and Smart Wallet to tap into global payment networks and blockchain ecosystems."
----
-
-Building onchain means tapping into a global, fast, and cheap payment network, plus a thriving ecosystem of NFTs, games, social networks, and more. This section will introduce the **unique aspects** of building onchain and show you **how Base's tools** (e.g., OnchainKit, Paymaster, Smart Wallet, etc.) simplify that process.
-
-If you'd like to learn more about the broader vision and benefits, check out Why Base. If you want to **start building right away**, visit our Quickstart.
-
-We will cover the following:
-
-- [The Onchain Tech Stack](understanding-the-onchain-tech-stack)
-- [Unique aspects of building onchain (and the tools that help)](onchain-aspects)
- - [Onchain Accounts (Wallets)](building-onchain-wallets)
- - [Onchain Identity](building-onchain-identity)
- - [Paying for transactions](building-onchain-gas)
- - [Connecting your Frontend](building-onchain-frontend-development)
- - [Funding Wallets (Onramps)](building-onchain-onramps)
- - [Onchain Social Networks](building-onchain-social-networks)
- - [AI Onchain](building-onchain-ai)
-- [The Onchain Development Flow](development-flow)
diff --git a/docs/learn/onchain-concepts/development-flow.mdx b/docs/learn/onchain-concepts/development-flow.mdx
deleted file mode 100644
index 5d7404633..000000000
--- a/docs/learn/onchain-concepts/development-flow.mdx
+++ /dev/null
@@ -1,90 +0,0 @@
----
-title: "The Development Flow"
-description: "Learn the different approaches to onchain development, from client-side apps using OnchainKit to smart contract development with Hardhat and Foundry."
----
-
-## Client-side Development
-
-If you're focusing on the front end or building a user interface, Kits like OnchainKit provide an opinionated, model-agnostic setup for handling user authentication, contract interactions, and transaction status updates. With a client-side approach:
-
-
-
- Configure an RPC endpoint to read chain data and interact with the blockchain.
-
-
-
- Use OnchainKit (or an equivalent framework) to handle function calls, sign messages, or sponsor gas if you've integrated Paymaster solutions.
-
-
-
- Add Identity Solutions like Basenames or Onchain Profiles for more user-friendly experiences.
-
-
-
-
-## Smart Contract Development
-
-Base is an EVM-equivalent chain, so you can build or reuse your smart contracts written in Solidity. Smart wallets, Paymaster services, and other infrastructure components on Base can significantly streamline the user experience around your onchain programs.
-
-
-
- Select a development environment such as Hardhat or Foundry.
-
-
-
- Write and compile your contracts in Solidity.
-
-
-
- Test locally or on a testnet before pushing to mainnet.
-
-
-
- Deploy to Base using your EOA wallet (or specialized deployment tooling).
-
-
-
-### Smart Contract Guides
-
-
-
- Quickstart: Deploy on Base
-
-
-
- Foundry Tutorial
-
-
-
- Base Learn: Development with HardHat
-
-
-
- Base Learn: Development with Foundry
-
-
-
- Verify a Smart Contract using Basescan API
-
-
-
-## Developer Environments
-
-Base offers multiple environments to help you iterate quickly:
-
-
-
-**Production Environment**
-Where real-value transactions occur. Use for live applications.
-
-
-
-**Base testnet on Sepolia**
-Great for QA or staging. Test your applications without real value.
-
-
-
-**Local EVM Environment**
-You can run a local EVM environment with Hardhat or similar tools to test your contracts before deploying.
-
-
diff --git a/docs/learn/onchain-concepts/understanding-the-onchain-tech-stack.mdx b/docs/learn/onchain-concepts/understanding-the-onchain-tech-stack.mdx
deleted file mode 100644
index d4155fa96..000000000
--- a/docs/learn/onchain-concepts/understanding-the-onchain-tech-stack.mdx
+++ /dev/null
@@ -1,73 +0,0 @@
----
-title: "Understanding Onchain in Your Tech Stack"
-description: "Learn how blockchain technology augments traditional web stacks by adding globally accessible logic and data through smart contracts and onchain state."
----
-
-In broad strokes, a traditional web application has a frontend, a backend, and a database. When we talk about "building onchain," we're adding a **blockchain** to that tech stack as globally accessible infrastructure that can provide both **logic** (smart contracts) and **data** (onchain state).
-
-## Traditional vs Onchain Architecture
-
-
-
-- **Frontend**: Usually React, Vue, or another framework
-- **Backend**: Node.js, Python, or similar, handling business logic
-- **Database**: A solution like Postgres or MongoDB for persistent storage
-
-
-
-- **Smart Contracts**: Globally accessible logic
-- **Onchain State**: Data that lives on Base (balances, user profiles, etc.) and is accessible to any onchain or offchain application
-
-
-
-
-Integrating a blockchain doesn't necessarily **replace** your database or your entire backend. Instead, it augments your stack. For instance, some business logic might remain in your backend, and sensitive data may remain in a traditional database.
-
-
-## What belongs onchain?
-
-## Onchain State
-
-Onchain state has several notable properties:
-
-
-**Immutable**: Once recorded, data can't be deleted ensuring a permanent historical record
-
-
-
-**Transparent**: All data is publicly viewable and verifiable
-
-
-
-**Global**: Data is stored across multiple nodes, eliminating single points of failure
-
-
-
-**Expensive**: Storing data onchain is expensive because it must be stored by every node globally
-
-
-Because of these properties, carefully consider what data is stored onchain. Ask yourself if the data is necessary for onchain logic or if the data should be immutable. Alternatively, you may be able to store your data offchain in a traditional database or a decentralized file storage network such as [IPFS](https://ipfs.tech/). If the state change is more informational, it may be best to emit an event, providing a more cost-effective alternative to direct onchain storage.
-
-## Onchain Events
-
-
-Since storing data onchain is expensive, we oftentimes use a cheaper alternative: events. Events are not part of the state, which makes them optional to store when running a node. They are a lot cheaper to use than state storage.
-
-
-Events are triggered when an onchain method is called. Events can have different data formats. In order to make sure events follow the format we are looking to receive on the frontend, we often use data indexers. For that, you can build your own indexer or use one of the [existing tools](/base-chain/tools/data-indexers).
-
-## Onchain Logic
-
-Onchain logic is stored in smart contracts. Similar to onchain data, it is immutable, transparent, and global. By default, onchain logic is accessible to every network participant, but can be permissioned so that only certain participants can interact. This makes onchain logic highly composable where builders can leverage existing onchain logic and extend that logic in novel ways instead of building from scratch.
-
-
-**Capabilities**: Transfer funds and digital assets, create onchain games, create content and social posts onchain, and more. Pretty much anything you can do offchain can be done onchain.
-
-
-
-**Cost Consideration**: Because every node in the network needs to execute every transaction, each transaction has a cost dependent on the computational expense of the onchain logic being run in that transaction.
-
-
-
-If you have proprietary logic which you don't want public, this shouldn't be onchain. Or if the logic doesn't need to be decentralized and is computationally expensive, it may be better kept in a traditional backend opposed to onchain.
-
diff --git a/docs/learn/solidity/anatomy.mdx b/docs/learn/solidity/anatomy.mdx
deleted file mode 100644
index 3f4da9254..000000000
--- a/docs/learn/solidity/anatomy.mdx
+++ /dev/null
@@ -1,6 +0,0 @@
----
-title: 'Anatomy of a Smart Contract'
----
-
-[Content explaining the structure and components of a smart contract]
-k
\ No newline at end of file
diff --git a/docs/learn/solidity/basic-types.mdx b/docs/learn/solidity/basic-types.mdx
deleted file mode 100644
index 5284eb2f4..000000000
--- a/docs/learn/solidity/basic-types.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: 'Basic Types'
----
-
-[Overview of basic data types in Solidity]
diff --git a/docs/learn/solidity/deployment-in-remix.mdx b/docs/learn/solidity/deployment-in-remix.mdx
deleted file mode 100644
index 4334aa730..000000000
--- a/docs/learn/solidity/deployment-in-remix.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: 'Deployment in Remix'
----
-
-[Guide for deploying contracts using Remix]
diff --git a/docs/learn/solidity/exercise-basics.mdx b/docs/learn/solidity/exercise-basics.mdx
deleted file mode 100644
index 94b14fa7c..000000000
--- a/docs/learn/solidity/exercise-basics.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: 'Exercise'
----
-
-[Practice exercises for basic Solidity concepts]
diff --git a/docs/learn/solidity/hello-world.mdx b/docs/learn/solidity/hello-world.mdx
deleted file mode 100644
index cd40a4f2c..000000000
--- a/docs/learn/solidity/hello-world.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: 'Hello World Guide'
----
-
-[Guide for creating your first smart contract]
diff --git a/docs/learn/solidity/introduction-to-contracts.mdx b/docs/learn/solidity/introduction-to-contracts.mdx
deleted file mode 100644
index 1e941623e..000000000
--- a/docs/learn/solidity/introduction-to-contracts.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: 'Introduction to Contracts'
----
-
-[Introduction to smart contract development]
diff --git a/docs/learn/solidity/introduction-to-remix.mdx b/docs/learn/solidity/introduction-to-remix.mdx
deleted file mode 100644
index 12e76a947..000000000
--- a/docs/learn/solidity/introduction-to-remix.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: 'Introduction to Remix'
----
-
-[Content introducing the Remix IDE]
diff --git a/docs/learn/solidity/introduction.mdx b/docs/learn/solidity/introduction.mdx
deleted file mode 100644
index c73e7fb4b..000000000
--- a/docs/learn/solidity/introduction.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: 'Introduction to Solidity'
----
-
-[Content introducing Solidity programming language]
diff --git a/docs/learn/solidity/overview.mdx b/docs/learn/solidity/overview.mdx
deleted file mode 100644
index 40edc5a9a..000000000
--- a/docs/learn/solidity/overview.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: 'Overview'
----
-
-[Overview of Solidity programming concepts]
diff --git a/docs/learn/solidity/remix-guide.mdx b/docs/learn/solidity/remix-guide.mdx
deleted file mode 100644
index 036b26802..000000000
--- a/docs/learn/solidity/remix-guide.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: 'Remix Guide'
----
-
-[Detailed guide for using Remix IDE]
diff --git a/docs/learn/solidity/step-by-step.mdx b/docs/learn/solidity/step-by-step.mdx
deleted file mode 100644
index 343fcea06..000000000
--- a/docs/learn/solidity/step-by-step.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: 'Step by Step Guide'
----
-
-[Step-by-step guide for Solidity development]
diff --git a/docs/learn/solidity/video-tutorial.mdx b/docs/learn/solidity/video-tutorial.mdx
deleted file mode 100644
index c219cc257..000000000
--- a/docs/learn/solidity/video-tutorial.mdx
+++ /dev/null
@@ -1,5 +0,0 @@
----
-title: 'Video Tutorial'
----
-
-[Video tutorial content for Solidity introduction]
diff --git a/docs/learn/storage/how-storage-works-video.mdx b/docs/learn/storage/how-storage-works-video.mdx
deleted file mode 100644
index 6e456fd27..000000000
--- a/docs/learn/storage/how-storage-works-video.mdx
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: How Storage Works
-description: Learn how storage works in the EVM.
-hide_table_of_contents: false
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
-
diff --git a/docs/learn/storage/how-storage-works.mdx b/docs/learn/storage/how-storage-works.mdx
deleted file mode 100644
index 133552151..000000000
--- a/docs/learn/storage/how-storage-works.mdx
+++ /dev/null
@@ -1,237 +0,0 @@
----
-title: How Storage Works
-sidebarTitle: Storage Overview
-description: An introduction to how storage works in Ethereum
-hide_table_of_contents: false
----
-
-In this article, we will delve into the workings of Ethereum storage, explore the nuances of variable declaration ordering, and provide examples of efficient and inefficient storage practices to create optimized smart contracts.
-
----
-
-## Objectives:
-
-By the end of this lesson you should be able to:
-
-- Diagram how a contract's data is stored on the blockchain (Contract -> Blockchain)
-- Order variable declarations to use storage efficiently
-- Diagram how variables in a contract are stored (Variable -> Contract)
-
----
-
-## Introduction
-
-Creating smart contracts that can operate efficiently requires a thorough understanding of how storage works in Ethereum. When designing a contract, you need to consider the storage requirements of the contract, including the types of storage needed, the gas costs associated with storage operations, and how to manage storage effectively. Poor storage management practices can lead to bloated contracts that consume excessive gas, making them more expensive to execute. By following best practices for storage management, you'll be equipped to create contracts that are lean, efficient, and cost-effective.
-
----
-
-## Smart Contract Data Storage
-
-### Key-Value Store
-
-Smart contracts on Ethereum store and manage data utilizing a key-value store model, where each piece of data is identified by a unique key and accompanied by its corresponding value.
-
-In this diagram, the keys (user addresses) are unique identifiers used to index the corresponding values (balances):
-
-
-
-
-
-This model can be compared to a dictionary or a map where the key serves as the index and the value represents the data associated with that index. However, the key-value store has distinct characteristics that set it apart from these traditional data structures, which make it a more optimal choice for smart contracts on Ethereum.
-
-- **Simplicity:** It is simple and straightforward, which allows for easier implementation and maintenance within a contract.
-
-- **Scalability:** It is highly scalable, making it well-suited for managing vast amounts of data typically associated with apps and smart contracts. This scalability helps maintain performance levels even as data storage requirements grow.
-
-- **Fixed-size chunks:** Storing data in fixed-size 32-byte chunks optimizes storage space and ensures that data location calculations are more efficient. This feature is particularly beneficial in the context of Ethereum, where storage costs are a significant concern.
-
-- **Efficient storage and retrieval:** It is optimized for storing and retrieving large volumes of data efficiently, which is essential for quick access to stored information.
-
-- **Security and immutability:** Unlike other storage models that may allow direct data manipulation, key-value stores within Ethereum's environment ensure data integrity and security through transaction-based modifications. This feature aligns with the decentralized and trustless nature of blockchain technology.
-
-- **Gas-efficiency:** In Ethereum, every operation within a smart contract execution consumes gas. The key-value store model is designed to be gas-efficient, minimizing the gas consumption for storage and retrieval operations, thus reducing the overall cost of contract execution.
-
-- **Compatibility with decentralized environments:** It is particularly suitable for decentralized environments, where data consistency, integrity, and security are crucial. The model's design inherently addresses the challenges posed by multi-threaded or concurrent environments where multiple processes or functions may attempt to access or modify the same data simultaneously.
-
-### Types of Storage
-
-There are three primary types of storage in Ethereum smart contracts: storage, memory, and stack. Each type has its specific use case and characteristics, which make them suitable for different aspects of smart contract execution.
-
-#### Storage
-
-Storage is the most persistent and expensive form of data storage. Data stored in the contract's storage persists across transaction executions and is accessible to any function within the smart contract. This storage is also visible on the blockchain and can be read by external sources, making it suitable for storing important and long-lasting information related to the contract's state.
-
-Key attributes of storage:
-
-- **Persistent:** Data remains in storage even after the contract execution finishes, allowing for state continuity across multiple transactions.
-
-- **Expensive:** Storing and modifying data in storage consumes more gas compared to other data locations, making it costly in terms of transaction fees.
-
-- **Visible on the blockchain:** Storage data is publicly available and can be read by external parties.
-
-Consider the following contract:
-
-```solidity
-contract StorageDemo {
- // Declare a state variable to store data in storage
- uint256 public storedData;
-
- // Function to update the storedData variable in storage
- function updateData(uint256 newData) public {
- storedData = newData;
- }
-}
-```
-
-The contract includes a state variable called `storedData`, which is stored in the contract's storage. The `public` visibility modifier allows anyone to access this variable. The contract also includes a public function called `updateData`, which can be called by anyone to modify the value of `storedData` in storage.
-
-Any changes made to `storedData` in storage will persist across multiple transactions and will be visible to anyone who reads the blockchain. Please note that storage is more expensive than other data locations, so it is important to use it judiciously to minimize gas costs.
-
-#### Memory
-
-Memory is a temporary and more affordable data location. It's used to save data during the execution of a single transaction. Once the transaction is complete, the memory is wiped clean and any data within it is lost. Memory is suitable for storing intermediate variables and temporary data that does not need to persist across multiple transactions.
-
-Key attributes of memory:
-
-- **Temporary:** Data in memory is only available during a single transaction execution and is lost afterward.
-
-- **Less expensive:** Saving and modifying data in memory consumes less gas compared to storage, making it more cost-effective for temporary data.
-
-- **Not visible on the blockchain:** Memory data is not accessible to external parties and remains confined to the transaction execution.
-
-Consider the following contract:
-
-```solidity
-contract MemoryDemo {
- // Declare a state variable to store data in storage
- uint256 public storedData;
-
- // Function to update the storedData variable in memory
- function updateData(uint256 newData) public {
- // Declare a memory variable to store the new data
- uint256 tempData = newData;
-
- // Assign the value of the memory variable to the storage variable
- storedData = tempData;
- }
-}
-```
-
-In the contract, we declare a memory variable called `tempData` and assign the input parameter `newData` to it to update its value. The `tempData` variable is then assigned to the `storedData` variable to update its value in storage.
-
-Unlike storage, data stored in memory is not persisted across transactions and is only accessible during the execution of the function. However, accessing and modifying data in memory is less expensive than doing so in storage, making it a more efficient option when dealing with temporary data. Additionally, any data stored in memory is not visible on the blockchain and cannot be read by external parties.
-
-#### Stack
-
-The stack is another form of temporary data storage, specifically used for holding function arguments, local variables, and intermediate values during function execution. The stack follows a Last-In-First-Out (LIFO) structure, meaning that the most recently added item is the first to be removed. This storage type is highly efficient but has limited space, making it suitable for small-scale data manipulation during function execution.
-
-The stack is an internal data structure used by the EVM (Ethereum Virtual Machine) for computation during the execution of transactions. When a transaction is executed by the EVM, the bytecode of the smart contract is loaded into memory, and the EVM uses the stack to keep track of intermediate results and execute operations.
-
-In Solidity, developers do not interact with the stack directly, but can optimize their code to make the best use of it and minimize the amount of gas used during transaction execution. This can include using more efficient algorithms or data structures, or avoiding unnecessary operations that can increase the depth of the stack.
-
-Key attributes of the stack:
-
-- **Temporary:** Like memory, stack data is only available during a single transaction execution and is lost afterward.
-
-- **Highly efficient:** Stack operations consume minimal gas, making it the most cost-effective storage option for small-scale data manipulation.
-
-- **LIFO structure:** The stack follows the Last-In-First-Out order, which allows for efficient management of function arguments, local variables, and intermediate values.
-
-- **Limited space:** The stack has a maximum depth of 1024, restricting the number of elements it can hold at a given time.
-
-- **Limited visibility:** Only the top 16 elements in the stack are accessible, limiting how many variables and other elements can be in scope at one time.
-
-Let's compare two versions of a function and analyze their gas efficiency with regard to stack usage and gas consumption:
-
-```solidity
-contract GasEfficiencyDemo {
- uint256 public result;
-
- // Less efficient
- function sumLessEfficient(uint256 a, uint256 b) public {
- uint256 temp = a + b;
- result = temp;
- }
-
- // More efficient
- function sumMoreEfficient(uint256 a, uint256 b) public {
- result = a + b;
- }
-}
-```
-
-In the `sumLessEfficient` function, the sum of the two input arguments `a` and `b` is first assigned to the temporary variable `temp` before being assigned to the state variable `result`. This additional step introduces an extra variable on the stack, which requires more gas for stack operations and consumes more gas overall.
-
-In contrast, the `sumMoreEfficient` function directly assigns the sum of the input arguments `a` and `b` to the state variable result. This eliminates the need for the temporary variable and reduces the stack usage, leading to lower gas consumption for stack operations and a more gas-efficient execution.
-
-Although the difference in gas consumption between these two functions may not be significant for such a simple example, the principle of minimizing stack usage and optimizing code to reduce gas consumption is essential for developing efficient smart contracts. By avoiding unnecessary variables and operations, you can improve the gas efficiency of your functions and reduce the cost of executing them on the EVM.
-
-## Variable Storage
-
-### Variable Packing
-
-As we've learned, minimizing the storage footprint of a contract can substantially reduce gas costs. To make storage more efficient, Ethereum employs a concept called variable packing.
-
-Variable packing is the process of placing multiple smaller variables into a single storage slot to optimize storage usage. A storage slot is a fixed-size container that can hold up to 32 bytes of data. Ethereum's Solidity compiler automatically packs smaller variables together if they can fit into a single storage slot.
-
-
-
-
-
-### Ordering Variable Declarations
-
-When declaring variables in a contract, their order can impact a contract's gas usage. You can optimize storage by declaring variables of similar sizes together, such that they can be packed into the same storage slot.
-
-Let's illustrate how this works:
-
-```solidity
-contract StoragePackingExample {
- uint8 a; // 1 byte
- uint8 b; // 1 byte
- uint256 c; // 32 bytes
-}
-```
-
-In this example, the compiler will automatically pack `a` and `b` into the same storage slot, as they are both 1-byte variables and can fit into a single 32-byte storage slot. However, `c` requires a separate storage slot due to its size (32 bytes).
-
-
-
-
-
-If these variables were not in the correct order, the contract would not take advantage of variable packing. The variables would take up more storage and would potentially consume more gas to execute the contract.
-
-Let's consider an inefficient example:
-
-```solidity
-contract StoragePackingBadExample {
- uint8 a; // 1 byte
- uint256 b; // 32 bytes
- uint8 c; // 1 byte
-}
-```
-
-In this contract, the variables are not declared in the optimal order, and the compiler would store these variables in the following way:
-
-
-
-
-
-To make the most of variable packing, it's important to group variables of the same size together and avoid mixing variable sizes. By doing this, the compiler can store them more efficiently, reducing the overall storage usage of the contract. This optimization will not only reduce the gas costs associated with storage, but it will also improve the contract's execution speed.
-
----
-
-## Conclusion
-
-Creating efficient and optimized smart contracts on Ethereum requires a thorough understanding of how storage works. Smart contracts use a key-value store model to manage and store data, which is simple, scalable, gas-efficient, and suitable for decentralized environments. There are three types of storage in Ethereum smart contracts: storage, memory, and stack, each with specific characteristics. Developers can optimize storage usage by using variable packing and ordering variable declarations based on their size. By following best practices for storage management, developers can create contracts that are lean, efficient, cost-effective, and improve their execution speed.
-
----
-
-## See Also
-
-- [Understanding Ethereum Smart Contract Storage](https://programtheblockchain.com/posts/2018/03/09/understanding-ethereum-smart-contract-storage/)
-- [What is Smart Contract Storage Layout](https://docs.alchemy.com/docs/smart-contract-storage-layout)
-
-
-[ethereum in depth, part 2]: https://blog.openzeppelin.com/ethereum-in-depth-part-2-6339cf6bddb9/
-[ethereum yellow paper]: https://ethereum.github.io/yellowpaper/paper.pdf
-
diff --git a/docs/learn/storage/simple-storage-sbs.mdx b/docs/learn/storage/simple-storage-sbs.mdx
deleted file mode 100644
index 32010af12..000000000
--- a/docs/learn/storage/simple-storage-sbs.mdx
+++ /dev/null
@@ -1,222 +0,0 @@
----
-title: Storing Data
-sidebarTitle: Step by Step Guide
-description: Learn how to Store data on the blockchain.
-hide_table_of_contents: false
----
-
-Ultimately, the power of the blockchain is that anyone can store their data on it via the `storage` in a smart contract. In this step-by-step guide, you'll learn how to access and use the `storage` data location.
-
----
-
-## Objectives
-
-By the end of this lesson you should be able to:
-
-- Use the constructor to initialize a variable
-- Access the data in a public variable with the automatically generated getter
-- Order variable declarations to use storage efficiently
-
----
-
-## Simple Storage Contract
-
-Create a contract called `SimpleStorage`.
-
-### Add a Storage Variable
-
-In Solidity, variables declared at the class level are automatically `storage` variables. Create a variable to store the age of a person and another to store the number of cars that they own. Give `age` an initial value of your choosing, but don't make an assignment for `cars`;
-
-
-
-```solidity
-contract SimpleStorage {
- uint8 age = 41;
- uint8 cars;
-}
-```
-
-
-
-Because the age of a person, or the number of cars they own, is unlikely to be greater than 255, we can use a `uint8` for each of these. For types that are smaller than 32 bytes, multiple variables of the same type will be [packed] in the same storage slot. For this to work, the variables must be declared together.
-
-```solidity
-// These variables take advantage of packing
-uint8 first;
-uint8 second;
-uint third;
-
-// These variables DO NOT take advantage of packing and should be reordered
-uint8 fourth;
-uint fifth;
-uint8 sixth;
-```
-
-### Initializing a Value with the Constructor
-
-You may add a `constructor` function to your contract. Similar to other languages, this function is called exactly once, when the contract is deployed. The constructor may have parameters, but it does not require them.
-
-You can use the constructor to perform various setup tasks. For example, the constructor for the _ERC-721_ token that is the underlying mechanism for most NFTs uses the constructor to set up the name and symbol for the token.
-
-Create a constructor function and use it to assign the value of your choosing to `cars`.
-
-
-
-```solidity
-constructor() {
- cars = 1;
-}
-```
-
-
-
-### Accessing State Variables
-
-Deploy your contract in Remix. It should work fine, but you'll have one problem: there isn't a way to see if the variables have the expected values!
-
-You could solve this by writing functions that return the values in your state variables, but you don't need to. The Solidity compiler automatically creates getters for all `public` variables.
-
-Add the `public` keyword to both variables. Unlike most languages, `public` goes **after** the type declaration. Your contract should now be similar to:
-
-
-
-```solidity
-contract SimpleStorage {
- uint8 public age = 41;
- uint8 public cars;
- constructor() {
- cars = 1;
- }
-}
-```
-
-
-
-Redeploy your contract and test to confirm.
-
----
-
-## Setting a State Variable with a Function
-
-Good news! Our user bought a second car! The only problem is that we don't have a way to update the number of `cars` stored.
-
-### Add a Function to Update `cars`
-
-Before writing the function, let's think about design considerations for this feature. At any point in time, a user could:
-
-- Buy or otherwise acquire a new car
-- Get several new cars all at once (Woohoo!)
-- Sell or give away one or more cars (😞)
-
-Given this wide variety of conditions, **a** good approach would be to handle calculating the correct number of cars on the front end, and passing the updated value to the back end.
-
-To meet this need, we can write a `public` function that takes a `uint8` for `_numberOfCars` and then simply assigns that value to the state variable `cars`. Because this function modifies state, it **does not** need `pure` or `view`. It isn't either of those.
-
-
-
-```solidity
-function updateNumberOfCars(uint8 _numberOfCars) public {
- cars = _numberOfCars;
-}
-```
-
-
-
-Deploy and test to make sure it works as expected.
-
-
-While packing variables can save on gas costs, it can also increase them. The EVM operates on 32 bytes at a time, so it will take additional steps to reduce the size of the element for storage.
-
-Furthermore, the savings in writing to storage only apply when writing multiple values in the same slot at the same time.
-
-Review the **Warning** in the [layout] section of the docs for more details!
-
-
-
-### Add a Function to Update `age`
-
-It would also be good to be able to update the `age` value. This problem has slightly different considerations. Sadly, `age` will never go down. It should also probably only go up by one year for each update. The `++` operator works in Solidity, so we can use that to create a function that simply increments age when called.
-
-
-
-
-```solidity
-function increaseAge() public {
- age++;
-}
-```
-
-
-
-
-But what if a user calls this function by mistake? Good point!
-
-On your own, add a function called `adminSetAge` that can set the `age` to a specified value.
-
-### Refactor the Constructor to Accept Arguments
-
-We've got one problem remaining with this contract. What if your user has a different `age` or number of `cars` than what you've hardcoded into the contract?
-
-As mentioned above, the `constructor` **can** take arguments and use them during deployment. Let's refactor the contract to set the two state variables in the constructor based on provided values.
-
-
-
-```solidity
-contract SimpleStorage {
- uint8 public age;
- uint8 public cars;
- constructor(uint8 _age, uint8 _cars) {
- age = _age;
- cars = _cars;
- }
-}
-```
-
-
-
-Redeploy your contract. Note that now you have added parameters to the `constructor`, you'll have to provide them during deployment.
-
-
-
-
-
-Once completed, your contract should be similar to:
-
-
-
-
-```solidity
-contract SimpleStorage {
- uint8 public age;
- uint8 public cars;
- constructor(uint8 _age, uint8 _cars) {
- age = _age;
- cars = _cars;
- }
-
- function updateNumberOfCars(uint8 _numberOfCars) public {
- cars = _numberOfCars;
- }
-
- function increaseAge() public {
- age++;
- }
-
- function adminSetAge(uint8 _age) public {
- age = _age;
- }
-}
-```
-
-
-
----
-
-## Conclusion
-
-In this lesson, you've explored how to persistently store values on the blockchain. You've also practiced updating them from functions. Finally, you've learned how to use the constructor to perform setup functionality during deployment, with and without parameters.
-
----
-
-[packed]: https://docs.soliditylang.org/en/v0.8.17/internals/layout_in_storage.html
-[layout]: https://docs.soliditylang.org/en/v0.8.17/internals/layout_in_storage.html
diff --git a/docs/learn/storage/simple-storage-video.mdx b/docs/learn/storage/simple-storage-video.mdx
deleted file mode 100644
index ae6b828a4..000000000
--- a/docs/learn/storage/simple-storage-video.mdx
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: Simple Storage
-description: Store data on the blockchain.
-hide_table_of_contents: false
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
diff --git a/docs/learn/storage/storage-exercise.mdx b/docs/learn/storage/storage-exercise.mdx
deleted file mode 100644
index a4f936197..000000000
--- a/docs/learn/storage/storage-exercise.mdx
+++ /dev/null
@@ -1,118 +0,0 @@
----
-title: Storage Exercise
-sidebarTitle: Exercise
-description: Exercise - Demonstrate your knowledge of storage.
-hide_table_of_contents: false
----
-
-import { Danger } from "/snippets/danger.mdx";
-
-Create a contract that adheres to the following specifications:
-
----
-
-## Contract
-
-Create a single contract called `EmployeeStorage`. It should not inherit from any other contracts. It should have the following functions:
-
-### State Variables
-
-The contract should have the following state variables, optimized to minimize storage:
-
-- A private variable `shares` storing the employee's number of shares owned
- - Employees with more than 5,000 shares count as directors and are stored in another contract
-- Public variable `name` which stores the employee's name
-- A private variable `salary` storing the employee's salary
- - Salaries range from 0 to 1,000,000 dollars
-- A public variable `idNumber` storing the employee's ID number
- - Employee numbers are not sequential, so this field should allow any number up to 2^256-1
-
-### Constructor
-
-When deploying the contract, utilize the `constructor` to set:
-
-- `shares`
-- `name`
-- `salary`
-- `idNumber`
-
-For the purposes of the test, you **must** deploy the contract with the following values:
-
-- `shares` - 1000
-- `name` - Pat
-- `salary` - 50000
-- `idNumber` - 112358132134
-
-### View Salary and View Shares
-
-
-In the world of blockchain, nothing is ever secret!\* `private` variables prevent other contracts from reading the value. You should use them as a part of clean programming practices, but marking a variable as private **does _not_ hide the value**. All data is trivially available to anyone who knows how to fetch data from the chain.
-
-\*You can make clever use of encryption though!
-
-
-
-Write a function called `viewSalary` that returns the value in `salary`.
-
-Write a function called `viewShares` that returns the value in `shares`.
-
-### Grant Shares
-
-Add a public function called `grantShares` that increases the number of shares allocated to an employee by `_newShares`. It should:
-
-- Add the provided number of shares to the `shares`
- - If this would result in more than 5000 shares, revert with a custom error called `TooManyShares` that returns the number of shares the employee would have with the new amount added
- - If the number of `_newShares` is greater than 5000, revert with a string message, "Too many shares"
-
-### Check for Packing and Debug Reset Shares
-
-Add the following function to your contract exactly as written below.
-
-```solidity
-/**
-* Do not modify this function. It is used to enable the unit test for this pin
-* to check whether or not you have configured your storage variables to make
-* use of packing.
-*
-* If you wish to cheat, simply modify this function to always return `0`
-* I'm not your boss ¯\_(ツ)_/¯
-*
-* Fair warning though, if you do cheat, it will be on the blockchain having been
-* deployed by your wallet....FOREVER!
-*/
-function checkForPacking(uint _slot) public view returns (uint r) {
- assembly {
- r := sload (_slot)
- }
-}
-
-/**
-* Warning: Anyone can use this function at any time!
-*/
-function debugResetShares() public {
- shares = 1000;
-}
-```
-
----
-
-### Submit your Contract and Earn an NFT Badge! (BETA)
-
-
-#### Hey, where'd my NFT go!?
-
-[Testnets](/learn/deployment-to-testnet/test-networks) are not permanent! Base Goerli [will soon be sunset](https://base.mirror.xyz/kkz1-KFdUwl0n23PdyBRtnFewvO48_m-fZNzPMJehM4), in favor of Base Sepolia.
-
-As these are separate networks with separate data, your NFTs **will not** transfer over.
-
-**Don't worry!** We've captured the addresses of all NFT owners on Base Goerli and will include them when we release the mechanism to transfer these NFTs to mainnet later this year! You can also redeploy on Sepolia and resubmit if you'd like!
-
-
-
-{/* */}
-
-
diff --git a/docs/learn/structs/structs-exercise.mdx b/docs/learn/structs/structs-exercise.mdx
deleted file mode 100644
index 097d6144f..000000000
--- a/docs/learn/structs/structs-exercise.mdx
+++ /dev/null
@@ -1,81 +0,0 @@
----
-title: Structs Exercise
-description: Exercise - Demonstrate your knowledge of structs.
-hide_table_of_contents: false
-sidebarTitle: Exercise
----
-
-Create a contract that adheres to the following specifications.
-
----
-
-## Contract
-
-Create a contract called `GarageManager`. Add the following in storage:
-
-- A public mapping called `garage` to store a list of `Car`s (described below), indexed by address
-
-Add the following types and functions.
-
-### Car Struct
-
-Implement a `struct` called `Car`. It should store the following properties:
-
-- `make`
-- `model`
-- `color`
-- `numberOfDoors`
-
-### Add Car Garage
-
-Add a function called `addCar` that adds a car to the user's collection in the `garage`. It should:
-
-- Use `msg.sender` to determine the owner
-- Accept arguments for make, model, color, and number of doors, and use those to create a new instance of `Car`
-- Add that `Car` to the `garage` under the user's address
-
-### Get All Cars for the Calling User
-
-Add a function called `getMyCars`. It should return an array with all of the cars owned by the calling user.
-
-### Get All Cars for Any User
-
-Add a function called `getUserCars`. It should return an array with all of the cars for any given `address`.
-
-### Update Car
-
-Add a function called `updateCar`. It should accept a `uint` for the index of the car to be updated, and arguments for all of the `Car` types.
-
-If the sender doesn't have a car at that index, it should revert with a custom `error` `BadCarIndex` and the index provided.
-
-Otherwise, it should update that entry to the new properties.
-
-### Reset My Garage
-
-Add a public function called `resetMyGarage`. It should delete the entry in `garage` for the sender.
-
----
-
-### Submit your Contract and Earn an NFT Badge! (BETA)
-
-
-#### Hey, where'd my NFT go!?
-
-[Testnets](/learn/deployment-to-testnet/test-networks) are not permanent! Base Goerli [will soon be sunset](https://base.mirror.xyz/kkz1-KFdUwl0n23PdyBRtnFewvO48_m-fZNzPMJehM4), in favor of Base Sepolia.
-
-As these are separate networks with separate data, your NFTs **will not** transfer over.
-
-**Don't worry!** We've captured the addresses of all NFT owners on Base Goerli and will include them when we release the mechanism to transfer these NFTs to mainnet later this year! You can also redeploy on Sepolia and resubmit if you'd like!
-
-
-{/* */}
-
-
-
-
-Ensure your variable sizes align with their intended use, and consider the nuances of packing in Solidity. Resources: [Solidity - Layout in Storage](https://docs.soliditylang.org/en/v0.8.17/internals/layout_in_storage.html#layout-of-state-variables-in-storage), [Variables in Struct](/learn/structs/structs-sbs#setting-up-the-struct)
-
diff --git a/docs/learn/structs/structs-sbs.mdx b/docs/learn/structs/structs-sbs.mdx
deleted file mode 100644
index 8dc92f267..000000000
--- a/docs/learn/structs/structs-sbs.mdx
+++ /dev/null
@@ -1,325 +0,0 @@
----
-title: Structs
-description: Practice using structs.
-hide_table_of_contents: false
-sidebarTitle: Step by Step Guide
----
-
-The `struct` type allows you to organize related data of different types.
-
----
-
-## Objectives
-
-By the end of this lesson you should be able to:
-
-- Construct a `struct` (user-defined type) that contains several different data types
-- Declare members of the `struct` to maximize storage efficiency
-- Describe constraints related to the assignment of `struct`s depending on the types they contain
-
----
-
-## Creating a Struct
-
-In the last exercise, we used a `mapping` to create a relationship between an `address` and a `uint`. But what if your users have favorite colors too? Or favorite cars? You **could** create a `mapping` for each of these, but it would quickly get awkward. Instead, a [`struct`](https://docs.soliditylang.org/en/v0.8.17/types.html#structs) can be used to create a custom type that can store all of a user's favorites within one data type.
-
-Create a new contract called `Structs`.
-
-### Setting up the Struct
-
-Instantiate a `struct` with the keyword, followed by a name for the type, curly brackets, and the variables that make up the type. Add a stub for `Favorites`:
-
-```solidity
-struct Favorites {
-
-}
-```
-
-After consulting with the designers, we need to store the following for each address's favorites:
-
-- Favorite number
-- Birth Day of Month
-- Favorite color
-- Lucky Lottery numbers
-
-Let's pause for a moment and do some technical design around how to save our favorites.
-
-The product team has confirmed for us that we can safely expect that no users have a favorite number greater than 65,536, and of course, everyone is born on a day of the month between 1-31.
-
-Variable [packing](https://docs.soliditylang.org/en/v0.8.17/internals/layout_in_storage.html) also works inside structs, so we could potentially save on storage by using smaller `uint`s for those variables. However, people don't change their favorite number very often, and the day of the month that they were born on never changes.
-
-Therefore, it's probably more gas-efficient and less cumbersome to write other parts of the code, if we just use `uint` for both variables.
-
-Favorite color can be a `string`.
-
-For Lucky Lottery Numbers, we need a collection. We could use a dynamic array, since this will be in _storage_, but we already know that the lottery has 5 numbers.
-
-Try to use this information to build the `struct` on your own. You should end up with something similar to:
-
-
-
-```solidity
-struct Favorites {
- uint favoriteNumber;
- uint birthDay;
- string favoriteColor;
- uint[5] lotteryNumbers;
-}
-```
-
-
-
-### Instantiating a Struct with Its Name
-
-There are two ways to instantiate a struct using its name. The first is similar to instantiating a new object in JavaScript:
-
-```solidity
-Favorites memory myFavorites = Favorites({
- favoriteNumber: 29,
- birthDay: 14,
- favoriteColor: "red",
- lotteryNumbers: [uint(1), 2, 3, 4, 5]
-});
-```
-
-You can also use a shorthand method where you skip the member names and just list a value for each one. Note that the curly brackets are **not** included in this format:
-
-```solidity
-Favorites memory myFavorites = Favorites(
- 29,
- 14,
- "red",
- [uint(1), 2, 3, 4, 5]
-);
-```
-
-There's no difference in gas costs with either of these methods. Use the one that makes the most sense for the given situation.
-
-### Saving Multiple Instances to Storage
-
-Next, we need to figure out the best way to organize the `Favorites` in _storage_. There are a few options, as always, each with tradeoffs. You could match the pattern you used for favorite numbers and utilize a `mapping` to match `addresses` to `Favorites`.
-
-Another popular method is to use an array, which takes advantage of `.push` returning a reference to the newly added element, and the fact that the concept of _undefined_ does not exist in Solidity.
-
-First, instantiate an array of `Favorites`:
-
-```solidity
-Favorites[] public userFavorites;
-```
-
-Next, add a `public` function to add submitted favorites to the list. It should take each of the members as an argument. Then, assign each argument to the new element via the reference returned by `push()`.
-
-
-
-```solidity
-function addFavorite(
- uint _favoriteNumber,
- uint _birthDay,
- string calldata _favoriteColor,
- uint[5] calldata _lotteryNumbers
-) public {
- // .push() returns a reference to the new element
- Favorites storage newFavorite = userFavorites.push();
- newFavorite.favoriteNumber = _favoriteNumber;
- newFavorite.birthDay = _birthDay;
- newFavorite.favoriteColor = _favoriteColor;
- newFavorite.lotteryNumbers = _lotteryNumbers;
-}
-```
-
-
-
-Alternatively, you can create an instance in memory, then `push` it to storage.
-
-
-
-```solidity
-function addFavorite(
- uint _favoriteNumber,
- uint _birthDay,
- string calldata _favoriteColor,
- uint[5] calldata _lotteryNumbers
-) public {
- Favorites memory myFavorites = Favorites(
- 29,
- 14,
- "red",
- [uint(1), 2, 3, 4, 5]
- );
-
- userFavorites.push(myFavorites);
-}
-```
-
-
-
-The gas cost is similar for each of these methods.
-
----
-
-## Unexpected Behavior in Structs
-
-Structs in Solidity exhibit some properties that are unexpected, or even frustrating. Working with them often includes untangling a set of mutually-exclusive properties and needs.
-
-### Dynamic Storage Arrays in Structs
-
-The product team has contacted you to let you know that the beta testers are complaining about the `lotteryNumbers`. As it turns out, not every locality has lotteries where 5 numbers are drawn. Some have 3, 4, or even 6!.
-
-You might think this is an easy enough change. After all, you can just remove the size from the array declaration inside `Favorites`. Go ahead and try it:
-
-```solidity
-struct Favorites {
- uint favoriteNumber;
- uint birthDay;
- string favoriteColor;
- uint[] lotteryNumbers; // Removed the '5'
-}
-```
-
-You'll get an error if you're using the `memory` method shown above.
-
-```text
-from solidity:
-TypeError: Invalid type for argument in function call. Invalid implicit conversion from uint256[5] memory to uint256[] memory requested.
- --> contracts/mappings_exercise.sol:70:13:
- |
-70 | [uint(1), 2, 3, 4, 5]
- | ^^^^^^^^^^^^^^^^^^^^^
-```
-
-The simplest resolution here is to switch back to using `push()` to create an empty instance of `Favorites`, then assigning the values.
-
-The reason this works is a little obtuse. In the failing example, an unsized `uint` array is the expected type for the argument, but a sized `uint` array is provided. Solidity cannot perform implicit conversions like this most of the time and you'll get a compiler error if you provide the wrong type for an argument, even if it is convertible.
-
-One exception to this rule is that Solidity **can** perform an implicit conversion during _assignment_ if the variable on the right side "fits" into the variable on the left side.
-
-`uint[5]` fits in `uint[]`, so Solidity will allow it to sit 🐈.
-
-But what happens if you use the _getter_ for `userFavorites` to retrieve your entry?
-
-```text
-{
- "0": "uint256: favoriteNumber 29",
- "1": "uint256: birthDay 14",
- "2": "string: favoriteColor red"
-}
-```
-
-What happened to the array? It's not there, and it turns out that this is [on purpose](https://github.com/ethereum/solidity/issues/1626).
-
-### Mappings Inside of Structs
-
-You may add `mappings` inside of `struct`s, subject to a few quirks and restrictions. Add `mapping (uint => uint) numberPairs;` to `Favorites`.
-
-In `addFavorites`, assign `newFavorite.numberPairs[33] = 66;`
-
-Deploy and test. So far, so good!
-
-_Déjà vu_ ahead: But what happens if you use the _getter_ for `userFavorites` to retrieve your entry?
-
-```text
-{
- "0": "uint256: favoriteNumber 29",
- "1": "uint256: birthDay 14",
- "2": "string: favoriteColor red"
-}
-```
-
-It's not there, and it turns out that this is [on purpose](https://github.com/ethereum/solidity/issues/1626).
-
-Another issue emerges if you try to return the struct from a public function. What if you wanted your `addFavorite` function to return a reference to the new favorite?
-
-```solidity
-// Bad code example, will not work
-function addFavorite(
- uint _favoriteNumber,
- uint _birthDay,
- string calldata _favoriteColor,
- uint[] calldata _lotteryNumbers
-) public returns (newFavorite memory) {
- // .push() returns a reference to the new element
- Favorites storage newFavorite = userFavorites.push();
- newFavorite.favoriteNumber = _favoriteNumber;
- newFavorite.birthDay = _birthDay;
- newFavorite.favoriteColor = _favoriteColor;
- newFavorite.lotteryNumbers = _lotteryNumbers;
- newFavorite.numberPairs[33] = 66;
-
- return newFavorite;
-}
-```
-
-You'll get an error. The `mapping` type cannot be returned by a `public` or `external` function, so neither can a `struct` that contains one.
-
-```text
-from solidity:
-TypeError: Types containing (nested) mappings can only be parameters or return variables of internal or library functions.
- --> contracts/mappings_exercise.sol:64:23:
- |
-64 | ) public returns (Favorites memory) {
- | ^^^^^^^^^^^^^^^^
-```
-
-Finally, what happens if you try to assign `newFavorite` to a `memory` variable? Again, an error occurs because `mapping`s can only be in `storage`.
-
-```solidity
-// Bad code example, will not work
-Favorites memory secondFavorite = newFavorite;
-```
-
-```text
-from solidity:
-TypeError: Type struct Structs.Favorites memory is only valid in storage because it contains a (nested) mapping.
- --> contracts/mappings_exercise.sol:82:9:
- |
-82 | Favorites memory secondFavorite = newFavorite;
- | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-```
-
-### Automatic Getters for Public Structs
-
-As with other types, if you put a `public` `struct` in storage at the contract level, the compiler will generate a getter automatically. However, these don't work quite the way you might expect. For example, imagine:
-
-```solidity
-
-struct MyStruct {
- uint first;
- uint second;
- uint third;
-}
-
-MyStruct myStruct;
-
-```
-
-The automatic getter for `myStruct` will **not** be:
-
-```solidity
-// Approximate example, not real code
-function myStruct() public view returns (MyStruct memory) {
- return myStruct;
-}
-```
-
-Instead, it returns the members individually:
-
-```solidity
-// Approximate example, not real code
-function myStruct() public view returns (uint, uint, uint) {
- return (myStruct.first, myStruct.second, myStruct.third);
-}
-```
-
-Create your own getter to return the data as a tuple, which will be interpreted as the appropriate type if it's called from another contract via an interface.
-
-```solidity
-function getMyStruct() public view returns (MyStruct memory) {
- return myStruct;
-}
-```
-
----
-
-## Conclusion
-
-In this lesson, you've learned how to use the `struct` keyword to create a custom type that stores related data. You've also learned three methods of instantiating them and common patterns for storing `struct`s in storage. Finally, you've explored some of the constraints that emerge when working with more complex data types within a `struct`.
diff --git a/docs/learn/structs/structs-vid.mdx b/docs/learn/structs/structs-vid.mdx
deleted file mode 100644
index cb39846e3..000000000
--- a/docs/learn/structs/structs-vid.mdx
+++ /dev/null
@@ -1,9 +0,0 @@
----
-title: Structs
-description: Create user-defined types.
-hide_table_of_contents: false
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
diff --git a/docs/learn/token-development/erc-20-token/analyzing-erc-20-vid.mdx b/docs/learn/token-development/erc-20-token/analyzing-erc-20-vid.mdx
deleted file mode 100644
index b7cd981d8..000000000
--- a/docs/learn/token-development/erc-20-token/analyzing-erc-20-vid.mdx
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Analyzing the ERC-20 Token
-description: Explore the ERC-20 standard.
-sidebarTitle: Analyzing ERC-20
-hide_table_of_contents: false
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
diff --git a/docs/learn/token-development/erc-20-token/erc-20-exercise.mdx b/docs/learn/token-development/erc-20-token/erc-20-exercise.mdx
deleted file mode 100644
index 9feedfbf3..000000000
--- a/docs/learn/token-development/erc-20-token/erc-20-exercise.mdx
+++ /dev/null
@@ -1,124 +0,0 @@
----
-title: ERC-20 Tokens Exercise
-description: Exercise - Create your own ERC-20 token!
-hide_table_of_contents: false
-sidebarTitle: Exercise
----
-
-Create a contract that adheres to the following specifications.
-
----
-
-## Contract
-
-Create a contract called `WeightedVoting`. Add the following:
-
-- A `maxSupply` of 1,000,000
-- Errors for:
- - `TokensClaimed`
- - `AllTokensClaimed`
- - `NoTokensHeld`
- - `QuorumTooHigh`, returning the quorum amount proposed
- - `AlreadyVoted`
- - `VotingClosed`
-- A struct called `Issue` containing:
- - An OpenZeppelin Enumerable Set storing addresses called `voters`
- - A string `issueDesc`
- - Storage for the number of `votesFor`, `votesAgainst`, `votesAbstain`, `totalVotes`, and `quorum`
- - Bools storing if the issue is `passed` and `closed`
-
-
-The unit tests require this `struct` to be constructed with the variables in the order above.
-
-
-
-- An array of `Issue`s called `issues`
-- An `enum` for `Vote` containing:
- - `AGAINST`
- - `FOR`
- - `ABSTAIN`
-- Anything else needed to complete the tasks
-
-Add the following functions.
-
-### Constructor
-
-Initialize the ERC-20 token and burn the zeroeth element of `issues`.
-
-### Claim
-
-Add a `public` function called `claim`. When called, so long as a number of tokens equalling the `maximumSupply` have not yet been distributed, any wallet _that has not made a claim previously_ should be able to claim 100 tokens. If a wallet tries to claim a second time, it should revert with `TokensClaimed`.
-
-Once all tokens have been claimed, this function should revert with an error `AllTokensClaimed`.
-
-
-In our simple token, we used `totalSupply` to mint our tokens up front. The ERC20 implementation we're using also tracks `totalSupply`, but does it differently.
-
-Review the docs and code comments to learn how.
-
-
-
-### Create Issue
-
-Implement an `external` function called `createIssue`. It should add a new `Issue` to `issues`, allowing the user to set the description of the issue, and `quorum` - which is how many votes are needed to close the issue.
-
-Only token holders are allowed to create issues, and issues cannot be created that require a `quorum` greater than the current total number of tokens.
-
-This function must return the index of the newly-created issue.
-
-
-One of the unit tests will break if you place your check for `quorum` before the check that the user holds a token. The test compares encoded error names, which are **not** human-readable. If you are getting `-> AssertionError: �s is not equal to �9�` or similar, this is likely the issue.
-
-
-
-### Get Issue
-
-Add an `external` function called `getIssue` that can return all of the data for the issue of the provided `_id`.
-
-`EnumerableSet` has a `mapping` underneath, so it can't be returned outside of the contract. You'll have to figure something else out.
-
-
-**Hint**
-
-The return type for this function should be a `struct` very similar to the one that stores the issues.
-
-
-### Vote
-
-Add a `public` function called `vote` that accepts an `_issueId` and the token holder's vote. The function should revert if the issue is closed, or the wallet has already voted on this issue.
-
-Holders must vote all of their tokens for, against, or abstaining from the issue. This amount should be added to the appropriate member of the issue and the total number of votes collected.
-
-If this vote takes the total number of votes to or above the `quorum` for that vote, then:
-
-- The issue should be set so that `closed` is true
-- If there are **more** votes for than against, set `passed` to `true`
-
----
-
-### Submit your Contract and Earn an NFT Badge! (BETA)
-
-
-#### Hey, where'd my NFT go!?
-
-[Testnets](/learn/deployment-to-testnet/test-networks) are not permanent! Base Goerli [will soon be sunset](https://base.mirror.xyz/kkz1-KFdUwl0n23PdyBRtnFewvO48_m-fZNzPMJehM4), in favor of Base Sepolia.
-
-As these are separate networks with separate data, your NFTs **will not** transfer over.
-
-**Don't worry!** We've captured the addresses of all NFT owners on Base Goerli and will include them when we release the mechanism to transfer these NFTs to mainnet later this year! You can also redeploy on Sepolia and resubmit if you'd like!
-
-
-
-
-The contract specification contains actions that can only be performed once by a given address. As a result, the unit tests for a passing contract will only be successful the **first** time you test.
-
-**You may need to submit a fresh deployment to pass**
-
-
-{/* */}
-
-
diff --git a/docs/learn/token-development/erc-20-token/erc-20-standard.mdx b/docs/learn/token-development/erc-20-token/erc-20-standard.mdx
deleted file mode 100644
index 9ef862814..000000000
--- a/docs/learn/token-development/erc-20-token/erc-20-standard.mdx
+++ /dev/null
@@ -1,103 +0,0 @@
----
-title: The ERC-20 Token Standard
-description: An overview of the ERC-20 token standard
-sidebarTitle: ERC-20 Standard
-hide_table_of_contents: false
----
-
-
-In this article, we'll delve into the structure and specifications of ERC-20 tokens, uncovering the key elements that contribute to their widespread adoption and diverse use cases.
-
----
-
-## Objectives:
-
-By the end of this lesson you should be able to:
-
-- Analyze the anatomy of an ERC-20 token
-- Review the formal specification for ERC-20
-
----
-
-## Introduction
-
-The emergence of the ERC-20 token standard marked a significant milestone in the evolution of the Ethereum ecosystem, providing a unified and adaptable framework for creating and managing fungible tokens. As the backbone for a vast array of applications in decentralized finance and beyond, ERC-20 tokens facilitate seamless collaboration and interoperability within the Ethereum ecosystem. Their adaptable nature and standardized structure have made them the go-to choice for developers and users alike, laying the groundwork for continued innovation and growth in the Ethereum space.
-
-The ERC-20 token standard has not only streamlined the creation of new tokens but also bolstered the overall user experience by establishing a consistent set of rules and functions. As a result, it has garnered widespread adoption and solidified its position as the de facto standard for fungible tokens on Ethereum, driving the expansion of the decentralized economy and fostering the development of novel applications and services.
-
-
-
-
-
----
-
-## ERC-20 Specification
-
-EIP-20 (Ethereum Improvement Proposal 20) is the formal specification for ERC-20, defining the requirements to create compliant tokens on the Ethereum blockchain. EIP-20 prescribes the mandatory functions, optional functions, and events a token must implement to achieve ERC-20 compliance. Adherence to EIP-20 allows developers to create tokens compatible with existing Ethereum applications and services, streamlining integration.
-
----
-
-## Anatomy of an ERC-20 Token
-
-An ERC-20 token consists of a smart contract that implements the standardized interface, which comprises a set of six mandatory functions:
-
-- **totalSupply():** Returns the total supply of the token.
-- **balanceOf(address):** Provides the balance of tokens held by a specific address.
-- **transfer(address, uint256):** Transfers a specified amount of tokens from the sender's address to the specified recipient's address.
-- **transferFrom(address, address, uint256):** Enables a third party to transfer tokens on behalf of the token owner, given that the owner has approved the transaction.
-- **approve(address, uint256):** Allows the token owner to grant permission to a third party to spend a specified amount of tokens on their behalf.
-- **allowance(address, address):** Returns the amount of tokens the token owner has allowed a third party to spend on their behalf.
-
-Additionally, ERC-20 tokens can include optional functions that provide descriptive information about the token:
-
-- **name():** Returns the name of the token, for example, "Uniswap."
-- **symbol():** Provides the token's symbol, like "UNI."
-- **decimals():** Indicates the number of decimal places the token can be divided into, typically 18 for most tokens.
-
----
-
-## Benefits of ERC-20 Standardization
-
-The standardization of ERC-20 tokens provides several benefits for both developers and users. For developers, it simplifies the process of creating new tokens by providing a consistent set of functions and conventions. This reduces the likelihood of errors and ensures a smooth integration with existing applications and services in the Ethereum ecosystem.
-
-
-
-
-
-For users, the standardized interface makes it easier to interact with a wide variety of tokens, regardless of their specific purpose or implementation. This means that users can effortlessly check their token balance, transfer tokens, or approve transactions using the same set of functions, whether they are interacting with a governance token like UNI or a stablecoin like USDC.
-
-
-
-
-
----
-
-## Applications
-
-ERC-20 tokens find wide-ranging applications in various categories, each with its unique purpose and functionality:
-
-- **Utility tokens:** These tokens can be used to access specific services or features within a platform. Examples include Filecoin (FIL) for decentralized storage, Basic Attention Token (BAT) for digital advertising, and Decentraland's MANA for purchasing virtual land and assets.
-
-- **Governance tokens:** These tokens grant voting rights and influence over the development of a project, allowing holders to participate in decision-making processes. Examples include Uniswap (UNI), Aave (AAVE), and Compound (COMP).
-
-- **Stablecoins:** These tokens maintain a relatively stable value pegged to a reserve of assets or fiat currency, providing a less volatile option for transactions and trading. Examples include USD Coin (USDC), Tether (USDT), and MakerDAO's DAI.
-
-- **Liquidity tokens:** Liquidity providers on DeFi platforms often receive ERC-20 tokens as a representation of their share in a liquidity pool. These tokens can be staked or traded, and they enable users to earn rewards for providing liquidity. Examples include Uniswap LP tokens and Curve LP tokens.
-
-- **Rewards tokens:** Some platforms issue ERC-20 tokens as incentives for users to participate in their ecosystem, such as staking, lending, or providing liquidity. These tokens can be earned as passive income or used to access additional platform features. Examples include Synthetix (SNX) and SushiSwap (SUSHI).
-
-Each of these use cases demonstrates the adaptability of ERC-20 tokens to serve different needs within the blockchain ecosystem.
-
----
-
-## Conclusion
-
-By providing a consistent framework for fungible tokens and adhering to the formal EIP-20 specification, ERC-20 has enabled the development of countless projects and applications that have revolutionized how value is exchanged and managed on Ethereum. Analyzing the anatomy of an ERC-20 token and reviewing its formal specification reveal the versatility and importance of this token standard.
-
----
-
-## See Also
-
-- [Introduction to Ethereum Improvement Proposals (EIPs)](https://ethereum.org/en/eips/)
-- [EIP-20: ERC-20 Token Standard](https://eips.ethereum.org/EIPS/eip-20)
-- [ERC-20 Token Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/)
diff --git a/docs/learn/token-development/erc-20-token/erc-20-testing-vid.mdx b/docs/learn/token-development/erc-20-token/erc-20-testing-vid.mdx
deleted file mode 100644
index 4214a1c6f..000000000
--- a/docs/learn/token-development/erc-20-token/erc-20-testing-vid.mdx
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: ERC-20 Testing
-description: Test the OpenZeppelin ERC-20 implementation.
-hide_table_of_contents: false
-sidebarTitle: Testing ERC-20
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
diff --git a/docs/learn/token-development/erc-20-token/erc-20-token-sbs.mdx b/docs/learn/token-development/erc-20-token/erc-20-token-sbs.mdx
deleted file mode 100644
index 34b9c8150..000000000
--- a/docs/learn/token-development/erc-20-token/erc-20-token-sbs.mdx
+++ /dev/null
@@ -1,141 +0,0 @@
----
-title: ERC-20 Implementation
-sidebarTitle: Step by Step Guide
-description: Implement your own ERC-20 token.
-hide_table_of_contents: false
----
-
-The ERC-20 is a standard that allows for the development of fungible tokens and helps sites and apps, such as exchanges, know how to find and display information about these tokens. You can leverage existing implementations, such as the one by [OpenZeppelin] to develop your own tokens.
-
----
-
-## Objectives
-
-By the end of this lesson you should be able to:
-
-- Describe OpenZeppelin
-- Import the OpenZeppelin ERC-20 implementation
-- Describe the difference between the ERC-20 standard and OpenZeppelin's ERC20.sol
-- Build and deploy an ERC-20 compliant token
-
----
-
-## Setting Up the Contract
-
-Create a new Solidity file, add the license and pragma, and import the ERC-20 implementation linked above.
-
-Add a contract called `MyERC20Token` that inherits from `ERC20`.
-
-```solidity
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.17;
-
-import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol";
-
-contract MyERC20Token is ERC20 {
-
-}
-```
-
-### Adding a Constructor
-
-Review the constructor on line 53 of the [OpenZeppelin] implementation. It requires strings for the name and symbol you wish to use for your token. They're using a slightly different naming convention by putting the `_` after the name of the parameters. Like any other function, you can pass variables of **any** name as long as they're the right type, so feel free to continue adding the `_` in front in your contract's constructor:
-
-```solidity
-constructor(string memory _name, string memory _symbol) ERC20(_name, _symbol) {
-
-}
-```
-
-
-There is neither a governing body nor built-in programmatic rules preventing you, or anyone else, from using the same name and symbol as an already in-use token. Scammers often take advantage of this fact, and even well-meaning developers can cause confusion by not being careful here.
-
-
-
-That's it. You're done! Deploy and test, and you should see all of the functionality called for by the standard and provided by the OpenZeppelin implementation.
-
-
-
-
-
-Do some testing. You'll see that the `totalSupply` and all balances are zero.
-
-By default, the decimal for the token will be 18, which is the most common choice. Remember, there aren't decimal types yet, so 1.0 ETH is really a `uint` holding 1 \* 10\*\*18, or 1000000000000000000.
-
----
-
-## ERC-20 Further Testing
-
-Line 251 of the [OpenZeppelin] implementation contains a `_mint` function, but it's internal. As a result, you'll need to figure out a minting mechanism and add it via your own contract.
-
-### Minting in the Constructor
-
-One method of using the `_mint` function is to create an initial supply of tokens in the constructor. Add a call to `_mint` that awards 1 full token to the contract creator. Remember, the decimal is 18. Minting literally `1` is creating a tiny speck of dust.
-
-```solidity
-constructor(string memory _name, string memory _symbol) ERC20(_name, _symbol) {
- _mint(msg.sender, 1 * 10**18);
-}
-```
-
-Redeploy. Without you needing to do anything, you should find that the `totalSupply` is now 1000000000000000000, as is the `balanceOf` the deploying address.
-
-You can also use this to mint to other users. Go ahead and add the second and third accounts:
-
-
-
-```solidity
-constructor(string memory _name, string memory _symbol) ERC20(_name, _symbol) {
- _mint(msg.sender, 1 * 10**18);
- _mint(0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2, 1 * 10**18);
- _mint(0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db, 1 * 10**18);
-}
-```
-
-
-
-
-**Switch back** to the first account and redeploy. Test to confirm that each account has the appropriate amount of tokens.
-
-### Testing the Transfer Function
-
-Try using the `transfer` function to move tokens around.
-
-What happens if you try to burn a token by sending it to the zero address? Give it a try!
-
-You'll get an error, because protecting from burning is built into the `_transfer` function.
-
-```text
-transact to MyERC20Token.transfer pending ...
-transact to MyERC20Token.transfer errored: VM error: revert.
-
-revert
- The transaction has been reverted to the initial state.
-Reason provided by the contract: "ERC20: transfer to the zero address".
-Debug the transaction to get more information.
-```
-
-### Testing the Transfer From Function
-
-You might have noticed that there's another function called `transferFrom`. What's that for? Check the documentation in the contract to find out!
-
-This function works with the `allowance` function to give the owner of one wallet permission to spend up to a specified amount of tokens owned by another. Exchanges can make use of this to allow a user to post tokens for sale at a given price without needing to take possession of them.
-
----
-
-## ERC-20 Final Thoughts
-
-The world is still figuring out how to handle all of the new possibilities tokens provide. Old laws are being applied in new ways, and new laws are being written. Different jurisdictions are doing this in unique and sometimes conflicting ways.
-
-You should consult with a lawyer in your jurisdiction before releasing your own tokens.
-
----
-
-## Conclusion
-
-In this lesson, you've learned how easy it is to create an ERC-20 compliant token by using the OpenZeppelin implementation. You've reviewed at least one method to mint an initial supply of tokens, and that it's up to you to figure out the best way to create your tokens and follow all relevant laws and regulations.
-
----
-
-[OpenZeppelin]: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol
diff --git a/docs/learn/token-development/erc-20-token/openzeppelin-erc-20-vid.mdx b/docs/learn/token-development/erc-20-token/openzeppelin-erc-20-vid.mdx
deleted file mode 100644
index baf1e8175..000000000
--- a/docs/learn/token-development/erc-20-token/openzeppelin-erc-20-vid.mdx
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: OpenZeppelin ERC-20 Implementation
-description: Review a popular implementation of the ERC-20 standard.
-hide_table_of_contents: false
-sidebarTitle: OpenZeppelin ERC-20
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
diff --git a/docs/learn/token-development/erc-721-token/erc-721-exercise.mdx b/docs/learn/token-development/erc-721-token/erc-721-exercise.mdx
deleted file mode 100644
index dd6a5e119..000000000
--- a/docs/learn/token-development/erc-721-token/erc-721-exercise.mdx
+++ /dev/null
@@ -1,87 +0,0 @@
----
-title: ERC-721 Tokens Exercise
-description: Exercise - Create your own NFT!
-sidebarTitle: Exercise
-hide_table_of_contents: false
----
-
-import { Danger } from "/snippets/danger.mdx";
-
-Create a contract that adheres to the following specifications.
-
----
-
-## Contract
-
-Create a contract called `HaikuNFT`. Add the following to the contract:
-
-- A `struct` called `Haiku` to store the `address` of the `author` and `line1`, `line2`, and `line3`
-- A public array to store these `haikus`
-- A public `mapping` to relate `sharedHaikus` from the `address` of the wallet shared with, to the id of the Haiku NFT shared
-- A public `counter` to use as the id and to track and share the total number of Haikus minted
- - If 10 Haikus have been minted, the counter should be at 11, to serve as the next id
- - Do **NOT** assign an id of 0 to a haiku
-- Other variables as necessary to complete the task
-
-Add the following functions.
-
-### Constructor
-
-As appropriate.
-
-### Mint Haiku
-
-Add an `external` function called `mintHaiku` that takes in the three lines of the poem. This function should mint an NFT for the minter and save their Haiku.
-
-Haikus must be **unique**! If any line in the Haiku has been used as any line of a previous Haiku, revert with `HaikuNotUnique()`.
-
-You **don't** have to count syllables, but it would be neat if you did! (No promises on whether or not we counted the same as you did)
-
-### Share Haiku
-
-Add a `public` function called `shareHaiku` that allows the owner of a Haiku NFT to share that Haiku with the designated `address` they are sending it `_to`. Doing so should add it to that address's entry in `sharedHaikus`.
-
-If the sender isn't the owner of the Haiku, instead revert with an error of `NotYourHaiku`. Include the id of the Haiku in the error.
-
-
-Remember, everything on the blockchain is public. This sharing functionality can be expanded for features similar to allowing an app user to display the selected shared haiku on their profile.
-
-It does nothing to prevent anyone and everyone from seeing or copy/pasting the haiku!
-
-
-
-### Get Your Shared Haikus
-
-Add a `public` function called `getMySharedHaikus`. When called, it should return an array containing all of the haikus shared with the caller.
-
-If there are no haikus shared with the caller's wallet, it should revert with a custom error of `NoHaikusShared`, with no arguments.
-
----
-
-
-The contract specification contains actions that can only be performed once by a given address. As a result, the unit tests for a passing contract will only be successful the **first** time you test.
-
-**You may need to submit a fresh deployment to pass**
-
-
-
-### Submit your Contract and Earn an NFT Badge! (BETA)
-
-
-#### Hey, where'd my NFT go!?
-
-[Testnets](../deployment-to-testnet/test-networks) are not permanent! Base Goerli [will soon be sunset](https://base.mirror.xyz/kkz1-KFdUwl0n23PdyBRtnFewvO48_m-fZNzPMJehM4), in favor of Base Sepolia.
-
-As these are separate networks with separate data, your NFTs **will not** transfer over.
-
-**Don't worry!** We've captured the addresses of all NFT owners on Base Goerli and will include them when we release the mechanism to transfer these NFTs to mainnet later this year! You can also redeploy on Sepolia and resubmit if you'd like!
-
-
-
-{/* */}
-
-
diff --git a/docs/learn/token-development/erc-721-token/erc-721-on-opensea-vid.mdx b/docs/learn/token-development/erc-721-token/erc-721-on-opensea-vid.mdx
deleted file mode 100644
index 6fc973036..000000000
--- a/docs/learn/token-development/erc-721-token/erc-721-on-opensea-vid.mdx
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: ERC-721 Token On Opensea
-description: Learn how a popular marketplace interprets tokens.
-hide_table_of_contents: false
-sidebarTitle: OpenSea Integration
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
diff --git a/docs/learn/token-development/erc-721-token/erc-721-sbs.mdx b/docs/learn/token-development/erc-721-token/erc-721-sbs.mdx
deleted file mode 100644
index 4261f5988..000000000
--- a/docs/learn/token-development/erc-721-token/erc-721-sbs.mdx
+++ /dev/null
@@ -1,296 +0,0 @@
----
-title: ERC-721 Token
-description: Build your own NFT based on the ERC-721 standard.
-hide_table_of_contents: false
-sidebarTitle: Step by Step Guide
----
-
-import { Danger } from "/snippets/danger.mdx";
-
-Punks, Apes, and birds of all kinds. You've heard about them, seen them, and may even be lucky enough to own a famous NFT. Or maybe you've just bought into a random collection and aren't sure what to do with your NFT. NFTs aren't really pictures, or anything else specific. They're a method of proving ownership of a digital asset. Anyone can right-click on a picture of a monkey and set it as their profile picture, but only the owner can use it with apps that utilize web3 ownership.
-
-The ERC-721 token standard is the underlying technical specification that not only makes digital ownership possible, it provides a standardized way for marketplaces, galleries, and other sites to know how to interact with these digital items.
-
----
-
-## Objectives
-
-By the end of this lesson you should be able to:
-
-- Analyze the anatomy of an ERC-721 token
-- Compare and contrast the technical specifications of ERC-20 and ERC-721
-- Review the formal specification for ERC-721
-- Build and deploy an ERC-721 compliant token
-- Use an ERC-721 token to control ownership of another data structure
-
----
-
-## Implementing the OpenZeppelin ERC-721 Token
-
-JPGs may be all the rage right now but in the future, the selfie you post on social media, a text message you send to your mother, and the +4 battleaxe you wield in your favorite MMO might all be NFTs.
-
-### Import and Setup
-
-Start by opening the [OpenZeppelin] ERC-721 in Github. Copy the link and use it to import the ERC-721 contract. Create your own contract, called `MyERC721`, that inherits from `ERC721Token`. Add a constructor that initializes the `_name` and `_symbol`.
-
-
-
-```solidity
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.17;
-
-import "https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol";
-
-contract MyERC721Token is ERC721 {
- constructor(string memory _name, string memory _symbol) ERC721(_name, _symbol) {
-
- }
-}
-```
-
-
-### Minting NFTs
-
-The minting function that is provided by OpenZeppelin, `_safeMint`, is `internal`. To use it to let your customers mint NFTs, you'll need to implement a function in your contract that calls the one in the imported contract.
-
-Before you can do that, you need a way to supply the two parameters needed for `_safeMint`:
-
-- `address to` - the owner of the new NFT
-- `uint256 tokenId` - the ID number for the new NFT
-
-The owner is easy, you can simply use `msg.sender` to grant ownership to the wallet doing the minting.
-
-ID is slightly more challenging. A common practice is to simply assign the total number of NFTs, including the one being minted, as the `tokenId`. Doing so is straightforward, makes it easier to find all of the NFTs within a collection, and helps lean in to the common community perception that lower-number NFTs are better, just like other limited-edition collectibles.
-
-
-Obfuscating certain information, such as customer IDs, is often considered a best practice. Doing so might make it harder for an attacker who has circumvented other security functions from getting access to more data. If `134` is a valid `customer_id`, it is likely that `135` is too. The same can't be said for `bfcb51bd-c04f-42d5-8116-3def754e8c32`.
-
-This practice is not as useful on the blockchain, because all information is public.
-
-
-
-To implement ID generation, simply add a `uint` called `counter` to storage and initialize it as 1, either at declaration or in the constructor.
-
-Now, you can add a function called `redeemNFT` that calls `safeMint` using the `msg.sender` and `counter`, and then increments the `counter`:
-
-
-
-```solidity
-function redeemNFT() external {
- _safeMint(msg.sender, counter);
- counter++;
-}
-```
-
-
-
-
-As a programmer, you've probably gone through great pains to internalize the idea of zero-indexing. Arrays start at 0. The pixel in the top-left corner of your screen is located at 0, 0.
-
-As a result, you need to be very careful when working with Solidity because there isn't the concept of `undefined`, and "deleted" values return to their default value, which is 0 for numbers.
-
-To prevent security risks, you'll need to make sure that you never give an ID or array index of 0 to anything. Otherwise, attempting to delete a value, such as a `struct` member called `authorizedSellerID` might give the wallet address stored at index 0 access to that resource.
-
-
-
-Deploy and test. Be sure to:
-
-- Mint several NFTs
-- Transfer an NFT from one Remix account to another
-- Try to transfer an NFT to `0x0000000000000000000000000000000000000000`
-
----
-
-## ERC-721 URIs
-
-The ERC-721 standard includes the option to define a [URI] associated with each NFT. These are intended to point to a `json` file following the _ERC721 Metadata JSON Schema_
-
-```json
-{
- "title": "Asset Metadata",
- "type": "object",
- "properties": {
- "name": {
- "type": "string",
- "description": "Identifies the asset to which this NFT represents"
- },
- "description": {
- "type": "string",
- "description": "Describes the asset to which this NFT represents"
- },
- "image": {
- "type": "string",
- "description": "A URI pointing to a resource with mime type image/* representing the asset to which this NFT represents. Consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive."
- }
- }
-}
-```
-
-Note that they don't have to. In the OpenZeppelin implementation, the function that returns the `_baseURI` is `virtual` and must be overridden by an inheriting contract.
-
-```
-// OpenZeppelin ERC-721
-/**
- * @dev Base URI for computing {tokenURI}. If set, the resulting URI for each
- * token will be the concatenation of the `baseURI` and the `tokenId`. Empty
- * by default, can be overridden in child contracts.
- */
-function _baseURI() internal view virtual returns (string memory) {
- return "";
-}
-```
-
-The owner of the contract can therefore choose what the value is and when, how, or if it is changeable. For example, the [Bored Ape Yacht Club] contract has a function allowing the owner to set or change the \_baseURI, changing where the metadata is stored, and potentially what is in it.
-
-```solidity
-// From boredapeyachtclub.sol
-function setBaseURI(string memory baseURI) public onlyOwner {
- _setBaseURI(baseURI);
-}
-```
-
-The metadata for [BAYC] is [stored on IPFS], but some projects even use centralized, web2 storage options!
-
-### NFT Switcheroo
-
-[Doodles] is another NFT collection that [uses IPFS] to store metadata. Let's modify our contract to swap metadata back and forth from one collection to the other.
-
-Start by saving the IPFS metadata bases as constants, at the contract level. Add an enum to enable selection between these two choices, and an instance of that enum.
-
-
-
-```solidity
- string constant BAYC = "https://ipfs.io/ipfs/QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/";
- string constant DOODLES = "https://ipfs.io/ipfs/QmPMc4tcBsMqLRuCQtPmPe84bpSjrC3Ky7t3JWuHXYB4aS/";
-
- enum NFTMetadata { BAYC, DOODLES }
- NFTMetadata nftMetadata = NFTMetadata.BAYC;
-```
-
-
-
-Finally, add an override of `_baseURI` that returns the appropriate selection based on which collection is active, and a function to swap the URI.
-
-
-
-```solidity
-function _baseURI() internal override view returns(string memory) {
- if (nftMetadata == NFTMetadata.BAYC) {
- return BAYC;
- } else if (nftMetadata == NFTMetadata.DOODLES){
- return DOODLES;
- } else {
- revert("Error...");
- }
-}
-
-function switchURI() public {
- // TODO: Limit to contract owner
- nftMetadata = nftMetadata == NFTMetadata.BAYC ? NFTMetadata.DOODLES : NFTMetadata.BAYC;
-}
-```
-
-
-
-Deploy, mint some NFTs, and call `tokenURI` to find the information for token number 1. You should get:
-
-```text
-https://ipfs.io/ipfs/QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/1
-```
-
-This links to the metadata json file for the first Bored Ape:
-
-```json
-{
- "image": "ipfs://QmPbxeGcXhYQQNgsC6a36dDyYUcHgMLnGKnF8pVFmGsvqi",
- "attributes": [
- {
- "trait_type": "Mouth",
- "value": "Grin"
- },
- {
- "trait_type": "Clothes",
- "value": "Vietnam Jacket"
- },
- {
- "trait_type": "Background",
- "value": "Orange"
- },
- {
- "trait_type": "Eyes",
- "value": "Blue Beams"
- },
- {
- "trait_type": "Fur",
- "value": "Robot"
- }
- ]
-}
-```
-
-IPFS links don't work natively directly in the browser, but you can see the image here:
-
-https://ipfs.io/ipfs/QmPbxeGcXhYQQNgsC6a36dDyYUcHgMLnGKnF8pVFmGsvqi/
-
-Now, call your `switchURI` function and then call `tokenURI` again for token 1.
-
-Now, you'll get a new link for metadata:
-
-```text
-https://ipfs.io/ipfs/QmPMc4tcBsMqLRuCQtPmPe84bpSjrC3Ky7t3JWuHXYB4aS/1
-```
-
-Which contains the metadata for Doodle 1 instead of BAYC 1:
-
-```json
-{
- "image": "ipfs://QmTDxnzcvj2p3xBrKcGv1wxoyhAn2yzCQnZZ9LmFjReuH9",
- "name": "Doodle #1",
- "description": "A community-driven collectibles project featuring art by Burnt Toast. Doodles come in a joyful range of colors, traits and sizes with a collection size of 10,000. Each Doodle allows its owner to vote for experiences and activations paid for by the Doodles Community Treasury. Burnt Toast is the working alias for Scott Martin, a Canadian\u2013based illustrator, designer, animator and muralist.",
- "attributes": [
- {
- "trait_type": "face",
- "value": "holographic beard"
- },
- {
- "trait_type": "hair",
- "value": "white bucket cap"
- },
- {
- "trait_type": "body",
- "value": "purple sweater with satchel"
- },
- {
- "trait_type": "background",
- "value": "grey"
- },
- {
- "trait_type": "head",
- "value": "gradient 2"
- }
- ]
-}
-```
-
-Your robot ape is now a person with a rainbow beard!
-
-https://ipfs.io/ipfs/QmTDxnzcvj2p3xBrKcGv1wxoyhAn2yzCQnZZ9LmFjReuH9
-
----
-
-## Conclusion
-
-In this lesson, you've learned how to use OpenZeppelin's ERC-721 implementation to create your own NFT contract. You've also learned how NFT metadata is stored, and that it is not necessarily immutable.
-
----
-
-[OpenZeppelin]: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC721/ERC721.sol
-[Coinbase NFT]: https://nft.coinbase.com/
-[URI]: https://en.wikipedia.org/wiki/Uniform_Resource_Identifier
-[stored on IPFS]: https://ipfs.io/ipfs/QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/
-[BAYC]: https://nft.coinbase.com/collection/ethereum/0xbc4ca0eda7647a8ab7c2061c2e118a18a936f13d
-[CryptoPunks]: https://nft.coinbase.com/collection/ethereum/0xb47e3cd837ddf8e4c57f05d70ab865de6e193bbb
-[Doodles]: https://nft.coinbase.com/collection/ethereum/0x8a90cab2b38dba80c64b7734e58ee1db38b8992e
-[uses IPFS]: https://ipfs.io/ipfs/QmeSjSinHpPnmXmspMjwiXyN6zS4E9zccariGR3jxcaWtq/
-
diff --git a/docs/learn/token-development/erc-721-token/erc-721-standard-video.mdx b/docs/learn/token-development/erc-721-token/erc-721-standard-video.mdx
deleted file mode 100644
index 8f8e36175..000000000
--- a/docs/learn/token-development/erc-721-token/erc-721-standard-video.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: ERC-721 Token Standard
-description: Review the formal standard for the ERC-721 Token.
-hide_table_of_contents: false
-sidebarTitle: ERC-721 Standard
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
-
diff --git a/docs/learn/token-development/erc-721-token/erc-721-standard.mdx b/docs/learn/token-development/erc-721-token/erc-721-standard.mdx
deleted file mode 100644
index aaebe27cb..000000000
--- a/docs/learn/token-development/erc-721-token/erc-721-standard.mdx
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: The ERC-721 Token Standard
-description: An overview of the ERC-721 token standard
-hide_table_of_contents: false
-sidebarTitle: Standard Overview
----
-
-In this article, we'll delve into the ERC-721 token standard, exploring its technical specs, applications, and how it differs from the ERC-20 standard.
-
----
-
-## Objectives:
-
-By the end of this lesson you should be able to:
-
-- Analyze the anatomy of an ERC-721 token
-- Compare and contrast the technical specifications of ERC-20 and ERC-721
-- Review the formal specification for ERC-721
-
----
-
-## Introduction
-
-The development of the Ethereum ecosystem has been marked by key milestones, two of which are the inception of the ERC-20 and ERC-721 token standards. While ERC-20 provided a foundational framework for fungible tokens, ERC-721 established a flexible and adaptable infrastructure for non-fungible tokens (NFTs).
-
-The ERC-721 token standard is pivotal in the Ethereum ecosystem for creating and managing unique digital assets. With its consistent rules and functions, it has greatly enhanced the user experience, solidifying its position as the go-to standard for non-fungible tokens. ERC-721 has been instrumental in expanding the digital collectibles market and spurring the development of new applications and services.
-
-
-
-
-
----
-
-## ERC-721 Specification
-
-EIP-721 (Ethereum Improvement Proposal 721) is the formal specification for ERC-721, defining the requirements for creating compliant non-fungible tokens on Ethereum. EIP-721 prescribes mandatory functions and events that a token must implement to achieve ERC-721 compliance. Adherence to EIP-721 ensures compatibility of unique tokens with existing Ethereum applications and services, simplifying integration.
-
----
-
-## Anatomy of an ERC-721 Token
-
-An ERC-721 token comprises a smart contract implementing the standardized interface, which includes six primary functions:
-
-- **balanceOf(address)** Returns the number of tokens held by a specific address.
-- **ownerOf(uint256):** Provides the owner of a specified token.
-- **safeTransferFrom(address, address, uint256):** Transfers a specific token's ownership from one address to another.
-- **transferFrom(address, address, uint256):** Allows a third party to transfer tokens on the token owner's behalf, given the owner's approval.
-- **approve(address, uint256):** Enables the token owner to permit a third party to transfer a specific token on their behalf.
-- **getApproved(uint256):** Shows the approved address for a specific token.
-
-These functions ensure each ERC-721 token has a unique identifier and can be owned and transferred individually.
-
----
-
-## ERC-721 Vs ERC-20
-
-The ERC-721 and ERC-20 token standards share a common goal of providing a set of standards for tokens on the Ethereum network but diverge in terms of functionality and use cases.
-
-ERC-20 tokens are fungible, meaning each token is identical to every other token; they are interchangeable like currency. On the other hand, ERC-721 tokens are non-fungible, meaning each token is unique and not interchangeable with any other token. This uniqueness is made possible through the ownerOf() and getApproved() functions, which provide information about the ownership of each unique token.
-
-The ERC-20 standard has primarily found use in creating cryptocurrencies for apps, governance tokens, utility tokens, stablecoins, and more. The ERC-721 standard, conversely, has been adopted largely for creating unique digital assets like collectibles, digital art, and tokenized virtual real estate, among other applications.
-
----
-
-## Benefits of ERC-721 Standardization
-
-Standardizing non-fungible tokens via the ERC-721 token standard presents substantial benefits to developers and users in the Ethereum ecosystem. Developers have access to a standardized set of functions, leading to less code ambiguity, fewer errors, and a streamlined development process. This uniformity also ensures smooth integration with existing apps and platforms on Ethereum.
-
-For users, the ERC-721 standard offers an intuitive, consistent interface for interacting with a wide array of unique tokens. Regardless of the token's specific use or design, users can reliably check their ownership of tokens, transfer tokens to other addresses, and approve transactions. This consistency enhances usability across the Ethereum platform, from digital art marketplaces to tokenized real estate and gaming applications.
-
-
-
-
-
----
-
-## Applications
-
-ERC-721 tokens find wide-ranging applications in various categories:
-
-- **Digital Art:** Artists can create unique digital artworks as ERC-721 tokens. These tokens can be sold or traded on platforms like OpenSea, Rarible, and Coinbase NFT. Examples include work by the digital artist Beeple.
-
-- **Gaming:** Game assets such as characters, items, and land can be tokenized as ERC-721 tokens, providing players with true ownership of their in-game assets. Examples include Axie Infinity and Decentraland.
-
-- **Collectibles:** ERC-721 tokens can represent unique collectible items in a digital space. Examples include NBA Top Shot moments and CryptoPunks.
-
-- **Virtual Real Estate:** Virtual real estate can be tokenized as ERC-721 tokens, providing proof of ownership and facilitating trade on virtual platforms. Examples include parcels of land in Cryptovoxels and Decentraland.
-
----
-
-## Conclusion
-
-ERC-721, with its consistent framework for non-fungible tokens, has revolutionized the unique digital asset space on Ethereum. This standard, when contrasted with ERC-20, highlights Ethereum's capacity for both fungible and unique asset types. Adhering to the EIP-721 specification, ERC-721 tokens have significantly influenced the Ethereum-based digital economy. From digital art to gaming, these tokens underscore their importance and role as catalysts in the burgeoning NFT revolution.
-
----
-
-## See Also
-
-- [EIP-721: ERC-721 Token Standard](https://eips.ethereum.org/EIPS/eip-721)
-- [ERC-721 Token Standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-721/)
-
diff --git a/docs/learn/token-development/erc-721-token/implementing-an-erc-721-vid.mdx b/docs/learn/token-development/erc-721-token/implementing-an-erc-721-vid.mdx
deleted file mode 100644
index 9a5c511d7..000000000
--- a/docs/learn/token-development/erc-721-token/implementing-an-erc-721-vid.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: Implementing an ERC-721
-description: Deploy your own NFT.
-hide_table_of_contents: false
-sidebarTitle: Implementation Guide
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
-
diff --git a/docs/learn/token-development/erc-721-token/openzeppelin-erc-721-vid.mdx b/docs/learn/token-development/erc-721-token/openzeppelin-erc-721-vid.mdx
deleted file mode 100644
index bd7d71bc0..000000000
--- a/docs/learn/token-development/erc-721-token/openzeppelin-erc-721-vid.mdx
+++ /dev/null
@@ -1,11 +0,0 @@
----
-title: OpenZeppelin ERC-721 Implementation
-description: Review the ERC-721 implementation by OpenZeppelin.
-hide_table_of_contents: false
-sidebarTitle: OpenZeppelin ERC-721
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
-
diff --git a/docs/learn/token-development/intro-to-tokens/intro-to-tokens-vid.mdx b/docs/learn/token-development/intro-to-tokens/intro-to-tokens-vid.mdx
deleted file mode 100644
index a70e30156..000000000
--- a/docs/learn/token-development/intro-to-tokens/intro-to-tokens-vid.mdx
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Introduction
-sidebarTitle: Tokens Overview
-description: Welcome to the wonderful world of tokens!
-hide_table_of_contents: false
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
diff --git a/docs/learn/token-development/intro-to-tokens/misconceptions-about-tokens-vid.mdx b/docs/learn/token-development/intro-to-tokens/misconceptions-about-tokens-vid.mdx
deleted file mode 100644
index 65b3a2dcf..000000000
--- a/docs/learn/token-development/intro-to-tokens/misconceptions-about-tokens-vid.mdx
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Common Misconceptions
-description: Review some common misconceptions before starting.
-hide_table_of_contents: false
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
-
diff --git a/docs/learn/token-development/intro-to-tokens/tokens-overview.mdx b/docs/learn/token-development/intro-to-tokens/tokens-overview.mdx
deleted file mode 100644
index f94ef6c97..000000000
--- a/docs/learn/token-development/intro-to-tokens/tokens-overview.mdx
+++ /dev/null
@@ -1,101 +0,0 @@
----
-title: Overview
-description: An overview of tokens on Ethereum
-hide_table_of_contents: false
-sidebarTitle: Overview Guide
----
-
-
-This article will provide an overview of the most popular token standards on Ethereum, including ERC-20, ERC-721, ERC-1155, and a discussion on their properties and various use cases.
-
----
-
-## Objectives:
-
-By the end of this lesson you should be able to:
-
-- Describe the properties of ERC-20 and ERC-721 tokens
-- List popular ERC-721 tokens
-- List the uses for ERC-20, ERC-721, and ERC-1155 tokens
-
----
-
-## ERC Token Standards
-
-Ethereum Request for Comments (or, ERC) is a term used to describe technical proposals and standards for Ethereum. An ERC is authored by developers and members of the Ethereum community to suggest improvements, new features, or guidelines for creating and managing tokens and smart contracts. Once an ERC is submitted, it undergoes review and discussion by the community. If it gains consensus, it can then be implemented or adopted as a standard in the ecosystem.
-
-Token standards on Ethereum form the backbone of the digital asset ecosystem. They are a set of predefined rules and guidelines that govern the creation, management, and interaction of tokens on the network. These standards ensure that tokens are compatible with various apps, wallets, and other tokens within the Ethereum ecosystem. Token standards allow developers to create tokens with consistent behavior, facilitating seamless interaction and interoperability within the network.
-
----
-
-## ERC-20
-
-ERC-20 tokens, the most widely-used token standard on Ethereum, possess several key properties that make them versatile and flexible for various applications. One of the defining characteristics of these tokens is their fungibility. Each unit of an ERC-20 token is interchangeable and holds equal value to another unit of the same token, rendering them indistinguishable from one another. In other words, one USDC token is always equal in value and interchangeable with another USDC token.
-
-Another aspect of ERC-20 tokens is their standardized interface, which includes a set of six mandatory functions: `totalSupply()`, `balanceOf(address)`, `transfer(address, uint256)`, `transferFrom(address, address, uint256)`, `approve(address, uint256)`, and `allowance(address, address)`. This standardization ensures consistency when interacting with these tokens, irrespective of their specific implementation or use case. For example, a user can easily check their token balance or transfer tokens using the same set of functions, whether they are interacting with a governance token like UNI or a stablecoin like DAI.
-
-Some notable applications of ERC-20 tokens include utility tokens (FIL, BAT, MANA), governance tokens (UNI, AAVE, COMP), and stablecoins (USDC, USDT, DAI).
-
-
-
-
-
----
-
-## ERC-721
-
-ERC-721 is a prominent token standard specifically designed for NFTs, allowing for the creation and management of unique, indivisible digital assets that each have their own special properties.
-
-In contrast to ERC-20 tokens, which are fungible and can be easily exchanged, ERC-721 tokens are non-fungible and can't be swapped on a one-to-one basis. Every token has its own attributes that set it apart from the rest. This one-of-a-kind nature enables the representation of a wide range of digital assets, including digital art, virtual real estate, and collectibles. For example, an artist could mint a one-of-a-kind digital painting, a virtual land parcel could be tokenized in a metaverse, or a rare sports card could be digitized as a collectible NFT.
-
-ERC-721 tokens, like ERC-20 tokens, follow a standardized interface but employ a unique set of functions designed for non-fungible tokens, which allow developers to interact with NFTs across multiple platforms. For instance, a developer would use the same set of functions to interact with a digital artwork NFT listed on OpenSea as they would with a virtual land parcel NFT in Decentraland.
-
-Besides their unique qualities, ERC-721 tokens come with metadata properties that offer information about the token's specific features, such as the artwork's title, the artist, and an image preview. This metadata helps users better understand and appreciate the distinct aspects of each NFT, and it is consistent across platforms.
-
-Some notable applications of ERC-721 tokens include digital art by Beeple, virtual collectibles by NBA Top Shot, virtual real estate in Decentraland, and Ethereum-based domain names like vitalik.eth on the Ethereum Name Service (ENS).
-
-
-
-
-
----
-
-## ERC-1155
-
-ERC-1155 is an innovative hybrid token standard that merges the best aspects of both fungible and non-fungible tokens, enabling developers to create and manage diverse token types using a single smart contract. This combination of features allows ERC-1155 tokens to provide greater versatility while representing a wide array of assets with different levels of fungibility.
-
-For example, a video game might use both fungible and non-fungible tokens within its ecosystem. Fungible tokens could represent in-game currencies, consumables, or resources, while non-fungible tokens could represent exclusive and unique items like character skins, weapons, or collectible cards.
-
-Digital artists can also benefit from ERC-1155, as it allows them to mint limited edition series of their artwork, with each piece in the series having unique attributes. At the same time, they can create fungible tokens that represent ownership of a specific edition number within the series.
-
-Similar to other token standards, ERC-1155 tokens adhere to a standardized interface with a set of functions that ensure consistency and compatibility across platforms and services. Furthermore, this standard enables efficient batch transfers, simplifying the process and reducing the cost of managing multiple tokens within a single application. For instance, a user who has collected various in-game items in a virtual world can leverage ERC-1155's batch transfer feature to send multiple fungible and non-fungible tokens to another user or marketplace simultaneously. This efficient approach minimizes transaction costs and the complexity typically involved in transferring numerous tokens one by one.
-
-
-
-
-
----
-
-## Other Token Standards
-
-In addition to the three most prominent token standards that we covered, it is worth mentioning that other standards like ERC-777 and ERC-4626 have been introduced to address specific use cases or challenges. ERC-777 offers enhanced security and functionality over the fungible ERC-20 standard, while ERC-4626 streamlines yield-bearing vault integration by optimizing and unifying technical parameters. These lesser-known standards highlight the ongoing innovation and adaptability of the Ethereum token ecosystem as it continues to grow and evolve.
-
----
-
-## Conclusion
-
-Ethereum's ERC token standards have played a pivotal role in shaping the digital asset ecosystem by providing clear guidelines and rules for the creation, management, and interaction of tokens on the network. From the widely-used ERC-20 standard for fungible tokens to the distinct ERC-721 standard for non-fungible tokens and the versatile hybrid ERC-1155 standard, these token standards empower developers to craft diverse tokens tailored to various use cases and applications. The standardized interfaces ensure seamless interoperability within the Ethereum ecosystem, facilitating token transfers and interactions across different platforms and services. Additional token standards, such as ERC-777 and ERC-4626, address specific challenges and further demonstrate the continuous innovation and adaptability of the Ethereum token ecosystem.
-
----
-
-## See Also
-
-- [EIP-20](https://eips.ethereum.org/EIPS/eip-20)
-- [EIP-721](https://eips.ethereum.org/EIPS/eip-721)
-- [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155)
-- [EIP-777](https://eips.ethereum.org/EIPS/eip-777)
-- [EIP-4626](https://eips.ethereum.org/EIPS/eip-4626)
-
-
-[token standards]: https://ethereum.org/en/developers/docs/standards/tokens/
-
diff --git a/docs/learn/token-development/minimal-tokens/creating-a-minimal-token-vid.mdx b/docs/learn/token-development/minimal-tokens/creating-a-minimal-token-vid.mdx
deleted file mode 100644
index 42a573685..000000000
--- a/docs/learn/token-development/minimal-tokens/creating-a-minimal-token-vid.mdx
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Create a Minimal Token
-description: Learn to build a very simple token.
-sidebarTitle: Creatiing a Minimal Token
-hide_table_of_contents: false
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
diff --git a/docs/learn/token-development/minimal-tokens/minimal-token-sbs.mdx b/docs/learn/token-development/minimal-tokens/minimal-token-sbs.mdx
deleted file mode 100644
index afe5cf76d..000000000
--- a/docs/learn/token-development/minimal-tokens/minimal-token-sbs.mdx
+++ /dev/null
@@ -1,175 +0,0 @@
----
-title: Minimal Token
-description: Build your own minimal token.
-hide_table_of_contents: false
-sidebarTitle: Step by Step Guide
----
-
-At their core, tokens are very simple. The technology powering famous NFT collections and fungible tokens worth vast amounts of money simply uses the EVM to keep track of who owns what, and provides a permissionless way for the owner to transfer what they own to someone new.
-
----
-
-## Objectives
-
-By the end of this lesson you should be able to:
-
-- Construct a minimal token and deploy to testnet
-- Identify the properties that make a token a token
-
----
-
-## Implementing a Token
-
-The minimal elements needed for a token are pretty basic. Start by creating a contract called `MinimalToken`. Add a `mapping` to relate user addresses to the number of tokens they possess. Finally, add a variable to track `totalSupply`:
-
-
-
-```solidity
-contract MinimalToken {
- mapping (address => uint) public balances;
- uint public totalSupply;
-}
-```
-
-
-
-Add a `constructor` that initializes the `totalSupply` at 3000 and assigns ownership to the contract creator:
-
-
-
-```solidity
-constructor() {
- totalSupply = 3000;
-
- balances[msg.sender] = totalSupply;
-}
-```
-
-
-
-Deploy and test to confirm that the total supply is 3000, and the balance of the first account is as well.
-
-
-
-
-
-Update the constructor and hardcode a distribution of the tokens to be evenly split between the first three test accounts:
-
-
-
-```solidity
-constructor() {
- totalSupply = 3000;
-
- balances[msg.sender] = totalSupply / 3;
- balances[0xAb8483F64d9C6d1EcF9b849Ae677dD3315835cb2] = totalSupply / 3;
- balances[0x4B20993Bc481177ec7E8f571ceCaE8A9e22C02db] = totalSupply / 3;
-}
-```
-
-
-
-Redeploy and test again. Now, each of the first three accounts should have 1000 tokens.
-
-
-
-
-
----
-
-## Transferring Tokens
-
-We can set an initial distribution of tokens and we can see balances, but we're still missing a way to allow the owners of these tokens to share them or spend them.
-
-To remediate this, all we need to do is add a function that can update the balances of each party in the transfer.
-
-Add a `function` called `transfer` that accepts an `address` of `_to` and a `uint` for the `_amount`. You don't need to add anything for `_from`, because that should only be `msg.sender`. The function should subtract the `_amount` from the `msg.sender` and add it to `_to`:
-
-
-
-```solidity
-function transfer(address _to, uint _amount) public {
- balances[msg.sender] -= _amount;
- balances[_to] += _amount;
-}
-```
-
-
-
-Double-check that you've switched back to the first address and redeploy. Then, try sending 500 tokens to the second address.
-
-
-
-
-
-What happens if you try to transfer more tokens than an account has? Give it a try!
-
-```text
-transact to MinimalToken.transfer pending ...
-transact to MinimalToken.transfer errored: VM error: revert.
-
-revert
- The transaction has been reverted to the initial state.
-Note: The called function should be payable if you send value and the value you send should be less than your current balance.
-Debug the transaction to get more information.
-```
-
-You won't be able to do it, though the `Note:` here is **misleading**. In the EVM, `payable` **only** refers to transfers of the primary token used to pay gas fees: ETH, Base ETH, Sepolia ETH, Matic, etc. It does **not** refer to the balance of our simple token.
-
-Instead, the transaction is reverting because of the built-in overflow/underflow protection. It's not a great programming practice to depend on this, so add an error for `InsufficientTokens` that returns the `newSenderBalance`.
-
-```Solidity
-function transfer(address _to, uint _amount) public {
- int newSenderBalance = int(balances[msg.sender] - _amount);
- if (newSenderBalance < 0) {
- revert InsufficientTokens(newSenderBalance);
- }
-
- balances[msg.sender] = uint(newSenderBalance);
- balances[_to] += _amount;
-}
-```
-
-Try spending too much again. You'll get the same error in Remix:
-
-```text
-transact to MinimalToken.transfer pending ...
-transact to MinimalToken.transfer errored: VM error: revert.
-
-revert
- The transaction has been reverted to the initial state.
-Note: The called function should be payable if you send value and the value you send should be less than your current balance.
-Debug the transaction to get more information.
-```
-
-However, you can use the debug tool to review the error in memory to see that it now matches your custom `error`.
-
-## Destroying Tokens
-
-Tokens can be effectively destroyed by accident, or on purpose. Accidental destruction happens when someone sends a token to an unowned wallet address. While it's possible that some day, some lucky person will create a new wallet and find a pleasant surprise, the most likely outcome is that any given randomly chosen address will never be used, thus no one will ever have the ability to use or transfer those tokens.
-
-Luckily, there are some protections here. Similar to credit card numbers, addresses have a built-in checksum that helps protect against typos. Try it out by trying to transfer tokens to the second Remix address, but change the first character in the address from `A` to `B`. You'll get an error:
-
-```text
-transact to MinimalToken.transfer errored: Error encoding arguments: Error: bad address checksum (argument="address", value="0xBb8483F64d9C6d1EcF9b849Ae677dD3315835cb2", code=INVALID_ARGUMENT, version=address/5.5.0) (argument=null, value="0xBb8483F64d9C6d1EcF9b849Ae677dD3315835cb2", code=INVALID_ARGUMENT, version=abi/5.5.0)
-```
-
-A more guaranteed way to destroy, or _burn_ a token, is to transfer it to the default address `0x0000000000000000000000000000000000000000`. This address is unowned and unownable, making it mathematically impossible to retrieve any tokens that are sent to it. Redeploy and try it out by sending 1000 tokens to the zero address.
-
-The `totalSupply` remains unchanged, and the balance of the zero address is visible, but those tokens are stuck there forever.
-
-
-The [zero address] currently has a balance of more than 11,000 ETH, worth over **20 million dollars**! Its total holding of burned assets is estimated to be worth more than **200 million dollars**!!!
-
-
-
----
-
-## Conclusion
-
-In this lesson, you've learned to implement a simple token, which is really just a system to store the balance of each address, and a mechanism to transfer them from one wallet to another. You've also learned how to permanently destroy tokens, whether by accident, or on purpose.
-
----
-
-[zero address]: https://etherscan.io/address/0x0000000000000000000000000000000000000000
-
diff --git a/docs/learn/token-development/minimal-tokens/minimal-tokens-exercise.mdx b/docs/learn/token-development/minimal-tokens/minimal-tokens-exercise.mdx
deleted file mode 100644
index 151b0e83b..000000000
--- a/docs/learn/token-development/minimal-tokens/minimal-tokens-exercise.mdx
+++ /dev/null
@@ -1,72 +0,0 @@
----
-title: Minimal Tokens Exercise
-description: Exercise - Create your own token!
-hide_table_of_contents: false
-sidebarTitle: Exercise
----
-
-Create a contract that adheres to the following specifications.
-
----
-
-## Contract
-
-Create a contract called `UnburnableToken`. Add the following in storage:
-
-- A public mapping called `balances` to store how many tokens are owned by each address
-- A `public uint` to hold `totalSupply`
-- A `public uint` to hold `totalClaimed`
-- Other variables as necessary to complete the task
-
-Add the following functions.
-
-### Constructor
-
-Add a constructor that sets the total supply of tokens to 100,000,000.
-
-### Claim
-
-Add a `public` function called `claim`. When called, so long as a number of tokens equalling the `totalSupply` have not yet been distributed, any wallet _that has not made a claim previously_ should be able to claim 1000 tokens. If a wallet tries to claim a second time, it should revert with `TokensClaimed`.
-
-The `totalClaimed` should be incremented by the claim amount.
-
-Once all tokens have been claimed, this function should revert with the error `AllTokensClaimed`. (We won't be able to test this, but you'll know if it's there!)
-
-### Safe Transfer
-
-Implement a `public` function called `safeTransfer` that accepts an address `_to` and an `_amount`. It should transfer tokens from the sender to the `_to` address, **only if**:
-
-- That address is not the zero address
-- That address has a balance of greater than zero Base Sepolia Eth
-
-A failure of either of these checks should result in a revert with an `UnsafeTransfer` error, containing the address.
-
----
-
-### Submit your Contract and Earn an NFT Badge! (BETA)
-
-
-#### Hey, where'd my NFT go!?
-
-[Testnets](/learn/deployment-to-testnet/test-networks) are not permanent! Base Goerli [will soon be sunset](https://base.mirror.xyz/kkz1-KFdUwl0n23PdyBRtnFewvO48_m-fZNzPMJehM4), in favor of Base Sepolia.
-
-As these are separate networks with separate data, your NFTs **will not** transfer over.
-
-**Don't worry!** We've captured the addresses of all NFT owners on Base Goerli and will include them when we release the mechanism to transfer these NFTs to mainnet later this year! You can also redeploy on Sepolia and resubmit if you'd like!
-
-
-
-
-The contract specification contains actions that can only be performed once by a given address. As a result, the unit tests for a passing contract will only be successful the **first** time you test.
-
-**You may need to submit a fresh deployment to pass**
-
-
-
-{/* */}
-
-
diff --git a/docs/learn/token-development/minimal-tokens/transferring-a-minimal-token-vid.mdx b/docs/learn/token-development/minimal-tokens/transferring-a-minimal-token-vid.mdx
deleted file mode 100644
index c9439826a..000000000
--- a/docs/learn/token-development/minimal-tokens/transferring-a-minimal-token-vid.mdx
+++ /dev/null
@@ -1,10 +0,0 @@
----
-title: Transferring a Minimal Token
-description: Explore how tokens are given from one owner to another.
-hide_table_of_contents: false
-sidebarTitle: Transferring Tokens
----
-
-import { Video } from '/snippets/VideoPlayer.mdx';
-
-
diff --git a/docs/learn/token-development/nft-guides/complex-onchain-nfts.mdx b/docs/learn/token-development/nft-guides/complex-onchain-nfts.mdx
deleted file mode 100644
index 6b3d9bbf9..000000000
--- a/docs/learn/token-development/nft-guides/complex-onchain-nfts.mdx
+++ /dev/null
@@ -1,867 +0,0 @@
----
-title: 'Complex Onchain NFTs'
-slug: /complex-onchain-nfts
-description: A tutorial that teaches how to make complex nfts that are procedurally generated and have onchain metadata and images.
-author: briandoyle81
-
----
-
-# Complex Onchain NFTs
-
-Many NFTs are dependent on offchain metadata and images. Some use immutable storage locations, such as [IPFS]. Others use traditional web locations, and many of these allow the owner of the contract to modify the URL returned by a contract when a site or user attempts to retrieve the location of the token art and metadata. This power isn't inherently bad, because we probably want someone to be able to fix the contract if the storage location goes down. However, it does introduce a requirement to trust the contract owner.
-
-Although challenging, it is possible to write a smart contract that contains all the necessary logic and data to generate json metadata and SVG images, entirely onchain. It **will** be expensive to deploy, but will be as cheap as simpler contracts to mint!
-
-In this tutorial, we'll show you how to do this to create your own fully-onchain art project, similar to our [sample project].
-
-## Objectives
-
-By the end of this tutorial you should be able to:
-
-- Programmatically generate and return json metadata for ERC-721 tokens
-- Deterministically construct unique SVG art in a smart contract
-- Generate deterministic, pseudorandom numbers
-
-## Prerequisites
-
-### ERC-721 Tokens
-
-This tutorial assumes that you are able to write, test, and deploy your own ERC-721 tokens using the Solidity programming language. If you need to learn that first, check out our content in [Base Learn] or the sections specific to [ERC-721 Tokens]!
-
-### Vector Art
-
-You'll need some familiarity with the SVG art format and a basic level of ability to edit and manipulate vector art. If you don't have this, find an artist friend and collaborate!
-
-## Creating the Art Assets
-
-To start, you'll need to build a few vector art assets and mock up an example of what your NFT might look like. Later, you'll cut these up and format them in a way that your smart contract will use to assemble unique NFTs for each minter.
-
-The mockup needs to have all of the elements you plan to have in the NFT, and you should be able to manually move things around or change colors to make it so that you can create the range of variation you want. For example:
-
-- A gradient sky in which the colors are randomized
-- One of three styles of sun, always in the same spot in the upper right corner
-- One to five clouds placed randomly in the upper half of the canvas
-- A wide mountain ridge that will always be in the middle, but slide side to side to show a different part for each NFT
-- An ocean in the foreground that is always the same
-
-If you are an artist, or are working with one, you can use the vector drawing tool of your choice to assemble your mockup. If not, you can use a number of stock art or AI tool options to assist you. If you do, make sure you understand any relevant laws or terms of service!
-
-You can also work from ours: [Sample Art]
-
-Either way, you should end up with something similar to this:
-
-
-
-
-
-## The Art of Making it Fit
-
-You'll notice that the SVG is probably way too big to be placed in a smart contract. The example is 103 KB, so you'll have to be clever to make this work.
-
-You'll accomplish this task by splitting each element out of the mockup and deploying them into separate smart contracts. To do so, individually export each element, and make sure that the exported pieces are no bigger than about 15 KB. That way, you'll have enough space to fit each piece within the 24KiB limit for compiled bytecode.
-
-If you're working with the sample, you'll end up with individual SVGs for:
-
-- Sun 1: 9 KB
-- Sun 2: 9 KB
-- Sun 3: 9 KB
-- Ocean: 17 KB
-- Mountain: 14 KB
-- Cloud: 6 KB
-- Sky: 802 bytes
-
-If you don't have the tools to do this, you can find these files here: [Sample Art]
-
-## Contract Architecture
-
-You'll need to build and deploy a number of contracts for this project. They'll be organized in this architecture:
-
-
-
-
-
-Deploying this many contracts will have a cost associated with it, but once they're deployed, this contract will cost the same as any other NFT contract. Remember, `pure` and `view` functions called outside the blockchain don't cost any gas. This means that you can use multiple contracts to assemble a relatively large graphic without additional costs!
-
-## Building the Contracts
-
-Create a new project using the toolkit of your choice, and add a contract called `LandSeaSkyNFT`. Import OpenZeppelin's ERC-721, inherit from it, and set it up with the constructor, a mint function, and a counter to keep track of the token ID:
-
-```solidity
-// SPDX-License-Identifier: UNLICENSED
-pragma solidity ^0.8.20;
-
-import "hardhat/console.sol";
-import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
-
-contract LandSeaSkyNFT is ERC721 {
- uint public counter;
-
- constructor() ERC721("Land, Sea, and Sky", "LSS") {}
-
- function mint() public {
- counter++;
- _safeMint(msg.sender, counter);
- }
-}
-```
-
-### Overriding the `_baseURI()` Function
-
-Normally, you'd override `_baseURI()` with the base URL for the location you select to keep your NFT metadata. This could be a website, IPFS folder, or many other possible locations.
-
-Since this contract will be generating the .json file directly, instead set it to indicate this to the browser:
-
-```solidity
-function _baseURI() internal pure override returns (string memory) {
- return "data:application/json;base64,";
-}
-```
-
-### Importing the Base64 Library
-
-As indicated above, you'll be returning the json metadata in [Base64] format. OpenZeppelin has a utility contract to do this. You'll also need the `Strings` library. Go ahead and import them:
-
-```solidity
-import "@openzeppelin/contracts/utils/Base64.sol";
-import "@openzeppelin/contracts/utils/Strings.sol";
-```
-
-
-Base64 allows the transport of binary data over the web in a reliable way. It is not a compression algorithm, and actually increased the data size by a 4/3 ratio.
-
-
-### Planning the override for the `tokenURI()` Function
-
-Next, set up your `tokenURI` function override. You'll need to write some other contracts to make this work, but you can write most of the code and stub out a plan for the rest to:
-
-- Check and ensure the token ID exists
-- Compile the json metadata for the token, including:
- - The `"name"` of the NFT
- - A `"description"`
- - The `"image"`
-- Base64 encode the above, combine it with the `_baseURI` and return it.
-
-```solidity
-function tokenURI(uint _tokenId) public view override returns (string memory) {
- if(_tokenId > counter) {
- revert InvalidTokenId(_tokenId); // Don't forget to add the error above!
- }
-
- string memory json = Base64.encode(
- bytes(
- string(
- abi.encodePacked(
- '{"name": "Land, Sea, and Sky #: ',
- Strings.toString(_tokenId),
- '", "description": "Land, Sea, and Sky is a collection of generative art pieces stored entirely onchain.", "image": "data:image/SVG+xml;base64,',
- "TODO: Build the SVG with the token ID as the seed",
- '"}'
- )
- )
- )
- );
-
- return string(abi.encodePacked(_baseURI(), json));
-}
-```
-
-
-Getting the quotes and commas correct when the json is broken apart like this is challenging. When debugging, look here first!
-
-
-### Test Your Progress
-
-Test your function by writing a simple test to mint an NFT, then call and log the output of the `tokenURI` function. You should get something similar to:
-
-```text
-string: data:application/json;base64,eyJuYW1lIjogIkxhbmQsIFNlYSwgYW5kIFNreSAjMSIsICJkZXNjcmlwdGlvbiI6ICJMYW5kLCBTZWEsIGFuZCBTa3kgaXMgYSBjb2xsZWN0aW9uIG9mIGdlbmVyYXRpdmUgYXJ0IHBpZWNlcyBzdG9yZWQgZW50aXJlbHkgb25jaGFpbi4iLCAiaW1hZ2UiOiAiZGF0YTppbWFnZS9zdmcreG1sO2Jhc2U2NCxUT0RPOiBCdWlsZCB0aGUgU1ZHIHdpdGggdGhlIHRva2VuIElEIGFzIHRoZSBzZWVkIn0=
-```
-
-To see if it worked, you'll need to use a manual method to decode the base64 data; everything after the comma:
-
-```text
-eyJuYW1lIjogIkxhbmQsIFNlYSwgYW5kIFNreSAjMSIsICJkZXNjcmlwdGlvbiI6ICJMYW5kLCBTZWEsIGFuZCBTa3kgaXMgYSBjb2xsZWN0aW9uIG9mIGdlbmVyYXRpdmUgYXJ0IHBpZWNlcyBzdG9yZWQgZW50aXJlbHkgb25jaGFpbi4iLCAiaW1hZ2UiOiAiZGF0YTppbWFnZS9zdmcreG1sO2Jhc2U2NCxUT0RPOiBCdWlsZCB0aGUgU1ZHIHdpdGggdGhlIHRva2VuIElEIGFzIHRoZSBzZWVkIn0=
-```
-
-You can use the terminal: `echo -n '' | base64 --decode`
-
-Do so, and you'll get:
-
-```text
-{"name": "Land, Sea, and Sky #: 1", "description": "Land, Sea, and Sky is a collection of generative art pieces stored entirely onchain.", "image": "data:image/SVG+xml;base64,TODO: Build the SVG with the token ID as the seed"}
-```
-
-## Building the SVG
-
-Next, you need to build logic to compile a real, working SVG from the pieces you've saved. You'll also need to add some variation based on the ID of the NFT.
-
-### SVG Renderer Contract
-
-Add a new file and contract called `SVGRenderer`. It doesn't need a constructor, but it will need the `Strings` library:
-
-```solidity
-// SPDX-License-Identifier: UNLICENSED
-pragma solidity ^0.8.20;
-
-import "hardhat/console.sol";
-import "@openzeppelin/contracts/utils/Strings.sol";
-
-contract SVGRenderer {
-
-}
-```
-
-Open the exemplar SVG in a code editor, and using it as an example, build out a function that uses `abi.encodePacked` to build everything from the SVG **except** the actual art. That's much too big for one contract, so add stubs instead.
-
-Depending on the tool you used to make the SVG, there may be unneeded extras you can remove from these lines. You also **don't** need the items in `` or ``. You'll take advantage of the flexibility of the format to include those in the pieces returned by the supporting contract.
-
-```solidity
-function render(uint _tokenId) public view returns (string memory) {
- return string(
- abi.encodePacked(
- ""
- )
- );
-}
-```
-
-### Rendering the Sea
-
-The sea element of this NFT will be the same for all NFTs, so it makes sense to write that contract first. Create it called, `SeaRenderer`, with a function called `render`. The `` element is the root of the different pieces of the SVG, so add that and a stub for the rest.
-
-```solidity
-// SPDX-License-Identifier: UNLICENSED
-pragma solidity ^0.8.20;
-
-import "hardhat/console.sol";
-import "@openzeppelin/contracts/utils/Strings.sol";
-
-contract SeaRenderer {
- function render() public pure returns (string memory) {
- return // TODO: Render the sea
- }
-}
-```
-
-The next part is tricky, and a little messy. You'll need to combine parts of the individually exported SVG that has the sea art and all of its properties with the position data for this part of the art from the exemplar SVG. You'll then need to flatten it to a single line, and add it as a string constant.
-
-Start by opening the Ocean SVG. Change the viewBox to `viewBox="0 0 1024 1024"`. Move the `` and `` tag inside of the `` tag. Open the SVG in the browser to make sure it hasn't broken.
-
-Next, delete the `id` and `data-name` from the top level `` and experiment with the `transform="translate(20,2.5)"` property to move the art back down to the bottom of the viewport.
-
-With the sample art, `` should work.
-
-The last edits you need to make are **critical** - do a find/replace to change all of the `cls-1` and similar classnames, to `cls-land-1`! Otherwise, the classes will override one another and nothing will be the right color. Also find all instances of `linear-gradient` and do the same.
-
-**Make sure** you change both the definitions, and where they're called!
-
-Finally, use the tool of your choice to minify **only** the outermost `` tag and its contents. This will flatten the code to a single line and remove extra empty character spaces. Doing so makes it easier to add to your contract, and makes the data smaller. Add it as a constant string to `SeaRenderer.sol`:
-
-```solidity
-string constant SVG = '
-
-```
-
-You have some design choices to make here. You could use deterministically chosen, but essentially random colors to make up the gradient. However, doing so will lead to the vast majority of NFTs having truly bizarre colors that don't look nice and don't look like they belong with the rest of the art.
-
-No one wants their sky to be a mix of cyan, teal, maroon, and brown!
-
-It might be better to add a gentle modification to the existing gradient colors and range. Start by minifying the top level `` group and contents, then create **two** constant strings, one for everything before the first `` element, and one for everything after the last `` element.
-
-Neither string should have the ``s. You'll make those next.
-
-### Building the Renderer Contract
-
-Add a new file and contract called `SkyRenderer`. Add your strings:
-
-```solidity
-// SPDX-License-Identifier: UNLICENSED
-pragma solidity ^0.8.20;
-
-import "hardhat/console.sol";
-import "@openzeppelin/contracts/utils/Strings.sol";
-
-string constant START = ' ';
-string constant END = ' ';
-
-contract SkyRenderer {
- function render(uint _tokenId) public pure returns (string memory) {
- return //TODO;
- }
-}
-```
-
-Next, add constants for the existing `offset` and `stop-color` properties:
-
-```solidity
-string constant OFFSET1 = ".12";
-string constant OFFSET2 = ".34";
-string constant OFFSET3 = ".68";
-string constant OFFSET4 = ".96";
-string constant COLOR1 = "#c391b4";
-string constant COLOR2 = "#ce9f9b";
-string constant COLOR3 = "#dfd061";
-string constant COLOR4 = "#e3f9f7";
-```
-
-Now, stub out your return for the `render` function. It will use the built in method of using `abi.encode` and casting to `string` to combine all the parts and return them.
-
-```solidity
-function render(uint _tokenId) public pure returns (string memory) {
- return string(
- abi.encodePacked(
- START,
- // TODO stop 1,
- // TODO stop 2,
- // TODO stop 3,
- // TODO stop 4,
- END
- )
- );
-}
-```
-
-Do the same for a function to `buildStop`:
-
-```solidity
-function _buildStop(
- string memory _offset,
- string memory _color,
- uint _tokenId,
- uint _stopNumber
- ) internal pure returns (string memory) {
- return string(
- abi.encodePacked(
- '` and `` inside the top-level group (``).
-
-Find transform/translate values that first put the mountains so that they are at the bottom, and the left-most portion is shown, then the right-most. `transform="translate(-150,350)"` and `transform="translate(-800,350)"` are about right.
-
-Don't forget to add `-land` to the classnames!
-
-### Writing the Contract
-
-Add a file and stub for the `LandRenderer`:
-
-```solidity
-// SPDX-License-Identifier: UNLICENSED
-pragma solidity ^0.8.20;
-
-import "hardhat/console.sol";
-import "@openzeppelin/contracts/utils/Strings.sol";
-
-contract LandRenderer {
- function render(uint _tokenId) public pure returns (string memory) {
- return string(
- abi.encodePacked(
- '',
- END
- )
- );
- }
-}
-```
-
-Minify the top-level `` element, and add a constant with everything after the opening `` tag. Use similar techniques as before to generate an offset based on the token id, then build the SVG. You'll end up with something like this:
-
-```solidity
-// SPDX-License-Identifier: UNLICENSED
-pragma solidity ^0.8.20;
-
-import "hardhat/console.sol";
-import "@openzeppelin/contracts/utils/Strings.sol";
-
-string constant END = "";
-
-contract LandRenderer {
- function render(uint _tokenId) public pure returns (string memory) {
- return string(
- abi.encodePacked(
- '',
- END
- )
- );
- }
-
- function _buildOffset(uint _tokenId) internal pure returns (string memory) {
- bytes32 hash = keccak256(abi.encodePacked(_tokenId));
- uint rand = uint(hash);
- uint xOffset = (rand % 650) + 150; // Produces a number between 150 and 799
- return string(abi.encodePacked("-", Strings.toString(xOffset)));
- }
-}
-```
-
-### Incorporating the LandRenderer
-
-Update `SVGRenderer`:
-
-```solidity
-ISVGPartRenderer seaRenderer;
-ISVGPartRenderer skyRenderer;
-ISVGPartRenderer landRenderer;
-
-constructor(address _seaRenderer, address _skyRenderer, address _landRenderer) {
- seaRenderer = ISVGPartRenderer(_seaRenderer);
- skyRenderer = ISVGPartRenderer(_skyRenderer);
- landRenderer = ISVGPartRenderer(_landRenderer);
-}
-
-function render(uint _tokenId) public view returns (string memory) {
- return string(
- abi.encodePacked(
- ""
- )
- );
-}
-```
-
-And the deploy script:
-
-```tsx
-const LandRenderer = await deploy('LandRenderer', {
- from: deployer,
-});
-
-const SVGRenderer = await deploy('SVGRenderer', {
- from: deployer,
- args: [SeaRenderer.address, SkyRenderer.address, LandRenderer.address],
-});
-```
-
-Test as before. It's starting to look really nice!
-
-
-
-
-
-## Adding the Sun Renderer
-
-The sun renderer will use similar techniques as those you've already incorporated. The sun will be in the same place for all NFTs. Variation will come from each one having only one of the three suns shown in the exemplar art file.
-
-### Preparing the SVGs
-
-For each of the three sun SVGs:
-
-- Change the `viewBox` to 1024x1024
-- Move the `` and `` into the first group
-- Find the correct translation to put the sun in the upper right
- - 750, 100 should work with the sample art
-- Add `-sun` to the classnames
-
-### Writing the Contracts
-
-The tricky part here is that you can't fit all the suns into one contract. They're too big! Instead, split them into three, similar to the original ocean renderer. For example:
-
-```solidity
-// SPDX-License-Identifier: UNLICENSED
-pragma solidity ^0.8.20;
-
-import "hardhat/console.sol";
-import "@openzeppelin/contracts/utils/Strings.sol";
-
-string constant SVG = ''
-
-contract SunRenderer1 {
- function render() public pure returns (string memory) {
- return SVG;
- }
-}
-```
-
-### Incorporating the SunRenderer
-
-Add the three `SunRenderer`s as you have the other rendering contracts. You'll have to incorporate this one a little differently. Add a function that picks which `SunRenderer` to call, based on the NFT id.
-
-```solidity
-function pickSunRenderer(uint _tokenId) public view returns (ISVGPartRenderer) {
- bytes32 hash = keccak256(abi.encodePacked(_tokenId));
- uint rand = uint(hash);
- uint sun = rand % 3;
- if(sun == 0) {
- return sunRenderer1;
- } else if(sun == 1) {
- return sunRenderer2;
- } else {
- return sunRenderer3;
- }
- }
-```
-
-Make sure to put it after `skyRenderer` in the main `render` function!
-
-```solidity
-function render(uint _tokenId) public view returns (string memory) {
- return string(
- abi.encodePacked(
- ""
- )
- );
-}
-```
-
-Test it out. You've now got one of three suns in the sky for each NFT!
-
-## Adding the Cloud Renderer
-
-On your own, try adding the clouds. The clouds renderer should:
-
-- Randomly select between one and seven clouds
-- Place those clouds randomly on the top half of the canvas
-- Be on the layer on top of the sun and sky, but below the sea and mountains
-
-## Conclusion
-
-In this tutorial, you've learned how to take advantage of the fact that offchain calls to your smart contracts don't use gas to create a significantly complex system to render complicated and unique NFTs, with the metadata and art existing entirely onchain. You've also explored some techniques for creating deterministic, pseudorandom numbers, and how to use them to add variation to your art. You've dealt with some of the many caveats and quirks of programmatically combining SVG files. Finally, you've practiced building multiple contracts that interact with one another.
-
-[Base Learn]: https://base.org/learn
-[ERC-721 Tokens]: https://docs.base.org/learn/erc-721-token/erc-721-standard-video
-[IPFS]: https://ipfs.tech/
-[Base64]: https://en.wikipedia.org/wiki/Base64
-[Hardhat and Hardhat Deploy]: https://docs.base.org/learn/hardhat-deploy/hardhat-deploy-sbs
-[testnet version of Opensea]: https://testnets.opensea.io/
-[sample project]: https://github.com/base-org/land-sea-and-sky
-[Sample Art]: https://github.com/base-org/land-sea-and-sky/tree/master/Final_SVGs
-[Basescan]: https://sepolia.basescan.org/
-
diff --git a/docs/learn/token-development/nft-guides/dynamic-nfts.mdx b/docs/learn/token-development/nft-guides/dynamic-nfts.mdx
deleted file mode 100644
index fc1212449..000000000
--- a/docs/learn/token-development/nft-guides/dynamic-nfts.mdx
+++ /dev/null
@@ -1,313 +0,0 @@
----
-title: 'Building dynamic NFTs'
-description: A tutorial that teaches how to make dynamic NFTs that evolve based on onchain or offchain actions.
-authors:
- - lukecd
-tags: ['nft']
-difficulty: intermediate
-hide_table_of_contents: false
-
----
-
-# Build a Dynamic NFT on Base with Irys
-
-In this tutorial, you will create a dynamic NFT using Irys's [mutability features].
-
-
-
-
-
-Dynamic NFTs are NFTs whose metadata evolves over time. They are commonly used in:
-
-- Gaming projects where in-game assets evolve as players progress
-- Loyalty programs where NFTs evolve as users accumulate points
-
-## Objectives
-
-By the end of this tutorial, you should be able to:
-
-- Permanently upload data onchain using Irys
-- Create NFT metadata and use it to mint an NFT
-- "Mutate" (change) the NFT metadata using Irys's mutability features
-
-## Prerequisites
-
-1. **Setup a Coinbase Wallet:** You'll need a web3 wallet; you'll use it to deploy the NFT contract and to sign and pay for uploads to Irys. We recommend using the [Coinbase Wallet].
-
-2. **Wallet Funding:** You'll need to fund your wallet with some Base Sepolia tokens. You can do this for free using the [Base Faucet].
-
-## About Irys
-
-[Irys] is a datachain, a blockchain optimized for data storage. Data uploaded to Irys is:
-
-- Permanent and immutable
-- Onchain
-- Censorship-resistant
-- Blockchain agnostic
-- Unconstrained (you can upload files of any size)
-
-When you store your NFT assets on Irys and mint them using a smart contract on Base, you can guarantee the NFT will be retrievable forever. Creators can rest assured that their works will endure indefinitely, while collectors can feel secure knowing their NFTs are permanently preserved.
-
-### Irys + Base
-
-Irys has a pay-once-store-forever model and accepts payment for storage using multiple tokens, including ETH on Base.
-
-## "Mutability"
-
-Data on Irys is permanent and immutable, but you use Irys's [mutability features] to simulate mutability and create dynamic NFTs that evolve based on onchain or offchain actions.
-
-
-
-
-
-Using Irys's mutability features, you create a single, static URL that is linked to a series of transactions. Then, you can add a new transaction to the series at any time, and the URL will always resolve to the most recent transaction.
-
-You'll mint your NFT using a mutable-style URL, and then push updates to that URL. The URL won't change, but the metadata it resolves to will.
-
-## About
-
-This tutorial focuses on creating a SuperMon NFT, similar to one used in a web3 game that would evolve during gameplay. The NFT starts with a basic appearance and can be "upgraded" twice. You will use the Irys CLI to "mutate" the metadata, simulating the automatic changes that would occur through player interactions in an actual game.
-
-## Smart contract
-
-You're building an NFT, which means you need a smart contract. Here's a simple one you can use to mint the NFT you'll create.
-
-```solidity filename="SuperMon.sol"
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-// Import OpenZeppelin's ERC721 and ERC721URIStorage contracts
-// These URLs are compatible with Remix IDE
-import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
-import "@openzeppelin/contracts/token/ERC721/extensions/ERC721URIStorage.sol";
-import "@openzeppelin/contracts/access/Ownable.sol";
-
-contract SuperMon is ERC721URIStorage {
- uint256 private _tokenIdCounter;
-
- // No arguments in the constructor, the owner will be the contract deployer
- constructor() ERC721("SuperMon", "SMON") {
- _tokenIdCounter = 0;
- }
-
- // Mint function to create a new NFT
- function mint(address to, string memory uri) public {
- uint256 tokenId = _tokenIdCounter;
- _tokenIdCounter += 1;
- _safeMint(to, tokenId);
- _setTokenURI(tokenId, uri);
- }
-}
-
-```
-
-Deploy the smart contract using [Remix].
-
-## Irys CLI
-
-You'll use the [Irys CLI] to upload images and metadata.
-
-### Installing the CLI
-
-Install the Irys CLI globally using the `-g` flag. Depending on your setup, you may need to use sudo.
-
-```bash
-npm i -g @irys/cli
-```
-
-Or:
-
-```bash
-sudo npm i -g @irys/cli
-```
-
-### Using private keys
-
-When executing CLI commands involving funding and signing, you must provide a private key. Use the `-w` flag to specify a private key along with the `-t` flag to signal you're using ETH on Base.
-
-```console
-irys -w -t base-eth
-```
-
-## Uploading the images
-
-
-
-
-
-[Download a zip containing PNGs] for each level, and save them on your local drive.
-
-Next, fund Irys with 0.1 [Base Sepolia ETH] to pay for your uploads.
-
-> In all of these CLI examples, make sure to replace the value of the `-w` parameter with your own private key.
-
-```console
-irys fund 100000000000000000 \
- -n devnet \
- -t base-eth \
- -w 6dd5e....54a120201cb6a \
- --provider-url https://sepolia.base.org
-```
-
-> The `fund` command accepts a value in atomic units, 0.1 ETH is equal to 100000000000000000 in atomic units.
-
-Next, use the Irys CLI to upload each of the images to the Irys Devnet.
-
-> Uploads to Irys's devnet are kept for ~60 days and are paid for using free tokens available from [faucets].
-
-```console
-irys upload image-level-1.png \
- -n devnet \
- -t base-eth \
- -w 6dd5e....54a120201cb6a \
- --provider-url https://sepolia.base.org
-
-irys upload image-level-2.png \
- -n devnet \
- -t base-eth \
- -w 6dd5e....54a120201cb6a \
- --provider-url https://sepolia.base.org
-
-irys upload image-level-3.png \
- -n devnet \
- -t base-eth \
- -w 6dd5e....54a120201cb6a \
- --provider-url https://sepolia.base.org
-```
-
-## Uploading the metadata
-
-Create three metadata files similar to the ones below. Make sure to change the value of the image field to match the URLs generated in the previous step.
-
-```json filename="metadata-level-1.json"
-{
- "name": "SuperMon",
- "symbol": "SMON",
- "image": "https://gateway.irys.xyz/3JE8cucmpLkXK1t84QwqDRv25FTB2EJWCUgpWdtvuJZd",
- "description": "Super dooper, changing shapes, changing power",
- "attributes": [
- {
- "trait_type": "supermon-level",
- "value": "1"
- }
- ]
-}
-```
-
-```json filename="metadata-level-2.json"
-{
- "name": "SuperMon",
- "symbol": "SMON",
- "image": "https://gateway.irys.xyz/3JE8cucmpLkXK1t84QwqDRv25FTB2EJWCUgpWdtvuJZd",
- "description": "Super dooper, changing shapes, changing power",
- "attributes": [
- {
- "trait_type": "supermon-level",
- "value": "2"
- }
- ]
-}
-```
-
-```json filename="metadata-level-3.json"
-{
- "name": "SuperMon",
- "symbol": "SMON",
- "image": "https://gateway.irys.xyz/3JE8cucmpLkXK1t84QwqDRv25FTB2EJWCUgpWdtvuJZd",
- "description": "Super dooper, changing shapes, changing power",
- "attributes": [
- {
- "trait_type": "supermon-level",
- "value": "3"
- }
- ]
-}
-```
-
-And upload **just the first file** using the Irys CLI.
-
-```console
-irys upload metadata-level-1.json \
- -n devnet \
- -t base-eth \
- -w 6dd5e....54a120201cb6a \
- --provider-url https://sepolia.base.org
-```
-
-The CLI will return a URL similar to `https://gateway.irys.xyz/94TNg3UUKyZ96Dj8eSo9DVkBiivAz9jT39jjMFeTFvm3`. To convert that to a mutable-style URL, interpolate it by adding `/mutable/` after the domain and before the transaction ID.
-
-Your final URL will be similar to `https://gateway.irys.xyz/mutable/94TNg3UUKyZ96Dj8eSo9DVkBiivAz9jT39jjMFeTFvm3`.
-
-## Minting the NFT
-
-To mint your NFT in Remix:
-
-1. Return to Remix.
-2. Under "Deployed Contracts", locate your contract and expand it to see its functions.
-3. Under the `Mint` function, enter the wallet address you want to mint the NFT to and the metadata URL (e.g. `https://gateway.irys.xyz/mutable/94TNg3UUKyZ96Dj8eSo9DVkBiivAz9jT39jjMFeTFvm3`) from the previous step.
-4. Click Transact.
-
-
-
-
-
-You can now view the NFT on the [Opensea Testnet].
-
-## Mutating the metadata
-
-To now "mutate" the NFT, upload a new version of the metadata tagging it as having a `Root-TX` equal to the transaction ID of your first transaction. In my example, I pass the value of `94TNg3UUKyZ96Dj8eSo9DVkBiivAz9jT39jjMFeTFvm3`, however make sure to change this to match your unique transaction ID.
-
-```console
-irys upload metadata-level-2.json \
- -n devnet \
- -t base-eth \
- -w 6dd5e....54a120201cb6a \
- --tags Root-TX 94TNg3UUKyZ96Dj8eSo9DVkBiivAz9jT39jjMFeTFvm3 \
- --provider-url https://rpc.sepolia.org
-```
-
-Return to Opensea and request that it refresh your metadata.
-
-
-
-
-
-Give it a few minutes and your updated NFT should be visible.
-
-## Free metadata uploads
-
-Uploads of less than 100 KiB are free on Irys, which is more than enough for most metadata files. This means projects can let users "evolve" their NFTs without having to pay gas fees.
-
-## Caching
-
-Wallets and NFT websites typically cache metadata to optimize performance, this can affect the visibility of updates to dynamic NFTs. While OpenSea offers a feature for users to manually request metadata refreshes, not all platforms provide this level of control. When building dynamic NFT projects, make sure to thoroughly test and understand the implications of caching on your platform.
-
-## Irys SDK
-
-This tutorial used the Irys CLI to permanently upload data. Irys also has a JS-SDK that can be used on the [server] and in the [browser].
-
-## Conclusion
-
-In this tutorial, you learned how to permanently upload data to Irys using their CLI and how to create a dynamic NFT. Data on Irys is onchain, permanent and immutable. When your NFT images and metadata are on Irys, you can guarantee to your users that the NFT will be retrievable forever.
-
-Dynamic NFTs are commonly used with gaming projects, similar to the one we built in this tutorial. However, there are countless other applications too. For example:
-
-- **Points programs**: Create an NFT representing a user's participation in a points program. As the user earns more points, the NFT evolves.
-- **Sports NFTs**: Create an NFT from a sports team that changes whenever the team wins an important game.
-- **Holiday NFTs**: Create an NFT that changes seasonally to represent different holidays.
-- **Activity tracking**: Create a health and wellness NFT that changes based on data from an activity tracker.
-
-[Irys]: https://www.irys.xyz/
-[Base Faucet]: https://docs.base.org/docs/tools/network-faucets/
-[faucets]: https://docs.base.org/docs/tools/network-faucets/
-[Base Sepolia]: https://docs.base.org/docs/tools/network-faucets/
-[browser]: https://docs.irys.xyz/build/d/irys-in-the-browser
-[Coinbase Wallet]: https://chrome.google.com/webstore/detail/coinbase-wallet-extension/hnfanknocfeofbddgcijnmhnfnkdnaad?hl=e
-[Download a zip containing PNGs]: https://gateway.irys.xyz/MoOvEzePMwFgc_v6Gw3U8ovV6ostgrkWb9tS4baAJhc
-[Irys CLI]: https://docs.irys.xyz/build/d/storage-cli/installation
-[mutability features]: https://docs.irys.xyz/build/d/features/mutability
-[Opensea Testnet]: https://testnets.opensea.io/account
-[Remix]: https://docs.base.org/tutorials/deploy-with-remix
-[server]: https://docs.irys.xyz/build/d/quickstart
-
-
diff --git a/docs/learn/token-development/nft-guides/signature-mint.mdx b/docs/learn/token-development/nft-guides/signature-mint.mdx
deleted file mode 100644
index 5e59dc165..000000000
--- a/docs/learn/token-development/nft-guides/signature-mint.mdx
+++ /dev/null
@@ -1,374 +0,0 @@
----
-title: 'Signature Mint NFT'
-slug: /signature-mint-nft
-description: A tutorial that teaches how to create a signature mint, in which minters pay their own gas, but must first be given a valid signed authorization.
-author: briandoyle81
-
----
-
-# Signature Mint NFT
-
-A _signature mint_ is a term for an NFT mint in which the recipient of the NFT pays for their own gas to receive the NFT, but may only do so if they possess a correct message signed by the owner or authorized address of the mint contract. Reasons for doing this include allowing fiat payment of minting fees, allowing holders of an NFT on one chain to mint that NFT on an unrelated chain, or gating the mint to users who meet other specific offchain requirements.
-
-Signature mints are not particularly complex, but they remain challenging to implement. Because they make use of both hashing and cryptography, there are no partially-correct states - either everything is exactly right and the mint works, or **something** is wrong **somewhere** and it doesn't.
-
-Combined with the rapid changes in Solidity, library contracts, and frontend libraries, troubleshooting errors is particularly difficult.
-
-## Objectives
-
-By the end of this tutorial you should be able to:
-
-- Cryptographically sign a message with a wallet
-- Validate a signed message in a smart contract
-- Implement a signature ERC-721 mint
-
-## Prerequisites
-
-### ERC-721 Tokens
-
-This tutorial assumes that you are able to write, test, and deploy your own ERC-721 tokens using the Solidity programming language. If you need to learn that first, check out our content in [Base Learn] or the sections specific to [ERC-721 Tokens]!
-
-### Vercel
-
-You'll need to be comfortable deploying your app to [Vercel], or using another solution on your own. Check out our tutorial on [deploying with Vercel] if you need a refresher!
-
-## Building the Contract
-
-Start by setting up an [OpenZeppelin ERC-721] contract. Set up variables and use the constructor to assign:
-
-- A name for the collection
-- Symbol for the collection
-- Description
-- IPFS Hash for the NFT art (assuming the same art for each NFT)
-- A counter to keep track of which NFT id is next
-
-```solidity
-// SPDX-License-Identifier: UNLICENSED
-pragma solidity 0.8.24;
-
-import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
-import "@openzeppelin/contracts/access/Ownable.sol";
-
-contract SoulboundSignatureMint is ERC721, Ownable {
- string public nameString;
- string public description;
- string public tokenArtIPFSId;
- uint public counter;
-
- constructor(
- string memory _nameString,
- string memory _symbol,
- string memory _tokenArtIPFSId,
- string memory _description
- ) ERC721(_nameString, _symbol) Ownable(msg.sender) {
- nameString = _nameString;
- description = _description;
- tokenArtIPFSId = _tokenArtIPFSId;
- }
-}
-```
-
-You're also using `Ownable` to assign an owner to this contract. You could instead just save an address for the authorized signer if you aren't going to add any functionality only the owner can invoke.
-
-### Public Mint Function
-
-For the `public`-facing mint function, create a function called `mintTo` that accepts an `address` for the `_recipient`.
-
-
-A common pattern used to be to simply mint the token and give it to `msg.sender`. This practice is falling out of favor. Allowing the recipient to be different than the sender gives greater flexibility. Doing so is also necessary to assign the right NFT owner in the event the user is using a smart contract wallet, paymaster, or other form of account abstraction.
-
-
-```solidity
-function mintTo(address _recipient, bytes memory _signature) public {
- counter++;
- _safeMint(msg.sender, counter);
-}
-```
-
-### Onchain Metadata
-
-Rather than pointing to a `json` file on the traditional internet, you can put your metadata directly in the contract. To do so, first import some helper libraries:
-
-```solidity
-import "@openzeppelin/contracts/utils/Base64.sol";
-import "@openzeppelin/contracts/utils/Strings.sol";
-```
-
-Next, `override` the functions for `_baseURI` and `tokenURI` to return base 64 encoded json metadata with the information you supplied in the constructor:
-
-```solidity
-function _baseURI() internal pure override returns (string memory) {
- return "data:application/json;base64,";
-}
-
-function tokenURI(uint _tokenId) public view override returns (string memory) {
- if(_tokenId > counter) {
- revert InvalidTokenId(_tokenId);
- }
-
- string memory json = Base64.encode(
- bytes(
- string(
- abi.encodePacked(
- '{"name": "',
- nameString,
- ' #: ',
- Strings.toString(_tokenId),
- '","description": "',
- description,
- '", "image": "ipfs://',
- tokenArtIPFSId,
- '"}'
- )
- )
- )
- );
-
- return string(abi.encodePacked(_baseURI(), json));
-}
-```
-
-**Be very careful** setting up the single and double quotes above and be sure to test this function to make sure the result is valid json metadata. An error here will break the NFT and it won't show up correctly in wallets or marketplaces!
-
-### Preventing Transfers
-
-_Soulbound_ is a video-game term that means that an item is permanently attached to the receiver - it can **not** be transferred. It's up to you if this restriction fits your design goals. We use it often because our NFTs are intended to be fun mementos or markers of personal accomplishment and not something that will ever have monetary value. Preventing trading reduces speculation and farming on something we did for fun!
-
-To prevent transfers other than the initial mint, you can `override` the `_update` function.
-
-
-Previously, this was done with the `_beforeTransfer` function. Current versions of OpenZeppelin's ERC-721 implementation have replaced that function with `_update`.
-
-
-```solidity
-/**
- * Disallow transfers (Soulbound NFT)
- */
-/**
- * @dev Internal function to handle token transfers.
- * Restricts the transfer of Soulbound tokens.
- */
-function _update(address to, uint256 tokenId, address auth)
- internal
- override(ERC721)
- returns (address)
-{
- address from = _ownerOf(tokenId);
- if (from != address(0) && to != address(0)) {
- revert SoulboundToken();
- }
-
- return super._update(to, tokenId, auth);
-}
-```
-
-### Deploy and Test
-
-Before getting into the complexity of validating a cryptographic signature, it's a good idea to validate your contract and make sure it is working as expected. You'll need to pin an image to IPFS and get a hash for it to use in your metadata. You can use a service like [Pinata] to help with that.
-
-### Adding Signature Validation
-
-To validate the signature that you'll later create in your backend, you'll use a pair of cryptography utilities from OpenZeppelin:
-
-```solidity
-import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
-import "@openzeppelin/contracts/utils/cryptography/MessageHashUtils.sol";
-```
-
-```solidity
-using ECDSA for bytes32;
-using MessageHashUtils for bytes32;
-```
-
-These utilities abstract away most of the complexity involved in working with messages adhering to the [ERC-191] and [EIP-712] specifications. Importantly, they work with the message format that prefixes `"\x19Ethereum Signed Message:\n32"` to the message. You **must** also do this when creating the signed message!
-
-Add a function to `validateSignature`:
-
-```solidity
-function validateSignature(address _recipient, bytes memory _signature) public view returns (bool) {
- bytes32 messageHash = keccak256(abi.encodePacked(_recipient));
- bytes32 ethSignedMessageHash = messageHash.toEthSignedMessageHash();
- address signer = ethSignedMessageHash.recover(_signature);
-
- return signer == owner();
-}
-```
-
-The way the verification works is a little obtuse, particularly given that you haven't created the `_signature` yet. The function has two inputs:
-
-- The message or variables in the signed message
- - Here, this is the `address` of the `_recipient`
- - The `_signature`, or signed message provided by the user claiming they have been given permission to mint the NFT
-
-First, the function recreates the hash of the data to be signed. If you were including other variables, you'd include them here as well. Next, `messageHash.toEthSignedMessageHash` prepends the bytes representation of `"\x19Ethereum Signed Message:\n32"` to the message, then hashes the result.
-
-Finally, calling `recover` with `ethSignedMessageHash` and the `_signature` attempts to recover the signing `address` from the `_signature` using the **independently constructed** message data.
-
-If the recovered address matches the expected address, in this case, the contract owner, then the provided `_signature` is valid. If the addresses do not match, then the `_signature` is not valid.
-
-Update your `mintTo` function to make use of the validation:
-
-```solidity
-function mintTo(address _recipient, bytes memory _signature) public {
- if(!validateSignature(_recipient, _signature)) {
- revert InvalidSignature();
- }
-
- counter++;
- _safeMint(msg.sender, counter);
-}
-```
-
-
-Nothing in the above validation method prevents a user, or a third party, from obtaining a valid, signed message from a previous transaction and reusing it for a **new** transaction. In this case, it doesn't matter because signature re-use would only allow minting more soulbound NFTs for the address within the signature.
-
-Other design requirements should use a nonce as a part of the signed data to prevent signature reuse.
-
-
-## Signing the Message
-
-If you're using [Hardhat] with [viem], you can write tests to verify the signing and validation mechanisms are working. Otherwise, there isn't a point, as success is dependent on the exact and specific way and order signing happens. If you're using a different toolkit to write your smart contracts, continue in your backend directly.
-
-If you're using a different library, you'll need to do research to figure out how to **exactly** reproduce the steps below.
-
-### Setting Up the Test
-
-Add a new test file and fill out a skeleton to deploy your contract and run a test:
-
-```tsx
-import { loadFixture } from '@nomicfoundation/hardhat-toolbox-viem/network-helpers';
-import { expect } from 'chai';
-import hre from 'hardhat';
-
-describe('Test', function () {
- // We define a fixture to reuse the same setup in every test.
- // We use loadFixture to run this setup once, snapshot that state,
- // and reset Hardhat Network to that snapshot in every test.
- async function deploySignatureFixture() {
- // Contracts are deployed using the first signer/account by default
- const [owner, signer0, signer1] = await hre.viem.getWalletClients();
-
- const soulboundSignatureMint = await hre.viem.deployContract('SoulboundSignatureMint', [
- 'Cool NFT Name', // Name
- 'CNFT', // Symbol
- 'QmRsQCyTEALYnHvBupFcs2ofzeeswEEEGN...', // IPFS Hash
- 'This is a cool NFT!', // Description
- ]);
-
- const publicClient = await hre.viem.getPublicClient();
-
- return {
- soulboundSignatureMint,
- owner,
- signer1,
- publicClient,
- };
- }
-
- describe('Mint', function () {
- it('Should validate the signed message', async function () {
- const { soulboundSignatureMint, owner, signer0, signer1 } = await loadFixture(
- deploySignatureFixture,
- );
-
- const ownerAddress = await owner.account.address;
- const signer1Address = await signer1.account.address;
-
- // TODO...
-
- // Signer 1 calls the mintTo function with the signature
- expect(await soulboundSignatureMint.write.mintTo([signer1Address, signature])).to.be.ok;
- });
- });
-});
-```
-
-You can use the example in the documentation for [signMessage] in the [viem] wallet client to get started, but it will **not** work as expected.
-
-```tsx
-// BAD CODE EXAMPLE DO NOT USE!
-const signature = await owner.signMessage({
- message: signer1Address,
-});
-```
-
-Try it, and it will fail. Add a log to your contract and you'll see that the recovered `signer` address is random, rather than the first address in the list of default Hardhat accounts.
-
-The reason for this is that while `signMessage` does follow the previously mentioned standards, prepends `"\x19Ethereum Signed Message:\n32"` to the message, and correctly signs it, it does **not** prepare the data to be signed in exactly the same way as the smart contract converts the `address` to `bytes32`.
-
-To fix this, first import some helper functions from [viem]:
-
-```tsx
-import { keccak256, encodePacked, toBytes } from 'viem';
-```
-
-Then `encodePacked` and `keccak256` hash your variables and turn them into `bytes`, just like you did in the contract in `validateSignature`:
-
-```tsx
-const message = keccak256(encodePacked(['address'], [signer1Address]));
-const messageBytes = toBytes(message);
-```
-
-Finally, call the wallet `signMessage` function with the newly assembled `messageBytes`. You'll need to mark the data representation as `raw`:
-
-```tsx
-const signature = await owner.signMessage({
- message: { raw: messageBytes },
-});
-```
-
-Test again, and it will pass!
-
-## Signing from the Backend
-
-It's up to you to determine the conditions that you're willing to sign a message. Once those conditions are met, you can use a similar process to load a wallet from your private key and sign the message on any TypeScript backend:
-
-```tsx
-const authorizedAccount = privateKeyToAccount(COINBASE_WALLET_KEY as `0x${string}`);
-
-const authorizedClient = createWalletClient({
- account: authorizedAccount,
- chain: base,
- transport: http(), // Leave empty for local account
-});
-
-// Align signed message with OpenZeppelin/Solidity
-
-const messageToSign = keccak256(encodePacked(['address'], [userAddress as `0x${string}`]));
-const messageBytes = getBytes(messageToSign);
-
-// Create an Ethereum Signed Message with the user's address
-const signedMessage = await authorizedClient.signMessage({
- message: { raw: messageBytes },
-});
-console.log('User address:', userAddress);
-console.log('Signed message:', signedMessage);
-
-const data = encodeFunctionData({
- abi: mintContractData.abi,
- functionName: 'mintTo',
- args: [userAddress, signedMessage],
-});
-```
-
-
-`privateKeyToAccount` expects that your key starts with `0x`. You may need to manually add that depending on the tool you exported it from.
-
-
-## Conclusion
-
-In this tutorial, you've learned how to create a signature mint, which allows you to set conditions on a backend before a user is allowed to mint your NFT. You've learned the detailed and specific steps needed to align [viem]'s method of signing messages with [OpenZeppelin]'s method of verifying them. Finally, you've learned a few of the risks and considerations needed in designing this type of mint.
-
-[Base Learn]: https://base.org/learn
-[ERC-721 Tokens]: https://docs.base.org/base-learn/docs/erc-721-token/erc-721-standard-video
-[Vercel]: https://vercel.com
-[deploying with Vercel]: /tutorials/farcaster-frames-deploy-to-vercel
-[OpenZeppelin ERC-721]: https://docs.openzeppelin.com/contracts/2.x/api/token/erc721
-[Pinata]: https://www.pinata.cloud/
-[ERC-191]: https://eips.ethereum.org/EIPS/eip-191
-[EIP-712]: https://eips.ethereum.org/EIPS/eip-712
-[Hardhat]: https://hardhat.org/
-[viem]: https://viem.sh/
-[signMessage]: https://viem.sh/docs/actions/wallet/signMessage.html
-[OpenZeppelin]: https://www.openzeppelin.com/
-
diff --git a/docs/learn/token-development/nft-guides/simple-onchain-nfts.mdx b/docs/learn/token-development/nft-guides/simple-onchain-nfts.mdx
deleted file mode 100644
index 0b91ad887..000000000
--- a/docs/learn/token-development/nft-guides/simple-onchain-nfts.mdx
+++ /dev/null
@@ -1,1044 +0,0 @@
----
-title: 'Simple Onchain NFTs'
-slug: /simple-onchain-nfts
-description: A tutorial that teaches how to make simple nfts that are procedurally generated and have onchain metadata and images.
-author: briandoyle81
----
-
-# Simple Onchain NFTs
-
-Many NFTs are dependent on offchain metadata and images. Some use immutable storage locations, such as [IPFS]. Others use traditional web locations, and many of these allow the owner of the contract to modify the URL returned by a contract when a site or user attempts to retrieve the location of the token art and metadata. This power isn't inherently bad, because we probably want someone to be able to fix the contract if the storage location goes down. However, it does introduce a requirement to trust the contract owner.
-
-In this tutorial, we'll show you how to do this to create a simple NFT that is fully onchain. This contract is used in our tutorials for [Thirdweb and Unreal - NFT Items] and the [Coinbase Smart Wallet].
-
-The result of this tutorial is used in other tutorials. [Below], you can find the complete contract and ABI. Feel free to use it if you're working on one of those and don't want to get sidetracked.
-
-## Objectives
-
-By the end of this tutorial you should be able to:
-
-- Programmatically generate and return json metadata for ERC-721 tokens
-- Deterministically construct unique SVG art in a smart contract
-- Generate deterministic, pseudorandom numbers
-
-## Prerequisites
-
-### ERC-721 Tokens
-
-This tutorial assumes that you are able to write, test, and deploy your own ERC-721 tokens using the Solidity programming language. If you need to learn that first, check out our content in [Base Camp] or the sections specific to [ERC-721 Tokens]!
-
-### Vector Art
-
-You'll need some familiarity with the SVG art format and a basic level of ability to edit and manipulate vector art. If you don't have this, find an artist friend and collaborate!
-
-## Building the Contract
-
-Start by setting up an [OpenZeppelin ERC-721] contract. You'll need to set up a `mintTo` function that accepts the address that should receive the NFT.
-
-```solidity filename="RandomColorNFT.sol"
-// SPDX-License-Identifier: UNLICENSED
-pragma solidity ^0.8.24;
-
-import "hardhat/console.sol";
-import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
-
-contract RandomColorNFT is ERC721 {
- uint public counter;
-
- constructor() ERC721("RandomColorNFT", "RCNFT") {
- }
-
- function mintTo(address _to) public {
- counter++;
- _safeMint(_to, counter);
- }
-}
-```
-
-
-With the Smart Wallet, `msg.sender` is the users custodial address - where you want to send the NFT. This is not always the case with account abstraction. In some other implementations, `msg.sender` is the smart contract address, even if the user signs in with an EOA. Regardless, it's becoming a common practice to pass the address you want the NFT to go to explicitly.
-
-
-### Onchain Metadata
-
-Rather than pointing to a `json` file on the traditional internet, you can put your metadata directly in the contract. To do so, first import some helper libraries:
-
-```solidity
-import "@openzeppelin/contracts/utils/Base64.sol";
-import "@openzeppelin/contracts/utils/Strings.sol";
-```
-
-Next, `override` the functions for `_baseURI` and `tokenURI` to return base 64 encoded json metadata with the appropriate information:
-
-```solidity
-function _baseURI() internal pure override returns (string memory) {
- return "data:application/json;base64,";
-}
-
-function tokenURI(uint _tokenId) public view override returns (string memory) {
- if(_tokenId > counter) {
- revert InvalidTokenId(_tokenId);
- }
-
- string memory json = Base64.encode(
- bytes(
- string(
- abi.encodePacked(
- '{"name": "',
- name(),
- ' #: ',
- Strings.toString(_tokenId),
- '","description": "Random colors are pretty or boring!", "image": "data:image/svg+xml;base64,',
- // TODO...,
- '"}'
- )
- )
- )
- );
-
- return string(abi.encodePacked(_baseURI(), json));
-}
-```
-
-**Be very careful** setting up the single and double quotes above and be sure to test this function to make sure the result is valid json metadata. An error here will break the NFT and it won't show up correctly in wallets or marketplaces!
-
-### Onchain SVG Image
-
-For this NFT, the art will consist of a simple onchain SVG containing a square with a pseudo-randomly chosen color. Check out our tutorial on [Building Onchain NFTs] if you want to try something more complicated.
-
-Start by scaffolding out a `render` function:
-
-```solidity
-function render(uint _tokenId) public view returns (string memory) {
- return string(
- abi.encodePacked(
- ""
- )
- );
-}
-```
-
-Rectangles in SVG images are created with the [rect] element. To cover the whole background, you can set the width and height to the size of the `viewbox`. Although not listed directly in the MDN page for rectangles, you can add a `fill` property to add a fill color to any SVG element. You can use color names, or hex codes for colors:
-
-```html
-
-Remember, randomness generated using onchain information is not fully secure. A determined attacker could manipulate a block to compromise your contract. That being said, `prevrandao` is a passable solution for anything not involving a large amount of money.
-
-
-### Saving the Color to the NFT
-
-You'll need to generate this color with the function, then save it in a way that it can be retrieved when the `tokenURI` function is called. Add a mapping to store this relationship:
-
-```solidity
-mapping (uint => string) public tokenIdToColor;
-```
-
-Then set the color when the token is minted:
-
-```solidity
-function mintTo(address _to) public {
- counter++;
- _safeMint(_to, counter);
- tokenIdToColor[counter] = generateRandomColor();
-}
-```
-
-### Finishing the `tokenURI` Function
-
-Update your `render` function to generate the SVG.
-
-```solidity
-function render(uint _tokenId) public view returns (string memory) {
- return string(
- abi.encodePacked(
- ""
- )
- );
-}
-```
-
-Then update your `tokenURI` function to use it, and return the SVG as base64 encoded data:
-
-```solidity
-function tokenURI(uint _tokenId) public view override returns (string memory) {
- if(_tokenId > counter) {
- revert InvalidTokenId(_tokenId);
- }
-
- string memory json = Base64.encode(
- bytes(
- string(
- abi.encodePacked(
- '{"name": "',
- name(),
- ' #: ',
- Strings.toString(_tokenId),
- '","description": "Random colors are pretty or boring!", "image": "data:image/svg+xml;base64,',
- Base64.encode(bytes(render(_tokenId))),
- '"}'
- )
- )
- )
- );
-
- return string(abi.encodePacked(_baseURI(), json));
-}
-```
-
-### List of NFTs Owned
-
-Most ERC-721 implementations don't contain an on-contract method to retrieve a list of **all** the NFTs owned by a single address. The reason for this is that it costs extra gas go manage this list, and the information can be retrieved by using read-only services that analyze blockchain data.
-
-However, gas prices are getting lower, and adding this data to your contract will reduce your dependency on third-party APIs.
-
-To track ownership in-contract, first import `EnumerableSet` from OpenZeppelin:
-
-```solidity
-import "@openzeppelin/contracts/utils/structs/EnumerableSet.sol";
-```
-
-Then enable it for `uint` sets and add a mapping to relate `addresses` to token ids.
-
-```solidity
-// Inside the RandomColorNFT contract
-using EnumerableSet for EnumerableSet.UintSet;
-
-mapping (address => EnumerableSet.UintSet) tokensOwned;
-```
-
-Finally, utilize the `_update` function to handle changes of ownership, including minting:
-
-```solidity
-function _update(address to, uint256 tokenId, address auth) internal override(ERC721) returns(address) {
- // Only remove the token if it is not being minted
- if (tokenId != counter){
- tokensOwned[auth].remove(tokenId);
- }
- tokensOwned[to].add(tokenId);
-
- return super._update(to, tokenId, auth);
-}
-```
-
-Now that you have a list of NFTs owned by an address, you can add a function to retrieve all of them. While you're at it, add the json metadata for each token. Doing so lets you get the complete list of NFTs **and** their metadata for just one RPC call!
-
-```solidity
-function getNFftsOwned(address owner) public view returns (TokenAndMetatdata[] memory) {
- TokenAndMetatdata[] memory tokens = new TokenAndMetatdata[](tokensOwned[owner].length());
- for (uint i = 0; i < tokensOwned[owner].length(); i++) {
- uint tokenId = tokensOwned[owner].at(i);
- tokens[i] = TokenAndMetatdata(tokenId, tokenURI(tokenId));
- }
- return tokens;
-}
-```
-
-### Testing
-
-Write some local tests, then [deploy] and test your contract. It can be very tricky to get all the commas, brackets, and single, and double quotes all lined up properly. The surest way to make sure it is working is to check the collection on [Testnet Opensea] or similar.
-
-Remember, it can take a few minutes for them to register and add the collection. If the metadata or image don't show up correctly, use [Sepolia Basescan] to pull the `tokenURI` and an online or console base64 decoder to decode and check the json metadata and SVG image.
-
-
-
-
-
-## Conclusion
-
-In this lesson, you learned how to make a simple NFT that is entirely onchain. You generated an SVG with a random color, and set up the JSON metadata for your NFT -- entirely onchain! Next, check out our tutorial for [Complex Onchain NFTs]!
-
-## Random Color NFT Contract
-
-```solidity filename="RandomColorNFT.sol"
-// SPDX-License-Identifier: UNLICENSED
-pragma solidity ^0.8.24;
-
-import "hardhat/console.sol";
-import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
-import "@openzeppelin/contracts/utils/Base64.sol";
-import "@openzeppelin/contracts/utils/Strings.sol";
-import "@openzeppelin/contracts/utils/structs/EnumerableSet.sol";
-
-contract RandomColorNFT is ERC721 {
- using EnumerableSet for EnumerableSet.UintSet;
-
- mapping (address => EnumerableSet.UintSet) tokensOwned;
-
- uint public counter;
-
- mapping (uint => string) public tokenIdToColor;
-
- error InvalidTokenId(uint tokenId);
- error OnlyOwner(address);
-
- constructor() ERC721("RandomColorNFT", "RCNFT") {
- }
-
- function mintTo(address _to) public {
- counter++;
- _safeMint(_to, counter);
- tokenIdToColor[counter] = generateRandomColor();
- }
-
- struct TokenAndMetatdata {
- uint tokenId;
- string metadata;
- }
-
- function getNftsOwned(address owner) public view returns (TokenAndMetatdata[] memory) {
- TokenAndMetatdata[] memory tokens = new TokenAndMetatdata[](tokensOwned[owner].length());
- for (uint i = 0; i < tokensOwned[owner].length(); i++) {
- uint tokenId = tokensOwned[owner].at(i);
- tokens[i] = TokenAndMetatdata(tokenId, tokenURI(tokenId));
- }
- return tokens;
- }
-
- function shuffleColor(uint _tokenId) public {
- if(_tokenId > counter) {
- revert InvalidTokenId(_tokenId);
- }
- if(ownerOf(_tokenId) != msg.sender) {
- revert OnlyOwner(msg.sender);
- }
- tokenIdToColor[_tokenId] = generateRandomColor();
- }
-
- function _update(address to, uint256 tokenId, address auth) internal override(ERC721) returns(address) {
- // Only remove the token if it is not being minted
- if (tokenId != counter){
- tokensOwned[auth].remove(tokenId);
- }
- tokensOwned[to].add(tokenId);
-
- return super._update(to, tokenId, auth);
- }
-
- function _baseURI() internal pure override returns (string memory) {
- return "data:application/json;base64,";
- }
-
- function tokenURI(uint _tokenId) public view override returns (string memory) {
- if(_tokenId > counter) {
- revert InvalidTokenId(_tokenId);
- }
-
- string memory json = Base64.encode(
- bytes(
- string(
- abi.encodePacked(
- '{"name": "',
- name(),
- ' #: ',
- Strings.toString(_tokenId),
- '","description": "Random colors are pretty or boring!", "image": "data:image/svg+xml;base64,',
- Base64.encode(bytes(render(_tokenId))),
- '"}'
- )
- )
- )
- );
-
- return string(abi.encodePacked(_baseURI(), json));
- }
-
- function render(uint _tokenId) public view returns (string memory) {
- return string(
- abi.encodePacked(
- ""
- )
- );
- }
-
- // Function to generate a random color hex code
- function generateRandomColor() public view returns (string memory) {
- // Generate a pseudo-random number using block.prevrandao
- uint256 randomNum = uint256(keccak256(abi.encodePacked(block.prevrandao, block.timestamp, msg.sender)));
-
- // Extract RGB components from the random number
- bytes memory colorBytes = new bytes(3);
- colorBytes[0] = bytes1(uint8(randomNum >> 16));
- colorBytes[1] = bytes1(uint8(randomNum >> 8));
- colorBytes[2] = bytes1(uint8(randomNum));
-
- // Convert RGB components to hex string
- string memory colorHex = string(abi.encodePacked(
- "#",
- toHexDigit(uint8(colorBytes[0]) >> 4),
- toHexDigit(uint8(colorBytes[0]) & 0x0f),
- toHexDigit(uint8(colorBytes[1]) >> 4),
- toHexDigit(uint8(colorBytes[1]) & 0x0f),
- toHexDigit(uint8(colorBytes[2]) >> 4),
- toHexDigit(uint8(colorBytes[2]) & 0x0f)
- ));
-
- return colorHex;
- }
-
- // Helper function to convert a uint8 to a hex character
- function toHexDigit(uint8 d) internal pure returns (bytes1) {
- if (d < 10) {
- return bytes1(uint8(bytes1('0')) + d);
- } else {
- return bytes1(uint8(bytes1('a')) + d - 10);
- }
- }
-}
-```
-
-```json
-{
- "address": "0x59c35beE5eAdeEDDc2c34d419459243bD70AFD72",
- "abi": [
- {
- "inputs": [],
- "stateMutability": "nonpayable",
- "type": "constructor"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "sender",
- "type": "address"
- },
- {
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- },
- {
- "internalType": "address",
- "name": "owner",
- "type": "address"
- }
- ],
- "name": "ERC721IncorrectOwner",
- "type": "error"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "operator",
- "type": "address"
- },
- {
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- }
- ],
- "name": "ERC721InsufficientApproval",
- "type": "error"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "approver",
- "type": "address"
- }
- ],
- "name": "ERC721InvalidApprover",
- "type": "error"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "operator",
- "type": "address"
- }
- ],
- "name": "ERC721InvalidOperator",
- "type": "error"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "owner",
- "type": "address"
- }
- ],
- "name": "ERC721InvalidOwner",
- "type": "error"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "receiver",
- "type": "address"
- }
- ],
- "name": "ERC721InvalidReceiver",
- "type": "error"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "sender",
- "type": "address"
- }
- ],
- "name": "ERC721InvalidSender",
- "type": "error"
- },
- {
- "inputs": [
- {
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- }
- ],
- "name": "ERC721NonexistentToken",
- "type": "error"
- },
- {
- "inputs": [
- {
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- }
- ],
- "name": "InvalidTokenId",
- "type": "error"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "",
- "type": "address"
- }
- ],
- "name": "OnlyOwner",
- "type": "error"
- },
- {
- "anonymous": false,
- "inputs": [
- {
- "indexed": true,
- "internalType": "address",
- "name": "owner",
- "type": "address"
- },
- {
- "indexed": true,
- "internalType": "address",
- "name": "approved",
- "type": "address"
- },
- {
- "indexed": true,
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- }
- ],
- "name": "Approval",
- "type": "event"
- },
- {
- "anonymous": false,
- "inputs": [
- {
- "indexed": true,
- "internalType": "address",
- "name": "owner",
- "type": "address"
- },
- {
- "indexed": true,
- "internalType": "address",
- "name": "operator",
- "type": "address"
- },
- {
- "indexed": false,
- "internalType": "bool",
- "name": "approved",
- "type": "bool"
- }
- ],
- "name": "ApprovalForAll",
- "type": "event"
- },
- {
- "anonymous": false,
- "inputs": [
- {
- "indexed": true,
- "internalType": "address",
- "name": "from",
- "type": "address"
- },
- {
- "indexed": true,
- "internalType": "address",
- "name": "to",
- "type": "address"
- },
- {
- "indexed": true,
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- }
- ],
- "name": "Transfer",
- "type": "event"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "to",
- "type": "address"
- },
- {
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- }
- ],
- "name": "approve",
- "outputs": [],
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "owner",
- "type": "address"
- }
- ],
- "name": "balanceOf",
- "outputs": [
- {
- "internalType": "uint256",
- "name": "",
- "type": "uint256"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [],
- "name": "counter",
- "outputs": [
- {
- "internalType": "uint256",
- "name": "",
- "type": "uint256"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [],
- "name": "generateRandomColor",
- "outputs": [
- {
- "internalType": "string",
- "name": "",
- "type": "string"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- }
- ],
- "name": "getApproved",
- "outputs": [
- {
- "internalType": "address",
- "name": "",
- "type": "address"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "owner",
- "type": "address"
- }
- ],
- "name": "getNFftsOwned",
- "outputs": [
- {
- "components": [
- {
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- },
- {
- "internalType": "string",
- "name": "metadata",
- "type": "string"
- }
- ],
- "internalType": "struct RandomColorNFT.TokenAndMetatdata[]",
- "name": "",
- "type": "tuple[]"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "owner",
- "type": "address"
- },
- {
- "internalType": "address",
- "name": "operator",
- "type": "address"
- }
- ],
- "name": "isApprovedForAll",
- "outputs": [
- {
- "internalType": "bool",
- "name": "",
- "type": "bool"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "_to",
- "type": "address"
- }
- ],
- "name": "mintTo",
- "outputs": [],
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "inputs": [],
- "name": "name",
- "outputs": [
- {
- "internalType": "string",
- "name": "",
- "type": "string"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- }
- ],
- "name": "ownerOf",
- "outputs": [
- {
- "internalType": "address",
- "name": "",
- "type": "address"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "uint256",
- "name": "_tokenId",
- "type": "uint256"
- }
- ],
- "name": "render",
- "outputs": [
- {
- "internalType": "string",
- "name": "",
- "type": "string"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "from",
- "type": "address"
- },
- {
- "internalType": "address",
- "name": "to",
- "type": "address"
- },
- {
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- }
- ],
- "name": "safeTransferFrom",
- "outputs": [],
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "from",
- "type": "address"
- },
- {
- "internalType": "address",
- "name": "to",
- "type": "address"
- },
- {
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- },
- {
- "internalType": "bytes",
- "name": "data",
- "type": "bytes"
- }
- ],
- "name": "safeTransferFrom",
- "outputs": [],
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "operator",
- "type": "address"
- },
- {
- "internalType": "bool",
- "name": "approved",
- "type": "bool"
- }
- ],
- "name": "setApprovalForAll",
- "outputs": [],
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "uint256",
- "name": "_tokenId",
- "type": "uint256"
- }
- ],
- "name": "shuffleColor",
- "outputs": [],
- "stateMutability": "nonpayable",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "bytes4",
- "name": "interfaceId",
- "type": "bytes4"
- }
- ],
- "name": "supportsInterface",
- "outputs": [
- {
- "internalType": "bool",
- "name": "",
- "type": "bool"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [],
- "name": "symbol",
- "outputs": [
- {
- "internalType": "string",
- "name": "",
- "type": "string"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "uint256",
- "name": "",
- "type": "uint256"
- }
- ],
- "name": "tokenIdToColor",
- "outputs": [
- {
- "internalType": "string",
- "name": "",
- "type": "string"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "uint256",
- "name": "_tokenId",
- "type": "uint256"
- }
- ],
- "name": "tokenURI",
- "outputs": [
- {
- "internalType": "string",
- "name": "",
- "type": "string"
- }
- ],
- "stateMutability": "view",
- "type": "function"
- },
- {
- "inputs": [
- {
- "internalType": "address",
- "name": "from",
- "type": "address"
- },
- {
- "internalType": "address",
- "name": "to",
- "type": "address"
- },
- {
- "internalType": "uint256",
- "name": "tokenId",
- "type": "uint256"
- }
- ],
- "name": "transferFrom",
- "outputs": [],
- "stateMutability": "nonpayable",
- "type": "function"
- }
- ]
-}
-```
-
-[Base Camp]: https://base.org.camp
-[ERC-721 Tokens]: https://docs.base.org/base-camp/docs/erc-721-token/erc-721-standard-video
-[IPFS]: https://ipfs.tech/
-[Base64]: https://en.wikipedia.org/wiki/Base64
-[Hardhat and Hardhat Deploy]: https://docs.base.org/base-camp/docs/hardhat-deploy/hardhat-deploy-sbs
-[testnet version of Opensea]: https://testnets.opensea.io/
-[sample project]: https://github.com/base-org/land-sea-and-sky
-[Sample Art]: https://github.com/base-org/land-sea-and-sky/tree/master/Final_SVGs
-[Basescan]: https://sepolia.basescan.org/
-[Thirdweb and Unreal - NFT Items]: ./thirdweb-unreal-nft-items
-[Coinbase Smart Wallet]: ./coinbase-smart-wallet
-[Below]: #random-color-nft-contract
-[Complex Onchain NFTs]: ./complex-onchain-nfts
-
diff --git a/docs/learn/token-development/nft-guides/thirdweb-unreal-nft-items.mdx b/docs/learn/token-development/nft-guides/thirdweb-unreal-nft-items.mdx
deleted file mode 100644
index 5a2841112..000000000
--- a/docs/learn/token-development/nft-guides/thirdweb-unreal-nft-items.mdx
+++ /dev/null
@@ -1,662 +0,0 @@
----
-title: 'Thirdweb and Unreal - NFT Items'
-slug: /thirdweb-unreal-nft-items
-description: Learn how to use NFTs as in-game items using Thirdweb and Unreal.
-author: briandoyle81
----
-
-# Thirdweb and Unreal - NFT Items
-
-[thirdweb] provides a number of contracts and tools for building onchain. Their [Gaming SDK] enables seamless onboarding, cross-platform support, and provides many other features. It's compatible with [Unreal Engine] and can be used to enable onchain elements in your games.
-
-In this tutorial, you'll learn how to add NFT item usage on top of the demo game you build in their [Unreal Engine Quickstart]. Specifically, you'll use an NFT collection of random colors to change the color of the player's race car.
-
-
-
-
-
-## Objectives
-
-By the end of this tutorial you should be able to:
-
-- Pull a user's NFTs into an Unreal Engine Game
-- Apply elements from the NFT to game entities
-- Award NFTs to players for game accomplishments or actions
-
-## Prerequisites
-
-### ERC-721 Tokens
-
-This tutorial assumes that you are able to write, test, and deploy your own ERC-721 tokens using the Solidity programming language. If you need to learn that first, check out our content in [Base Learn] or the sections specific to [ERC-721 Tokens]!
-
-### Unreal Engine
-
-This tutorial will cover everything you need to know to accomplish the learning objectives, but it won't teach you how to make a game. You'll need to take further steps to learn the [Unreal Engine] on your own. You'll also need to have Visual Studio or Visual Studio Code set up to edit and compile Unreal files.
-
-### Onchain Apps
-
-The tutorial assumes you're comfortable with the basics of deploying an app and connecting it to a smart contract. If you're still learning this part, check out our tutorials in [Base Learn] for [Building an Onchain App].
-
-## Reviewing the Contract
-
-In our tutorial for building a [Simple Onchain NFTs], you can find an example of an ERC-721 NFT contract. It's an extension of the [OpenZeppelin ERC-721] implementation. When a user mints, they're granted an NFT with a random color. The metadata is fully onchain, as is the svg image. The image is a simple 1024\*1024 `rect`, with a `fill` of the randomly generated color.
-
-If the user dislikes the color, they may shuffle it and the NFT will change to a new randomly-selected color.
-
-These NFTs are not restricted for trading. The contract includes a utility function, `getNftsOwned`, which will return an array containing the `tokenId` and base64-encoded metadata string for all tokens currently owned by the provided `address`.
-
-## Getting Started with Unreal
-
-Continue below for some tips on completing the [Unreal Engine Quickstart] tutorial provided by thirdweb. This tutorial will guide you through installing the Unreal Engine and setting up the major components of the thirdweb [Gaming SDK].
-
-It will also guide you through setting up the website and backend that are needed to support the game integration. The client in their example uses Next.js, and the server is built with Node and Express.
-
-### Setting up the Engine
-
-First, you need to set up the [Engine]. For testing, you can [run it locally] with a [Docker] container.
-
-If you need to, install or update [Docker] and [Postgres].
-
-Start Postgres:
-
-```shell
-docker run -p 5432:5432 -e POSTGRES_PASSWORD=postgres -d postgres
-```
-
-Make sure Docker desktop is running.
-
-Create a [thirdweb API key]. Allow `localhost:3000` and `localhost:8000` when creating your api key. When you deploy, you'll need to update the allowed domains.
-
-The command to launch the engine itself is complicated and has many parameters. You'll want to create a file and run it from that. Create `thirdweb-engine.sh` in a convenient location and add:
-
-```shell
-docker run \
- -e ENCRYPTION_PASSWORD="" \
- -e THIRDWEB_API_SECRET_KEY="" \
- -e ADMIN_WALLET_ADDRESS="" \
- -e POSTGRES_CONNECTION_URL="postgresql://postgres:postgres@host.docker.internal:5432/postgres?sslmode=disable" \
- -e ENABLE_HTTPS=true \
- -p 3005:3005 \
- --pull=always \
- --cpus="0.5" \
- thirdweb/engine:latest
-```
-
-Enter your `THIRDWEB_API_SECRET_KEY` and the wallet address you sign into thirdweb with as the `ADMIN_WALLET_ADDRESS`. You can see a full list of [environment variables] in the docs, but shouldn't need to set any others now.
-
-Give your script permission to run with `chmod +x ./thirdweb-engine.sh` then run it with `./thirdweb-engine.sh
-`.
-
-It will take awhile to spin up, and you can ignore the warning about the `Chain Indexer Listener not started...`.
-
-Once the engine is running, navigate to `https://localhost:3005/json`. Click through the warning that the connection is not secure. Doing so allows your browser to connect to your engine instance.
-
-
-
-We do not have an official browser recommendation, but during our testing, Chrome worked and Brave did not with the engine setup and configuration.
-
-
-
-Navigate to the [thirdweb engine dashboard], and click the `Import` button. Enter a name and the local address for your engine instance:
-
-
-
-
-
-Next, you must add your wallet to the engine instance. Open up the instance in the dashboard, then click the `Import` button next to `Backend Wallets`. Enter your secret key for the wallet.
-
-
-
-Remember, the wallet key gives full access to all assets within any wallet. Use separate wallets for development and individual production tasks. Don't hold or fund a production wallet with any assets other than the minimum amount necessary for the task it is accomplishing.
-
-
-
-**Be sure to fund** this wallet with Base Sepolia ETH. It will be paying the gas for transactions.
-
-
-
-The key to your wallet is stored in ephemeral memory in the engine itself. You'll need to re-add it whenever you restart the engine.
-
-
-
-## Setting up the Client and Server
-
-Clone the [engine-express] repo. CD into the `client` and `server` repos and run `yarn` to install dependencies, then CD back to root and run `yarn` again.
-
-In both the `client` and `server` folders, copy or rename the `.env.example` files as `.env`.
-
-### Client
-
-In the client `.env`:
-
-- Set `NEXT_PUBLIC_THIRDWEB_CLIENT_ID` to the **Client ID** matching your [thirdweb API key]
-- You don't need to change the `NEXT_PUBLIC_BACKEND_URL`
-- Set the `NEXT_PUBLIC_THIRDWEB_AUTH_DOMAIN` as `localhost`
-
-In the server `.env`:
-
-- Don't change the `THIRDWEB_ENGINE_URL`. (It **is** supposed to be `https`)
-- Set the `THIRDWEB_ENGINE_BACKEND_WALLET` to the same as you used in the engine setup
-- Set the `THIRDWEB_AUTH_DOMAIN` as `localhost`
-- Set the `THIRDWEB_API_SECRET_KEY` to the **Secret Key** matching your [thirdweb API key]
-- Set the `THIRDWEB_AUTH_PRIVATE_KEY` to the private key matching your backend engine wallet
-
-Open `client/components/ThirdwebProvider.tsx`. Update the `activeChain` to Base Sepolia.
-
-```tsx
-import { BaseSepoliaTestnet } from '@thirdweb-dev/chains';
-
-// This is the chainId your dApp will work on.
-const activeChain = BaseSepoliaTestnet;
-```
-
-### Server
-
-Open `server/src/controllers/engineController.ts`. Update the `const`s at the beginning to load from environment variables:
-
-```tsx
-const ENGINE_URL = process.env.THIRDWEB_ENGINE_URL;
-const BACKEND_WALLET = process.env.THIRDWEB_ENGINE_BACKEND_WALLET;
-const ERC20_CONTRACT = process.env.ERC20_CONTRACT;
-const CHAIN = process.env.CHAIN;
-```
-
-You'll need to deploy your own version of the [Token Drop] contract. Click `Deploy Now`, then enter the name, symbol, and image of your choosing.
-
-**Select `Base Sepolia Testnet` as the Network / Chain**.
-
-You can leave the `Recipient Address` as your connected address, and you don't need to do an advanced configuration.
-
-Click `Deploy Now`, and approve the transactions to deploy the contract and add it to your dashboard.
-
-Next, click the `Claim Conditions` tab on the left side nav. Then click the `+ Add Phase` button and select `Public`. Review the options, but don't change any of them for this demo. Click `Save Phases`.
-
-
-
-If later in the tutorial, you get an error when you attempt to claim a token, but not an error every four seconds failing to read the balance, it's because you missed this step.
-
-
-
-Copy the address from the dashboard:
-
-
-
-
-
-Return to the `.env` for your server, and add:
-
-```env
-ERC20_CONTRACT=0x... # Your Address
-CHAIN=84532 # Base Sepolia
-```
-
-Run the client and server with `yarn client` and `yarn server`. Navigate to `localhost:3000`, create a user, and link a wallet.
-
-## Setting Up the Game
-
-Clone the thirdweb [Unreal Demo], and open it with the Unreal Editor. Do so by clicking the `Recent Projects` tab in the upper left, then `Browse`, in the lower right.
-
-
-
-
-
-Open the folder cloned from the repo and select `unreal_demo.uproject`. You may need to convert the project to the current version of Unreal. Click the `Open a copy` button.
-
-When the scene loads, double-click `Scene_Game` in the upper-right corner.
-
-
-
-
-
-Before you can play, you need to do some config. Scroll down in the `Outliner` until you find `ThirdWebManager`. Click the `Open Thirdweb Manager` button to open the file in your editor.
-
-
-
-
-
-Then, click the green play button at the top of the viewport.
-
-
-
-
-
-Log in using the credentials you created on the website, and play the game for a minute or two. If you get a 404, check that your engine, client, and server are all still running.
-
-
-
-The demo does not actually have a database connected for users. You'll need to recreate your user each time you restart the server. For production, you'll need to swap this out with an actual database.
-
-
-
-If you get an error 500 `"No configured wallet found with address 0xABCD...."`, it's because you didn't add your wallet in the [thirdweb engine dashboard].
-
-Otherwise, the game should run, and you should receive an ERC20 NFT every time you collect one of the orange orbs on the race track.
-
-## Adding the Color Changer
-
-Your next goal is to make it so that your players can use their Random Color NFTs as skins on the race car. You'll need to deploy the [contract provided below], set it up to be accessed via the server and engine, and finally, enable the colors from the NFTs to be used to change the color of the car.
-
-### Deploying the Contract
-
-You'll use thirdweb's platform to deploy this contract as well. Open a new folder in your editor and run:
-
-```shell
-npx thirdweb create contract
-```
-
-Then:
-
-- Name the project - `random-color-nft`, or `.` if you run the script from the folder where you want the project
-- Select your preference of `Forge` or `Hardhat`
-- Name the NFT contract - `RandomColorNFT`
-- Select `Empty Contract`
-
-Open `contracts/Contract.sol` and replace the contents with the [contract provided below].
-
-You'll need to import or install the OpenZeppelin contracts. You may also need to update the config for the development environment you're using to `0.8.24`.
-
-Run `yarn build`.
-
-Select `y` to install the thirdweb package and wait for the script to complete.
-
-Run `yarn deploy`.
-
-If you haven't linked your device to your thirdweb account, the browser will open to a page asking you to make the connection. Do so now.
-
-After the script runs for a moment, it will open the thirdweb dashboard with the deployment UI open. Select `Base Sepolia Testnet` as your network, then click the `Deploy Now` button. Sign the transaction and wait for the contract to deploy.
-
-### Adding the Contract to the Server
-
-Copy the address for the contract to the clipboard and return to `thirdweb-engine-express`. Open `server/.env` and add:
-
-```env
-RANDOM_COLOR_NFT_CONTRACT=
-```
-
-Open `server/src/controllers/engineController.ts` and add it there as well:
-
-```tsx
-const RANDOM_COLOR_NFT_CONTRACT = process.env.RANDOM_COLOR_NFT_CONTRACT;
-```
-
-Now, using `claimERC20` as a template, add a function to `claimRandomColorNFT`. It's identical, except the `url`, `body`, and error message are:
-
-```tsx
-// Other code...
-const url = `${ENGINE_URL}/contract/${CHAIN}/${RANDOM_COLOR_NFT_CONTRACT}/write`;
-// Other code
-const body = {
- functionName: 'mintTo',
- args: [user.ethAddress],
-};
-// Other code
-res.status(400).json({ message: 'Error claiming RandomColorNFT' });
-```
-
-
-
-A better practice for production would be to make a more generalized function that can handle multiple requests to your contracts. We're skipping that for now to avoid needing to refactor the existing collectibles in the game.
-
-
-
-Next, you need to add a route for this function. Open `server/src/routes/engineRoutes.ts`. Import `claimRandomColorNFT` and add a route for it:
-
-```tsx
-router.post('/claim-random-color-nft', claimRandomColorNFT);
-```
-
-### Collecting the NFT from the Game
-
-Return to the Unreal Editor and open `ThirdwebManager.cpp`:
-
-
-.
-
-
-Similarly to what you did in the server, use the existing `PerformClaim()` as a template to add a function for `PerformNFTClaim()`. The only thing different is the name of the function and the URL:
-
-```c++
-HttpRequest->SetURL(this->ServerUrl + "/engine/claim-random-color-nft");
-```
-
-
-
-Again, it would be better practice to generalize this function, but you can skip that for now to avoid needing to update all the collectibles.
-
-
-
-Next, you need to let the editor know about this new function. Open `Source/unreal_demo/Public/ThirdwebManager.h`. Add your new function under the one for `PerformClaim();`
-
-```c++
-// Function to perform the NFT claim operation
-UFUNCTION(BlueprintCallable, Category = "Thirdweb")
-void PerformNFTClaim();
-```
-
-**Build your project**
-
-Once it's done compiling, return UnrealEditor. In the `Outliner`, open the folder for `Collectibles` and click `Edit Collectible`. In the new window, click `File->Save As...` and save a copy as `CollectibleNFT`.
-
-Open the `Content Drawer` at the bottom, search for `CollectibleNFT`, and drag one into the scene. Find it in the `Outliner` and click `Edit Collectible NFT`.
-
-Find the `Perform Claim` function call and replace it with `Perform NFT Claim`. **Note** that the `Target` is passed from `Get Actor of Class`.
-
-
-
-
-
-You'll want to be able to tell this collectible apart, so click on the mesh for `Collectible` on the left side in the `Component` tree, then on the `Details` panel on the right, find the `Materials` section and change it to `MI_Solid_Blue`.
-
-Click the icons at the top to `Compile` and save your asset.
-
-From the content drawer, drag your asset into the viewport.
-
-You should now see a blue orb floating where you placed it.
-
-Make sure the orb is low enough to drive through, then run the game. Collect the orb, then verify on a block explorer that you received the NFT.
-
-### Tinting the Car
-
-In the content browser, open `All>Content>Vehicles>SportsCar>Materials`. Right-click in an empty spot and select `Material>Material Parameter Collection`. Name yours `NFT_MPS`. Open the collection, click the `+` to add an item to `Vector Parameters` and create the color of your choosing. Bright red is a good option to make your change very visible.
-
-Right-click in an empty spot again and select `Create Basic Asset>Material`. Name your new material `M_NFT_Color`. Open it by double-clicking.
-
-Right-click on the graph and add a `Collection Parameter` node. In the `Details` panel on the left, select your `NFT_MPS` collection and pick the first vector for `Parameter Name`
-
-Connect the output to the `Base Color` of `M_NFT_Color`, then save and close the editor.
-
-Again in the content browser, right-click on the `M_NFT_Color` asset and select `Create Material Instance`. Name the instance `MI_NFT_Color`.
-
-Navigate to the sports car mesh located in `VehicleTemplate>Blueprints>SportsCar` and double-click to open the `SportsCar_pawn`. Select the `Mesh` from the `Components` tree and you should see the car in the editor.
-
-On the right side, change the `Element 2` material to `MI_NFT_Color`. The car is now bright red. Radical! Take your newly red car for a spin.
-
-### Fetching the NFT Colors
-
-Return to `engine-express` and open `engineController.ts`. Add a function to `getNFTColors` that uses the `read` endpoint to call the `getNFTsOwned` function.
-
-```tsx
-export const getNFTColors = async (req: Request, res: Response) => {
- const { authToken } = req.body;
- if (!authToken || !userTokens[authToken]) {
- return res.status(400).json({ message: 'Invalid auth token' });
- }
- const user = userTokens[authToken];
- try {
- const url = `${ENGINE_URL}/contract/${CHAIN}/${RANDOM_COLOR_NFT_CONTRACT}/read?functionName=getNftsOwned&args=${user.ethAddress}`;
- const headers = {
- 'x-backend-wallet-address': BACKEND_WALLET,
- Authorization: `Bearer ${process.env.THIRDWEB_API_SECRET_KEY}`,
- };
-
- const response = await axiosInstance.get(url, { headers: headers });
-
- // TODO: Extract the color from the image
-
- // TODO: Replace response
- res.json(response.data);
- } catch (error) {
- console.error(error);
- res.status(400).json({ message: 'Error getting NFT data' });
- }
-};
-```
-
-You'll also need to add this function to `engineRoutes.ts`:
-
-```tsx
-router.post('/get-nft-colors', getNFTColors);
-```
-
-Return to `engineController.ts`.
-
-Because Unreal doesn't support SVGs, you'll need to extract the color from your NFT metadata, and pass that to use in the material you created. Start by adding a type for the response, and for the JSON metadata:
-
-```tsx
-type NFTData = {
- tokenId: bigint;
- metadata: string;
-};
-
-type JSONMetadata = {
- name: string;
- description: string;
- image: string;
-};
-```
-
-You'll also need helper functions to decode the base64 encoded metadata and SVG, then get the color from the SVG.
-
-```tsx
-function getJsonMetadata(nft: NFTData) {
- const base64String = nft.metadata.split(',')[1];
- const jsonString = atob(base64String);
- return JSON.parse(jsonString) as JSONMetadata;
-}
-
-function getColorFromBase64StringSVG(base64String: string) {
- const base64Data = base64String.split(',')[1];
- const svgString = atob(base64Data);
- const color = svgString.match(/fill=['"](#[0-9a-fA-F]{6})['"]/);
- return color ? color[1] : '#000000';
-}
-```
-
-Use these to extract an array of colors and return it:
-
-```tsx
-const nfts = response.data.result.map((item: any) => {
- return {
- tokenId: item[0],
- metadata: item[1],
- };
-});
-
-const metadata = nfts.map((nft: NFTData) => getJsonMetadata(nft));
-const colors = metadata.map((m: JSONMetadata) => getColorFromBase64StringSVG(m.image));
-
-res.json(colors);
-// Delete res.json(response.data);
-```
-
-
-
-To test with Postman or similar, comment out the check for a valid `authToken` and hardcode in an address that you know has NFTs.
-
-
-
-### Getting the Colors into the Game
-
-Return to the game in your code editor, and open `ThirdwebManager.cpp` and `ThirdwebManager.h`. As before, add a function to call and endpoint on your server. This time to retrieve the array of colors. You'll need to do a little more for this one to set an in-game variable for the colors.
-
-First, you'll need to add a new multicast delegate type to handle the response in `ThirdwebManager.h`:
-
-```c++
-// ThirdwebManager.h
-DECLARE_DYNAMIC_MULTICAST_DELEGATE_TwoParams(FOnNFTColorsResponse, bool, bWasSuccessful, const TArray &, ResponseArray);
-```
-
-And expose it to the editor:
-
-```c++
-// ThirdwebManager.h
-// This delegate is triggered in C++, and Blueprints can bind to it.
-UPROPERTY(BlueprintAssignable, Category = "Thirdweb", meta = (DisplayName = "OnNFTColorsResponse"))
-FOnNFTColorsResponse;;
-```
-
-Then, add the function to `ThirdwebManager.cpp`. It's similar, but instead hits the endpoint for the NFT color array and uses the response you just created. It also expects the response to be an array of strings instead of searching for a property called `result`:
-
-```c++
-// ThirdwebManager.cpp
-void AThirdwebManager::GetNFTColors()
-{
- TSharedRef HttpRequest = FHttpModule::Get().CreateRequest();
- HttpRequest->SetURL(this->ServerUrl + "/engine/get-nft-colors"); // The endpoint to get the NFT colors
- HttpRequest->SetVerb("POST");
- HttpRequest->SetHeader(TEXT("Content-Type"), TEXT("application/json"));
-
- TSharedPtr JsonObject = MakeShareable(new FJsonObject);
- JsonObject->SetStringField("authToken", AuthToken);
-
- FString OutputString;
- TSharedRef> Writer = TJsonWriterFactory<>::Create(&OutputString);
- FJsonSerializer::Serialize(JsonObject.ToSharedRef(), Writer);
-
- UE_LOG(LogTemp, Warning, TEXT("OutputString: %s"), *OutputString);
-
- HttpRequest->SetContentAsString(OutputString);
-
- HttpRequest->OnProcessRequestComplete().BindLambda([this](FHttpRequestPtr Request, FHttpResponsePtr Response, bool bWasSuccessful)
- {
- if (bWasSuccessful && Response.IsValid())
- {
- int32 StatusCode = Response->GetResponseCode();
- if (StatusCode == 200)
- {
- TArray> JsonArray;
- TSharedRef> Reader = TJsonReaderFactory<>::Create(Response->GetContentAsString());
- if (FJsonSerializer::Deserialize(Reader, JsonArray) && JsonArray.Num() > 0)
- {
- TArray ResponseArray;
- for (const TSharedPtr& Value : JsonArray)
- {
- FString StringValue;
- if (Value->TryGetString(StringValue))
- {
- ResponseArray.Add(StringValue);
- }
- }
- this->OnNFTColorsResponse.Broadcast(true, ResponseArray);
- UE_LOG(LogTemp, Warning, TEXT("Get NFT Color response: %s"), *Response->GetContentAsString());
- return;
- }
- this->OnNFTColorsResponse.Broadcast(false, TArray());
- }
- else
- {
- FString ErrorMsg = FString::Printf(TEXT("HTTP Error: %d, Response: %s"), StatusCode, *(Response->GetContentAsString()));
- TArray ErrorArray;
- ErrorArray.Add(ErrorMsg);
- this->OnNFTColorsResponse.Broadcast(false, ErrorArray);
- UE_LOG(LogTemp, Warning, TEXT("ErrorMsg: %s"), *ErrorMsg);
- }
- }
- else
- {
- TArray ErrorArray;
- ErrorArray.Add(TEXT("Failed to connect to the server."));
- this->OnNFTColorsResponse.Broadcast(false, ErrorArray);
- UE_LOG(LogTemp, Warning, TEXT("Failed to connect to the server."));
- } });
-
- HttpRequest->ProcessRequest();
-}
-```
-
-Finally, expose this function to the editor.
-
-```c++
-// ThirdwebManager.h
-// Function to perform the get NFT Colors operation
-UFUNCTION(BlueprintCallable, Category = "Thirdweb")
-void GetNFTColors();
-```
-
-Compile and reload the project in the editor.
-
-In the content browser, find and open `Content>_Thirdweb>Blueprints>Canvas_HUD`.
-
-Under the text field for `Tokens`, drag a new `Text` widget in. Set the name at the top to `Label_Colors` and check `Is Variable`. Change the `Content` to `Colors`. If you put it on the right side, move the `Anchor` to the upper right corner.
-
-In the upper right, click the `Graph` tab. Add a `Sequence` node to split the flow after `Get Actor Of Class`. Following the same pattern as the flow that gets the balance response, add one that gets the NFT colors.
-
-Create the `Bind Event to OnNFTColorsResponse` node first, then create the `Custom Event` node from dragging from `Event`.
-
-For now, simply grab the last color in the array and set it in the HUD. To get it, drag off the `Response Array` in `OnNFTColorResponseReceived` and add a `Last Index` node. Drag again from the `Response Array` and add a `Get (Ref)` node. Connect the output of `Last Index` to the `Input` of `Get`. From there, drag from the output of `Get` and add a `To Text (String)` node.
-
-Drag out of the exec (white) connector of `OnNFTColorResponseReceived` and add a `Branch` and connect `Was Successful` to the `Condition`. For the `True` state, drag and add a `SetText (Text)`. Right click and add a reference to `Label Colors` and drag it to the `Target` of `SetText`. Connect the `Return Value` of `To Text (String)` to `In Text`.
-
-Finally, drag off `Bind Event to OnNFTColorsResponse` and add a `Set Timer by Function Name` node. Connect the `Return Value` of `Get Actor Of Class` to `Object`. Set the `Function Name` to `GetNFTColors` and the `Time` to `2.0`.
-
-You should end up with something like this:
-
-
-
-
-
-Compile the blueprint then run the game. You should see that last color in the array in the HUD, and you should see the full list printed in the console every two seconds.
-
-
-
-If you have an error in your `GetNFTColors` function that prevents `.Broadcast` from being called, nothing in the NFT Colors branch of this blueprint will run, including printing to the console.
-
-
-
-### Changing the Color of the Car
-
-Now that you have the colors, you can use them to change the color of your car! For now, you can just set the car to the last color, but on your own you'll want to add a UI widget to allow the player to pick their color.
-
-
-
-If you really wanted to get fancy, you could modify the contract to emit an `event` containing the color of the newly-minted NFT, extract that from the receipt, and optimistically make it available to the player a few seconds earlier.
-
-
-
-Unreal doesn't use hex colors, so you'll need to convert your hex string to a linear color and save it in the `Material Parameter Collection` you created earlier.
-
-Converting the hex code with a blueprint is very complicated. Luckily, Unreal has a helpful community that has created many utilities, including a [conversion function].
-
-
-
-Copying and pasting code for a game engine isn't quite as dangerous as copying and pasting unknown smart contract code, but you're working at the intersection of these worlds. Be sure to review and make sure you understand anything you find online.
-
-
-
-In the content browser, add a `Blueprints>Blueprint Function Library` called `ColorUtils`. In it, add a function called `HexStringToColor`.
-
-Copy the code from the community site and paste it into the function. Connect the `Hex String to Color` node to the `SET` node attached to `Make Array`, then from `SET` to the `Return Node`.
-
-Compile, and you'll get an error. Find and right-click on the error in the `Hex Code` node, then select `Create local variable`. Recompile and the error will resolve.
-
-You also need to input the string you want converted. Select the `Hex String to Color` node and click the `+` button by `Inputs` located in the panel on the right. Name it `hexString` and give it a `string` type. `Hex String` will now appear as a value in the `Hex String to Color` node. Connect it to the `Source String` input in the `Replace` node.
-
-Compile one last time, then save and close `ColorUtils`.
-
-Return to `Canvas_HUD` and open the `Graph`. Drag out of the `SetText` node that adds the color to the HUD and add a `Hex String to Color` node. The function expects alpha values in the hex code. To add this connect a second output of the string array `GET` to an `Append` function and append `ff` in the `B` input. Connect the `Return Value` to the `Hex String` input in `Hex String to Color`.
-
-Finally, add a `Set Vector Parameter Value`. Select `NFT_MPS` for the collection and `Vector` for the `Parameter Name`. Connect the `Liner Color` output of `Hex String to Color` to the `Parameter Value` input.
-
-
-
-
-
-Compile, save, and close `Canvas_HUD`. Run the game. Your car will start red, but after the response from the server, it will turn the color of your last NFT! Drive and collect the NFT collectible, and it will change colors!
-
-## Conclusion
-
-In this tutorial, you've learned how to set up Thirdweb's engine and use it to connect an Unreal Engine game to Base. You've also learned how to use their platform to deploy and manager your contracts. Finally, you've learned how to build game elements to allow players to collect new NFTs and use them to personalize their game items.
-
-[Base Learn]: https://docs.base.org/learn/welcome
-[ERC-721 Tokens]: https://docs.base.org/learn/erc-721-token/erc-721-standard-video
-[OpenZeppelin ERC-721]: https://docs.openzeppelin.com/contracts/2.x/api/token/erc721
-[OpenZeppelin]: https://www.openzeppelin.com/
-[Unreal Engine]: https://www.unrealengine.com/en-US
-[thirdweb]: https://thirdweb.com/
-[Gaming SDK]: https://portal.thirdweb.com/solutions/gaming/overview
-[Unreal Engine Quickstart]: https://portal.thirdweb.com/solutions/gaming/unreal-engine/quickstart
-[contract provided below]: #random-color-nft-contract
-[Engine]: https://github.com/thirdweb-dev/engine
-[run it locally]: https://portal.thirdweb.com/engine/self-host
-[Docker]: https://www.docker.com/
-[Postgres]: https://www.postgresql.org/
-[thirdweb API key]: https://thirdweb.com/dashboard/settings/api-keys
-[environment variables]: https://portal.thirdweb.com/engine/self-host#environment-variables
-[engine-express]: https://github.com/thirdweb-example/engine-express
-[Token Drop]: https://thirdweb.com/thirdweb.eth/DropERC20
-[Unreal Demo]: https://github.com/thirdweb-example/unreal_demo
-[thirdweb engine dashboard]: https://thirdweb.com/dashboard/engine
-[wallet best practices]: https://portal.thirdweb.com/engine/features/backend-wallets#best-practices
-[conversion function]: https://blueprintue.com/blueprint/vm4ujcqe/
-[Simple Onchain NFTs]: /tutorials/simple-onchain-nfts
-
diff --git a/docs/learn/welcome.mdx b/docs/learn/welcome.mdx
deleted file mode 100644
index c29f9d601..000000000
--- a/docs/learn/welcome.mdx
+++ /dev/null
@@ -1,27 +0,0 @@
----
-sidebarTitle: Welcome
-title: Learn to Build Smart Contracts and Onchain Apps
-description: Base Learn is a comprehensive, free guide to learning smart contract and onchain app development.
----
-
-import LearningObjectives from '/snippets/learning-objectives.mdx';
-
-
-
-
-
-## Introduction
-
-Welcome to Base Learn, your guide to learning smart contract development. Base Learn's curriculum has been expertly crafted to equip you with the skills and knowledge needed to build and deploy smart contracts on Base, or any EVM-compatible chain, including Ethereum, Optimism, and many more. Plus, you'll be eligible to earn NFTs as you complete each module, showcasing your mastery of the material.
-
-Whether you're a curious novice or a seasoned pro looking to stay ahead of the game, our dynamic lessons cater to all levels of experience. You can start with the basics and work your way up, or dive straight into the more advanced concepts and push your limits to new heights.
-
-Begin your journey today!
-
-## What you can learn in this program
-
-Base Learn covers the following topics. If you're looking for quickstarts, or deeper guides on advanced topics, check out our [Base Builder Tutorials](/)!
-
-
-
-
-);
-```
-
-Try it out. Notice that the button text briefly changes without the wallet window popping up if you click the `Claim Tokens` button while connected with a wallet that already owns the tokens. The reason this happens is that viem, which underlies wagmi, runs a simulation of the transaction to estimate gas costs. If that simulation fails, it triggers the fail mechanism immediately, rather than allowing the app to send a bad transaction to the blockchain and cost the user gas for a call doomed to fail. You will fix this in the next tutorial.
-
-In the meantime, you'll need to change to a new wallet or redeploy your contract a couple of times to complete your testing. Do that, and try out the call on a wallet that hasn't claimed any tokens. Notice that the button is disabled and the text now prompts the user to look to their wallet to approve the transaction.
-
----
-
-## Conclusion
-
-In this step-by-step, you've learned how to use the [`useWriteContract`] hook to call your smart contract functions on demand. You've also tested methods to manage the UI/UX experience for your users, based on the state of the transaction, as well as its success or failure.
-
----
-
-[wagmi]: https://wagmi.sh/
-[`useWriteContract`]: https://wagmi.sh/react/hooks/useWriteContract
-[`usePrepareContractWrite`]: https://wagmi.sh/react/prepare-hooks/usePrepareContractWrite
-[Reading and Displaying Data]: ../reading-and-displaying-data/useAccount
-[`useReadContract`]: https://wagmi.sh/react/hooks/useReadContract
-[OpenZeppelin ERC20]: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/token/ERC20/ERC20.sol
-[`useAccount`]: https://wagmi.sh/react/hooks/useAccount
-
diff --git a/docs/learn/onchain-concepts/building-onchain-ai.mdx b/docs/learn/onchain-concepts/building-onchain-ai.mdx
deleted file mode 100644
index 2584493f0..000000000
--- a/docs/learn/onchain-concepts/building-onchain-ai.mdx
+++ /dev/null
@@ -1,14 +0,0 @@
----
-title: "AI Onchain"
-description: "Learn how AI agents can manage economic value onchain using AgentKit to deploy contracts, create tokens, and manage funds autonomously on Base."
----
-
-AI agents are quickly evolving, but most can't hold or manage economic value on their own. AgentKit bridges that gap by giving AI agents a wallet and "economic agency," letting them deploy contracts, create tokens, or manage funds autonomously on Base. In this final sub-section, you'll learn about practical use cases for combining AI with onchain functionality—and how AgentKit simplifies the process.
-
-{'Token Balance: ' + tokenBalance}
- -