Marco/mp 1027 template design merchanttokenfactory contract #9
Conversation
src/MerchantToken.sol
Outdated
| error UNAUTHORIZED(); | ||
| error INVALID_ADDRESS(); | ||
|
|
||
| contract MerchantToken is MerchantFactory { |
There was a problem hiding this comment.
🤔 I know this MerchantToken is MerchantFactory relationship is borrowed from our previous factories, but it's always thrown me for a loop. Since this is our Nth factory, I think it's worth reassessing the interface between these two contracts.
In my head, I imagine a Factory deploying Tokens, but the way it's written at the moment, these are one and the same and we've just broken up the code somewhat arbitrarily between two files.
Let's either change the relationship between these two contract files, or just consolidate them and break out a helper contract along a different boundary
There was a problem hiding this comment.
one specific refactor i'd suggest, we have 3 deploy related functions:
- MerchantToken.deployToken()
- MerchantFactory.deploy()
- MerchantFactory._deploy()
These could be consolidated into a single MerchantFactory.deploy() with helper functions to break it up as necessary. At the moment, we don't even call MerchantFactory.deploy() so that code + MerchantFactory._deploy() never get used.
…Full functionality on new template.
| uint256 _lpReserve, | ||
| uint256 _airdropReserve, | ||
| uint256 _rewardsReserve | ||
| ) external returns (InstantLiquidityToken token) { |
There was a problem hiding this comment.
For reference, here are the old /airdrop params:
{
"network": "base", // not necessary in this function
"symbol": "METALTEST", // included _symbol
"initialPrice": 0.001, // now passed in via createLiquidityPool()
"name": "metal test", // included _name
"totalSupply": 1000000000, // included _totalySupply
"recipient": {
"address": "0x000000000000000000000000000000000000dEaD", // included _merchant
"supply": 4000000 // included _merchantAmount
},
"airdrop": {
"addresses": [
"0x0000000000000000000000000000000000000001",
"0x0000000000000000000000000000000000000002",
"0x0000000000000000000000000000000000000003"
], // will now be passed in via direct gaslite call in metal-service
"supply": 8000000 // included _airdropReserve
}
}
New fields:
_rewardsReserve
_lpReserve
looks good 👍
There was a problem hiding this comment.
I know we've used the name merchant internally, but I'm not sure I like it in this context. these will eventually deployable by the users of the merchant too. what about creator instead? that'll be accurate whether it's a merchant or a user of the merchant.
| if (_rewardsReserve > 0) { | ||
| merchantTransfer(address(token), signer, _rewardsReserve); | ||
| } | ||
|
|
There was a problem hiding this comment.
| // lpReserve remains on the factory until createLiquidityPool is called |
src/MetalToken.sol
Outdated
| // proxy swap | ||
| INonfungiblePositionManager(0x56c65e35f2Dd06f659BCFe327C4D7F21c9b69C2f); | ||
| } | ||
| } |
There was a problem hiding this comment.
function _getAddresses() can be moved to Constants.sol or a new helper contract since it shouldn't change and isn't specific to this factory.
No description provided.