Conversation
There was a problem hiding this comment.
It feels like we should fold this, the pool, and the router all into a single contract to minimize the amount of moving around assets we need to do? Or would we gain little benefit from such a combination?
There was a problem hiding this comment.
Yea thats the next thing I plan to take a stab at once this is in. Will involve a core contract that uses delegate calls for at least some of the implementation though bc of size constraints.
| import { TokenId } from "./TokenId.sol"; | ||
| import { IOICash } from "./IOICash.sol"; | ||
|
|
||
| contract AugurConstantProductShareToken is ERC1155 { |
There was a problem hiding this comment.
Does this actually need to be an ERC1155? I think the minimum requirement is that a user can "roll their keys", but I don't know if we need full 1155 support? I'm not sure if it helps us to remove ERC-1155 dependency though.
There was a problem hiding this comment.
It probably doesn't need the full ERC1155 but I think we wouldn't gain much by ripping out functionality. There shouldn't be much overhead of those features in its operation within our system. Its a good mental construct too for understanding how the system is operating and what state looks like.
There was a problem hiding this comment.
If this and other contracts are cribbed from OpenZeppelin we should include a comment at the top indicating as much along with a link to the original. If they are not cribbed from OZ, then I think we should consider doing so.
There was a problem hiding this comment.
They're cribbed from AugurV2 which may have been cribbed from OZ. Will look.
2 participants
Roll our own share token to cut some of the gas cost incurred by using real complete set operations