You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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)
To be considered:
The text was updated successfully, but these errors were encountered: