We modified @AaveAave's AToken implementation to support Flexible Voting so you can earn yield on governance tokens and continue participating in governance.

For example, you can supply UNI to Aave to earn yield, and still vote on @Uniswap proposals.

https://twitter.com/ScopeLift/status/1621275019929059329

Right now most users must choose between earning yield or participating in governance.

With DAOs that integrate Flex Voting—an extension for @OpenZeppelin Governors—that no longer has to be the case.

https://www.scopelift.co/blog/how-scopelift-built-a-flex-voting-atoken-on-aave

Flex voting integration also unlocks a lot more use cases, such as:

- Affordable cross-chain voting
- Cheaper subsidized voting
- Custodial voting
- Shielding voting

You can learn more about these in the original flex voting announcement, linked below

https://twitter.com/ScopeLift/status/1547627175347507205

Foundry and solidity best practices were recently released, strongly recommended reading through them

Ethereum development changes quickly so I suspect these will evolve over time. Feedback is definitely welcome

A few highlights below, read them all at: https://book.getfoundry.sh/tutorials/best-practices

This seems to be getting more popular anyway, but always prefer named input syntax instead of importing full files. It helps avoid issues, especially as your project grows.

Potential hot take: Use fork tests liberally, always prefer them to mocks.

Mocks are required in web2 development, where you have no choice but to mock API responses. But in web3 development everything is on-chain, so just fork the chain instead of risking a buggy mock.

When organizing tests, I like treating each contract as a describe block. And be sure to give your tests and harnesses clear, consistent naming conventions.

Some more examples of good test names in @PaulRBerg's tweet.

https://twitter.com/PaulRBerg/status/1616068157088714765

Some tips in there from @samczsun's How Do You Even Write Secure Code Anyways talk

And finally, some tips and footguns to be aware of with `forge script`

This writeup of best practices was a collaboration between:
- @odysseas_eth from @nomadxyz_
- @lucasmanuel_eth from @maplefinance
- And a few of us at @ScopeLift

So thanks to all for their help reviewing.

As mentioned above, this will likely evolve and feedback is welcome!

Foundry and Solidity Best Practices

Introducing forge-std v1.0.0 🧵

Strongly recommend updating your forge-std versions ASAP, as there are changes that improve fuzzing so you might find some new failing tests.

Update with `forge update lib/forge-std`

This, along with `vm.assume` are used in fuzz tests to take an input value generated by the fuzzer and wrap it into some range.

But the old `bound` had a problem.

A big feature of the forge fuzzer it its dictionary: it takes PUSH bytes and keys/values from storage, adds them to a dictionary, then sometimes uses the values as fuzz inputs

But if the min value in your bound was non-zero, there was a bias which negated the dictionary benefits

The new bound fixes this. Now, that bias is removed, so you can safely use it without removing the dictionary benefits.

Additionally, bound now has edge biasing, so the min and max values in your bound range should be covered. Previously, this was extremely unlikely.

These changes to bound mean that after updating forge-std, you may have new test failures that you didn't have before, but that is good thing!

(Note that no changes are needed to use this, just update forge-std and the new bound will be used, then you may need to fix some tests)

With forge-std v1.0.0, the new fuzzing best practices are:

- Default to using `bound` to shape inputs: it increases the chance of testing the edges of your bound and is faster than `vm.assume`

- Use `vm.assume` to exclude specific values from fuzzing, such as an owner address

One feature of @vyperlang that I really like is the built-in interfaces. Popular interface definitions are included so you don't need to redefine them in each project.

The lack of shared interfaces causes two issues.

The first is that it's tedious to copy/paste interface files, or install a dependency to get the interfaces

The second is that everyone declares interfaces differently, and if you have two dependencies with different IERC20 files, you may end up with some solc complaints to fix

So forge-std now includes common interface files by default for ERC-20, ERC-165, ERC-721, ERC-1155, and ERC-4626.

`import {IERC20} from "forge-std/interfaces/IERC20.sol"` is all you need

If you need an interface not currently included, feel free to PR it in.

3. A new `stdChains` variable, included by default in your scripts and tests.


This lets you do a few things:

1. Access a chain's ID with `stdChains.Mainnet.chainId`
2. Access a chain's RPC URL with `stdChains.Optimisim.rpcUrl`
3. Access a chain's name with `stdChains.ArbitrumOne.name`

Note: The default RPC URLs are included for convenience to facilitate quick tests and experimentation. Do not use them for production test suites, CI, or other heavy usage as you will be throttled and this is a disservice to others who need this endpoint.

But the RPC URLs are automatically updated with any URLs found in the `[rpc_endpoints]` of your foundry.toml file.

You can see the full list of supported chains, and the expected aliases in the `foundry.toml` file, here: https://github.com/foundry-rs/forge-std/blob/17656a2fa5453f495d8c1302a0cedded912457eb/src/StdCheats.sol#L228-L275

Included in this change is a new `assumeNoPrecompiles` helper method, that makes it easy for you to have the fuzzer skip precompile inputs for any chain: https://github.com/foundry-rs/forge-std/blob/17656a2fa5453f495d8c1302a0cedded912457eb/src/StdCheats.sol#L286-L316

And if you want support for a new chain, feel free to PR that in!

Ensuring scripts are safe and footgun-free is important. But some cheatcodes might result in a script working as expected during tests, but not in production.

For example, if you `vm.warp` to change timestamp, and use the block timestamp to calculate an input value.

So now you can alternatively use `vmSafe` in your scripts, which is a subset of the full `vm` interface. It excludes all cheats that modify the VM state, such as warp, roll, deal, etc.

5. A few small other small features and breaking changes:
- A new `createCompute2Address` utility.
- The minimum supported pragma is now 0.6.2.
- forge-std is now more modular and better organized.

- Related to the `VmSafe` change to make scripts safer, `using stdStorage for StdStorage` will break in scripts and will need to be changed to `stdStorageSafe` (or manually import the full `stdStorage`)

And finally:
- Thanks to @PaulRBerg for helping modularize the codebase.
- Thanks to @mrnventuro for helping with `bound` improvements.
- HUGE thanks to @ZeroEkkusu00x for all the help implementing and testing these features!

Introducing forge-std v1.0.0

Keeping Up with the Foundry Devs

An ongoing thread of foundry changes so you can stay up to date

First, follow all the Foundry legends:

@onbjerg @mattsse_ @gakonst @r_krasiuk @joshie_sh @brockjelmore @ashekhirin @rakitadragan

Ok, now on to the updates.

This thread will start with some highlights from the last few weeks, then I'll add to it over time as new features are added and bugs are fixed.

Various `forge fmt` updates and fixes. Available config options are now:

line_length
tab_width
bracket_spacing
int_types
multiline_func_header
quote_style
number_underscore
single_line_statement_blocks

Formatting reference: https://book.getfoundry.sh/reference/config/formatter

If the docs aren't updated, you can see options in the code here: https://github.com/foundry-rs/foundry/blob/master/config/src/fmt.rs

Note that options from those enums must be written as `snake_case` in your config file, e.g. `attributes_first` not `AttributesFirst`

Fork tests are easier than ever, details in the quoted thread.

In addition to what's in that thread, you can also fork from any transaction hash, and it will replay all *prior* transactions in that block.

You can see the relevant cheats for this here: https://github.com/foundry-rs/forge-std/pull/180/files

https://twitter.com/msolomon44/status/1564742781129502722

File reading and writing is easy too. This thread includes cheatcodes for reading JSON files and converting between strings and native solidity types.

https://twitter.com/msolomon44/status/1565387268105199616

New deploy patterns for `forge script` 

https://twitter.com/msolomon44/status/1567204143689011200

Start anvil by forking from a node with archive data (@AlchemyPlatform and @infura_io offer this for free), and you can now use `debug_tranceTransaction` with anvil https://github.com/foundry-rs/foundry/pull/2868

This works with Hardhat too as mentioned in the quoted tweet

https://twitter.com/msolomon44/status/1461176450250276867

Missing dependencies are automatically installed on `forge build` and `forge test` https://github.com/foundry-rs/foundry/pull/3212

Improvement to broadcast artifacts (the JSON file outputs): For dry runs, i.e. no `--broadcast` flag, the artifact is now nested within a `dry-run` folder

Add `/broadcast/**/dry-run/` to your .gitignore to only commit broadcasted txs

Broadcast artifact fix: the `arguments` field showing constructor args is now populated instead of always being `null`.

You can suppress solc warnings using human-friendly aliases (instead of numeric error codes) with `ignored_error_codes` in the config file

See the full list of aliases here: https://github.com/foundry-rs/foundry/pull/3164/files 

Previously there was `vm.getCode` to get the creation bytecode for a give file. There's now also `vm.getDeployedCode` to get the deployed bytecode.

More info and examples in the book: https://book.getfoundry.sh/cheatcodes/get-deployed-code#getdeployedcode

`forge snapshot` improvements:

1. New tests do not cause snapshot to exit with an error: https://github.com/foundry-rs/foundry/pull/3251

2.  A new `forge snapshot --tolerance <pct>` flag can be used to allow tolerating snapshot deviations up to that percentage: https://github.com/foundry-rs/foundry/pull/3102

Previously the fuzz config had both `max_local_rejects` and `max_global_rejects` options.

 The former is gone (it was never used anyway) and the latter is renamed to `max_test_rejects` for clarity (but behavior is unchanged).

https://github.com/foundry-rs/foundry/pull/3138

Blockscout and sourcify are supported for contract verification with `--verifier <name>`, where name can be `etherscan`, `sourcify`, or `blockscout`

https://book.getfoundry.sh/reference/forge/forge-verify-contract

And now some forge-std updates:

Small utils called `makeAddr` and `makeAddrAndKey` make it quick to generate and label addresses for arbitrary users: https://github.com/foundry-rs/forge-std/blob/e68214f75c4c9411baede13606544f228994396c/src/Test.sol#L90-L100

Thanks @0xkarmacoma for implementing and @eth_call for the inspiration

.@kelvinfichter added a package.json so you can properly import forge-std as a git dependency in your node.js projects https://github.com/foundry-rs/forge-std/pull/176

I'm sure there's plenty I've missed but that's it for now, more to come later.

You can read the unrolled version of this thread here, which is nice for just searching the whole thread at once. https://typefully.com/msolomon44/GtoP4UV

(Not sure if it will update itself as tweets get added)  

Keeping Up with the Foundry Devs

1/ New `forge script` patterns unlocked thanks to @devan_non. No more passing private keys in the CLI:

1. `export PRIVATE_KEY=&lt;key&gt;` in `.env`
2. `uint256 privKey = vm.envUint("PRIVATE_KEY")`
3. `address deployer = vm.rememberKey(privKey)`
4. Deploy with `vm.broadcast(deployer)`

2/ You can also do this with mnemonics:

1. `export MNEMONIC=&lt;mnemonic&gt;` in `.env`
2. `uint256 privKey = vm.deriveKey(vm.envString("MNEMONIC"), index);`
3. `address deployer = vm.rememberKey(privKey)`
4. Deploy with `vm.broadcast(deployer)`

New Deploy Patterns for `forge script`

1/ Guide to file reading and writing in foundry.

2/ Read a whole file into a string with `vm.readFile`, or read the next line of a file with `vm.readLine`.

Right now the best options are reading (1) a JSON file, or (2) a file with one piece of data per line. CSVs aren't well supported yet.

3/ Now you have data as a string, but string manipulation is terrible in Solidity so there's cheatcodes for that too. The below cheats take a string and convert to the specified type:

parseBytes
parseAddress
parseUint256
parseInt256
parseBytes32
parseBool

4/ If you read JSON, `parseJson(stringifiedJson, key)`  returns the data as ABI-encoded bytes which you can decode with abi.decode

The `key` is a string and supports jq-syntax. If you don't know jq syntax, see https://earthly.dev/blog/jq-select/

Note the caveats if the key holds an object

5/ forge-std has a library to simplify this:

contract MyScript is Script {
  using stdJson for string;
   
  function parseInputs() internal {
    string memory json = vm.readFile("data.json");
    uint userBalance = json.readUint(".balance");
  }
}

6/ It also has various structs defined that match the transactions and receipts from `forge script` broadcast logs, and helper methods for easily reading the txs/receipts.

https://twitter.com/gakonst/status/1564461115567878144

7/ Ok now you have a bunch of data, you ran some scripts or tests with it, and want to save outputs. 

vm.writeFile(string)
vm.writeLine(string)
vm.toString(anyType)

Use `str.concat` to help format and you're done.

8/ If you want to write JSON you have to format it manually for now, but @odysseas_eth is working on some helpers to make that easier.  

Big shoutout to @odysseas_eth and @ashekhirin for implementing most of the stuff in this thread 🙌

9/ And in case you missed the previous alpha 

https://twitter.com/msolomon44/status/1564742781129502722

File Reading and Writing in Foundry

This feature seems to have went under the radar, so here's a guide to clean and simple fork tests with foundry.

No custom profiles, tailored file names/directory structure, or match flags needed 👇️

1/ In your foundry.toml, create an `[rpc_endpoints]` table. The key is your alias for the network, the value is the RPC URL for that network. Env vars are supported using the syntax shown:

[rpc_endpoints]
mainnet = "${MAINNET_RPC_URL}"
optimism = "${OPTIMISM_RPC_URL}"

2/ In your test file, do something like this:

contract MyToken_ForkTests {
  uint forkId;
  
  function setUp() public {
    uint forkBlock = 15_000_000;
    forkId = vm.createSelectFork(vm.rpcUrl("mainnet"), forkBlock);
  }

  function testSomething () public {}
}

3/ How it works: `vm.createSelectFork` creates the fork at the specified block number using the "mainnet" RPC URL specified in foundry.toml, returns the ID of that fork, and makes it active.

Now, all fork tests in that contract run against mainnet state. 

4/ Since an (optional) block number was passed, RPC responses are cached to speed up future test runs.

You can also change forks in a test as shown. Contracts deployed on a fork only exist on that fork. The makePersistent cheat lets you mark addresses to persist across forks.

5/ There's a whole set of related cheats you should check out: https://github.com/foundry-rs/forge-std/blob/2da2f4a3470b87c94e5616c4297f3651179950ed/src/Vm.sol#L165-L199

With this setup, a single `forge test` now runs all tests, both fork and non-fork, and foundry will automatically pick up the RPC env vars from a local `.env` file

6/ Be consistent with test/contract naming conventions: if you're offline and can't run fork tests, good naming conventions let you use the `--no-match*-` flags to skip anything with "fork" in its name

Credit to @mattsse_ for implementing to make fork tests super easy 👌


Forking with Foundry

Introducing Multicall3

A modern, efficient contract for aggregating results from multiple function calls

Deployed (almost) everywhere at 0xcA11bde05977b3631167028862bE2a173976CA11

https://github.com/mds1/multicall

Backwards compatible with previous Multicalls so it can be dropped in easily, though you should also check out the new, flexible, and highly optimized `aggregate3` and `aggregate3Value` methods

If there is a network it's not yet deployed on, let me know, and you can speed up the new deploy by sending funds to the deployer account: 0x05f32B3cC3888453ff71B01135B34FF8e41263F2

Big thanks to @andreasbigger for leading development, and to other contributors who reviewed the contract and gave suggestions:

@StittsHappening
@pcaversaccio
@_hrkrshnn
@transmissions11 
@brockjelmore
@joshie_sh
@_nd_go
@odyslam_
@lostbutlucky

(probably more I'm forgetting)

And also to the authors of the original Multicall: 

@michaelelliot
@jparklev 
@nicksdjohnson 

https://twitter.com/jparklev/status/1499110861255979009

@michaelelliot @jparklev @nicksdjohnson Ah how could I forget, built with Foundry of course
https://twitter.com/gakonst/status/1501633490550353924

Just deployed to 6 new chains

Multicall3 is now deployed at the same address on 18 different chains. Is this a record? 👀

(thanks @ahussein for supplying the funds for the new deploys) 

@harithk17 any chance we could get a "Multicall3" label on the contracts across the various networks?