1.3b Tooling Development (Smart Contracts)

[steve0xp]

Factory Smart Contracts

• [x] Research factory contracts & set one up on feat branch for custom pools
• [x] Create custom pool factory sc
• [x] Write deployment script & test with testnet
• [ ] Write foundry tests to test its functionality (generating pools, etc.)
• [x] Get questions on factory scope --> it is meant as a template, not audited, liability etc :O
• [x] Write rough README sections for factory - including disclaimers on it being not production ready and teams need to make their own of course.
  • Finalization will be done in another PR.

Custom Pool Examples

• [x] Create rough constant price pool
• [x] Finalize constant price pool example (natspec, etc.)
• [ ] Write template unit testing for example custom pool (use constant price pool for example)
• [x] Write constant product pool example roughly
• [x] Finalize constant product pool example
• [x] Write rough README sections walking through the example pools
  • Finalization will be done in another PR.
• [x] Obtain feedback from BLabs and Grants
• [x] Finalize based on feedback

[steve0xp]

Quick Research Notes on Factory creation:

• See balancer monorepo for IBasePoolFactory, BasePoolFactory, StablePoolFactory, and create a CustomPoolFactoryTemplate contract that outlines how one creates a CustomPoolFactory.
• They would create a custom pool, then create the associated customPoolFactory, and finally the scaffoldBalancer tool would stitch into said factory contract.
• So I guess the scaffoldBalancer should work with the examples we have, including the factoryExample. If we make it work with just one of the types, but also have both constant price and constant product factory contractsthen that’s cool

[steve0xp]

Updates from last time:

• Created CustomPoolFactoryExample.sol referencing balancerV3-monorepo

Today:

• Write deployment script & test on local fork

NOTES:

From Discussions w/ Matt: Recall: the full repo, off the shelf, will do the following: deploy a constant price custom pool factory, deploy a new pool from said factory, register and initialize the pool.

The factory and the new pool will be deployed, off the shelf, in the local mainnet fork. So the dev can interact with their new pool with the ScaffoldBalancer front end. They can also interact with it via scripts and other development tools including hardhat and foundry.

1. Creating new pools once the factory is deployed:
   • Going with a hardhat script so dev can simply run make createPool or something with the appropriate params within a script. This is alternative to doing it within the debug tab in the localhost FE. The main reason to do it this way vs the FE was that it would be a better developer UX as it would be cumbersome to repeatedly type in the input params via the debug tab (especially if a machine crashed, etc.).
     • SE-2 currently doesn't have the foundry framework setup so it feeds new internally deployed contracts and their addresses to new scripts. Thus we are using hardhat scripts. We'll still have foundry scripts in case devs want those, but they will have to feed some foundry scripts with contract addresses appropriately.

Next Steps:

• Deploy local host and front end, see if custom pool factory is shown properly in debug tab, make sure scripts work with Sepolia.
• Run createPool script and check the new deployed pool in the FE.
• Merge the PR to dev branch. The dev branch will then have a new PR on it to update the setup so it works with local mainnet forks by default as per PR #24

[steve0xp]

Questions for Balancer Labs Team Possibly (Draft)

1. Are pools registered if they come from a BalancerPoolFactory that abides by the Balancer architecture? I guess the better question is how do we know that a specific Balancer Pool Factory abides by the Balancer architecture / standards?
2. Does initialization happen before or after registration?

[johngrantuk]

Questions for Balancer Labs Team Possibly (Draft)

1. Are pools registered if they come from a BalancerPoolFactory that abides by the Balancer architecture? I guess the better question is how do we know that a specific Balancer Pool Factory abides by the Balancer architecture / standards?

2. Does initialization happen before or after registration?

1. It permissionless so any pool could be registered. It won't be scaffolds job to enforce standards.
2. Register then initialise

[steve0xp]

Beating me to the punch on even finalizing the questions! Haha, thanks @johngrantuk.

[steve0xp]

More Questions / Requests for Feedback from Balancer Labs specific to CreatePoolFromFactoryExample.s.sol - THIS NEEDS TO BE FINALIZED BEFORE REVIEWING WITH BLABS

1. So if a factory is created that inherits BasePoolFactory, are pools from said factory automatically registered? This message below is causing me to ask:

2. Default Setup:

• At a high level, the tool will work like this: “Front end allows people to play with newly created pool, scripts and solidity contracts are used to create said initial pool to play with.” There are two categories of development: 1. using the local mainnet fork, and 2. using a network (testnet or prod).
  • FIRST (local mainnet fork): The first goal is to set the front-end so the developer can play with the pool created from the script. Let’s call this the “default setup.” We will have it so they run one script (that creates the pool factory and creates a new pool from it) so they have everything they need to be able to play with it from the get-go.
  • NEXT (Testnet): The developer will want to deploy it to a testnet. They’ll set up their env and then can deploy accordingly using a different script (or I have my script conditional based on chainID somehow). The front-end aspect now involves the user connecting a wallet and interacting with the newly created pool.
  • NEXT (prod development): They can use the Testnet scripts as a template and create their production scripts. The front end operates the same as the Testnet
• So the front end will need to load appropriately depending on what network it is on (local, testnet, or prod). I know this is possible but can’t remember how it all is jigged up
• For now, I’ll create the script so it seeds the liquidity from the deployer wallet from the env file, but I’ll mark a TODO on handling scenarios where we are working with local mainnet forks. - So the default, via a script, would have these new tokens (scBAL and scETH) minted to the front-end wallet that the user is connecting so they can do things like “addLiquidity, etc.” because they have the necessary tokens

3. Should the pricing of assets with Balancer be OKed before working with new assets? Currently, we run scripts to deploy and mint 1000 fake ERC20 tokens $scBAL & $scETH where we assume 1 scBAL == 1 scETH. If these tokens are newly created (fresh ERC20s) on mainnet forks or testnets, do we need to add rate providers for them before creating pools that the Balancer vault will register?

[steve0xp]

The remaining test TODOs are being handled by PR #34 and are also documented in issue #28. Thus I am closing this issue.