Skip to content
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

extend token gating features (wrt protocol v2.3.0) #795

Open
levalleux-ludo opened this issue Aug 30, 2023 · 1 comment · May be fixed by #893
Open

extend token gating features (wrt protocol v2.3.0) #795

levalleux-ludo opened this issue Aug 30, 2023 · 1 comment · May be fixed by #893
Assignees

Comments

@levalleux-ludo
Copy link
Member

levalleux-ludo commented Aug 30, 2023

v2.3.0 introduces some new ways to manage the token gating. This new ways would require some adaptation in the dApp (including UI/UX)

  • seller side:
    • ERC20 token gate: no change (the seller needs to set a threshold balance the buyers need to own)
    • ERC1155 token gate:
      • before v2.3.0: the seller needs to select a tokenId and a threshold balance (of this tokenId) the buyers need to own
      • v2.3.0: now the seller can select a range instead (minTokenId, maxTokenId). The buyer will need to own at least the minimum balance for at least one of the token ID in the range. The seller can now decide if the gatingType is "per token" or "per wallet", that tells how the maxCommit is evaluated.
    • ERC721 token gate:
      • before v2.3.0; the seller can select a specific tokenId OR a threshold balance (of any token id) the buyers need to own. In any case, the gatingType is "per wallet" (once a wallet has reached the commit limit, it can no longer commit)
      • v2.3.0: the seller can select either a threshold balance (of any token id) OR a range (minTokenId, maxTokenId) in which case they can decide if the gatingType is "per token" or "per wallet"
  • buyer side
    • when committing to a conditional offer, a new method should be called (commitToConditionalOffer, instead of commitToOffer), passing a tokenId as an argument, depending on the token gating type:
      • for an ERC20, tokenId should be set to "0"
      • for an ERC721 with a threshold balance, tokenId should be set to "0"
      • for an ERC721 with a token range, tokenId should be chosen amongst the tokens owned by the wallet with id in the specified range. In case the gatingType is "per token", a token that is not "consumed" yet.
      • for an ERC1155, tokenId should be chosen amongst the tokens owned by the wallet with id in the specified range. In case the gatingType is "per token", a token that is not "consumed" yet.
    • before commitment, the UI is expected to show if the user is allowed to commit (criteria match or not):
      • for an ERC20, no change (check the balance and maxCommit limit per wallet)
      • for an ERC721 with a threshold balance, check the balance and maxCommit limit per wallet
      • for an ERC721 with a token range, check the token ownership and maxCommit limit per wallet or per token regarding the gatingType.
      • for an ERC1155, check the token ownership and maxCommit limit per wallet or per token regarding the gatingType.

To be considered:

  • the protocol now implements events (ConditionalCommitAuthorized) and methods (isEligibleToCommit) to allow tracking the token gating limits
  • so to be added in the subgraph to make it available to the dApp
@albertfolch-redeemeum
Copy link
Contributor

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants