-
Notifications
You must be signed in to change notification settings - Fork 457
feat: StrategyFactory contract #522
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This comment was marked as duplicate.
This comment was marked as duplicate.
fd751e3 to
6da040d
Compare
wadealexc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks fine, but IMO we want the BeaconProxy pattern!
switch to beacon proxies implemented in 5d19597 |
scotthconner
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These comments here mostly reflect what I put in the technical proposal. Nothing super critical, but understanding the core contract interactions and where state is managed is one piece that sticks out to me.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
This comment was marked as duplicate.
ce213b4 to
bb5f30b
Compare
| // @notice Upgradeable beacon which new Strategies deployed by this contract point to | ||
| IBeacon public strategyBeacon; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should add immutable?
wadealexc
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Needs docs. I'll put something together tomorrow :)
ypatil12
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One comment
| * @notice Owner-only function to prevent strategies from being created for given tokens. | ||
| * @param tokens An array of token addresses to blacklist. | ||
| */ | ||
| function blacklistTokens(IERC20[] calldata tokens) external onlyOwner { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the plan to blacklist already deployed tokens via the initializer? We don't want to get frontrun on a permissionless deployment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Resolved offline -> the deployment requires us to wait to transfer the strategyWhitelister role so we won't need to add this functionality in the initializer
| IStrategy strategy = IStrategy( | ||
| address( | ||
| new BeaconProxy( | ||
| address(strategyBeacon), | ||
| abi.encodeWithSelector(StrategyBase.initialize.selector, token, pauserRegistry) | ||
| ) | ||
| ) | ||
| ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we be using Create2 like we do in the EigenPodManager?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As an outsider, I definitely +1 this
| * $dev Immense caution is warranted for non-standard ERC20 tokens, particularly "reentrant" tokens | ||
| * like those that conform to ERC777. | ||
| */ | ||
| function deployNewStrategy(IERC20 token) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I could not find an event emitted when a new strategy gets deployed. EigenPodManager, for example, emits a PodDeployed event whenever an EigenPod is created, which can be used in subgraph templates to index instantiated contracts. Is it possible to do the same here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can use the StrategyAddedToDepositWhitelist event in the StrategyManager instead? Or do you want to track the count of contracts deployed from this contract?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
StrategyAddedToDepositWhitelist tracks only EigenLayer approved strategies that are shown on the UI, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we deploy a strategy through this method, it is added to the deposit whitelist. So it would be both EigenLayer approved AND permissionless strategies
14aa656 to
aa05081
Compare
|
bd1cc42 to
0960524
Compare
* fix: make the StrategyFactory actually whitelist new strategies * feat: add several unit tests for the StrategyFactory * feat: switch to beacon proxies * feat: split storage, create interface, and rename - separate storage contract - create interface -- storage contract inherits from it - rename `tokenStrategies` => `tokenStrategy` for clarity * chore: move events to interface * feat: additional unit tests, interface cleanup * feat: reduce owner powers, make mapping behavior strict - remove `editTokenStrategiesMapping` and `setStrategyBeacon` functions - make the `whitelistStrategies` pass-through function no longer edit the `tokenStrategy` mapping - delete and modify related tests, as necessary * feat: add several unit tests for the StrategyFactory * feat: switch to beacon proxies * feat: additional unit tests, interface cleanup * feat: reduce owner powers, make mapping behavior strict - remove `editTokenStrategiesMapping` and `setStrategyBeacon` functions - make the `whitelistStrategies` pass-through function no longer edit the `tokenStrategy` mapping - delete and modify related tests, as necessary * chore: formatting feat: add `blacklistTokens` fn refactor: separate mapping Feat: add `sharesToUnderlying` event (#644) * feat: add `sharesToUnderlying` event * refactor: cleanup * refactor: separate logic to new fn * test: sanity feat: emit exchange rate on deposits/withdrawals (#647) * feat: exchange rate in deposits/withdrawals * chore: forge fmt --------- Co-authored-by: clandestine.eth <96172957+0xClandestine@users.noreply.github.com> fix: strategy unit tests feat: add pass thoughts for all `strategyWhitelister` gated functions (#648) docs: add documentation for strategy factory methods chore: make bindings feat: change name of tokenStrategy mapping to deployedStrategies (#657) feat: auto remove strategies from whitelist (#658) feat: limit total shares on `StrategyBase` (#659) * feat: limit totalShares * chore: update natspec * chore: bindings & formatting * chore: bindings * docs: update docs with max total shares change * chore: fix formatting --------- Co-authored-by: wadealexc <pragma-services@proton.me> fix: natspec strategy factory (#660) * fix: natspec * chore: format * chore: bindings * chore: bindings * chore: bindings feat: integration tests docs: wip readme update docs: finalize deployment info in readme
0960524 to
b8694e9
Compare
|
All the activity you're seeing here is:
|
|
1 similar comment
|
|
1 similar comment
|
Proposal Doc: https://docs.google.com/document/d/1C1nN6BkCMS0Z9EnizU0pNYNNOiRd_FH6E2Vd-ZPULro/edit?usp=sharing
High-Level Notes on Design
This avoid making any changes to existing "core" protocol contracts, and is instead purely additive.
In particular, this change is effectively turning the
strategyWhitelisterrole in the StrategyManager into a smart contract -- the ability to whitelist particular strategies is maintained with a pass-through function, while the ability to whitelist factory-generated strategy contracts is made permissionless.Summary
The StrategyFactory allows any caller to deploy a StrategyBase contract for any ERC20 token
Still needs a few things, including documentation that provides warnings against using reentrant tokens (e.g. ERC777), or other non-standard tokens, and more extensive testing
Deployment
strategyWhitelisterrole in the StrategyManager to the StrategyFactory (proxy) -- this will require an executor multisig action and thus be subject to a 10-day timelock delay if accomplished via the ops multisig