add alt-registry allocation spec #41
Conversation
| ### Custom Variables | ||
| This strategy will need the following custom variables: | ||
| - `poolOpen` - boolean value that represents whether the pool is accepting new applications | ||
| - `alternateRegistry` - location of alternate registry of eligible recipients |
There was a problem hiding this comment.
I think we should dial in on one specific example like Hypercerts, Passport(when onchain is ready), Givith or Optimism.
EAS is another option which I am very fond of experimenting with.
There was a problem hiding this comment.
Based on how the protocol has developed, will it still need these custom variables? I don't think so
There was a problem hiding this comment.
@0xZakk poolOpen might not be relevant, but we need somewhere to account for how the strategy will check for eligibility, right?
| - Is `poolOpen` true? | ||
| - If yes, proceed | ||
| - If no, revert with message that pool is not accepting proposals | ||
| - Is recipient present in `alternateRegistry`? |
There was a problem hiding this comment.
We may wan to use different wording here; i.e. Is the recipient not only present (define what this means) the alternateRegistry but the user meets certain qualifications. We need to think about how to make this versatile and show the ability to use any kind of registry. Should we be forcing the alternateRegistry to be an address or maybe even a centralized API?
There was a problem hiding this comment.
@codenamejason all I'm trying to articulate here is that the logic for this specific strategy should just be whether or not the address is in a registry. Would you want me write that differently in the spec? or is that something you want to solve for in the code?
There was a problem hiding this comment.
Are we talking about an alternate registry which implements the registry interface / just having a gatekeeper for new applications ?
Additionally what is voting mechanism here ? Is it similar to QF ?
Each of these gatekeepers would be it's own contract, we could define a base contract and implement flavours of them but for starters -> could we pick one usecase and update the spec to reflect that
|
Put together PR #44, which can be merged into this PR I think the goal here is just to showcase that you can write a strategy that uses another registry. Similarly, you can write a strategy that doesn't use a registry at all. PR #44 implements a very simple example of what an alternative registry might look like, which should hopefully help us think through what this strategy will need to do. That's all we're trying to do here, so the voting method for this allocation strategy can be something really simple (maybe just most votes wins, or something) |
@thelostone-mc are these questions still relevant given Zakk's mock and our discussion? If not, can you approve and merge |
thelostone-mc
force-pushed
the
alt-registry
branch
from
14892bb
to
3394584
Compare
|
Reverting the commit to HEAD~1 and pushing the alt registry to the strategy PR |
No description provided.