[Feature] Burn Hypercert

[bitbeckers]

Goal

The creator of a hypercert is capable or burning the hypercert token they created

There are two types of tokens in the HypercertMinter:

• ClaimToken (e.g. 10) representing the claim
• FractionToken (e.g. 11) representing the first fraction (1) on the claim (10)

There are two type of protocol users:

• Creator (registered as creator of ClaimToken in contract)
• User (owner of a FractionToken)

We have three types of TransferRestrictions:

• AllowAll
• DisallowAll,
• FromCreatorOnly

Usecases

• [ ] Creator can burn the ClaimToken when they own all FractionTokens
• [ ] Creator can burn a FractionToken when they own it
• [ ] User cannot burn a FractionToken
• [ ] User cannot burn a ClaimToken when they own all FractionTokens

[bitbeckers]

https://github.com/Network-Goods/hypercerts/issues/117

[bitbeckers]

@holkeb @ryscheng could you review and expand on the Usecases in the top post?

[ryscheng]

Hmmm.... I'm seeing that the primary distinction is that a user and creator has different burn permissions...

@holkeb I'm curious what do you think about this:

• [ ] Creator or user can burn the ClaimToken when they own all FractionTokens
  • [ ] Creator or user can burn a FractionToken when they own it

[holkexyz]

1. For retiring of hypercerts, I think we only need the burning of the fractions, i.e. (like @ryscheng proposed)

   • [ ] Creator or user can burn a FractionToken when they own it

2. There doesn't really seem to be a need to burn the ClaimToken, except maybe if a Creator made a mistake creating it? (like @bitbeckers proposed)

   • [ ] Creator can burn the ClaimToken when they own all FractionTokens (and the ClaimToken)

3. I don't see a case why a user should be able to burn the ClaimToken, when they hold all fractions.

   • [ ] User cannot burn a ClaimToken when they own all FractionTokens

Reg. 1 and 2:

• In case 1 the claim still occupies the area in the impact space, even though all FractionTokens are burned.
• In case 2 the claim doesn't occupy the area in the impact space. Potentially for the collision checks we can just check all ClaimTokens. If a ClaimToken is burned, it isn't included in the collision check. The FractionTokens are then irrelevant for the collision check, including if they are burned or not. Does that makes sense?

Previously I thought we would need to have two different addresses: One to retire. Another one to burn and unclaim the area. But I guess with the ClaimToken, we don't need two addresses for that anymore.

If case 2 is difficult to implement, we don't necessarily need it.

[ryscheng]

how do you feel about this @bitbeckers ?

[bitbeckers]

• Since we don't really reuse tokenIds I think it might even be cleaner to simply not being able to burn the ClaimToken.
• "When they own all FractionTokens" can become pretty costly and complex to determine, I think it's easier to check if the FractionToken holds all available units (in our current case 10000)
• We also have this check in the contract before a token transfer:

          if (isBaseType(ids[i]) && from != address(0)) revert Errors.NotAllowed();

  This check only allows the transfer of a ClaimToken when it's minted.

This can bring us to two conclusions:

• Allow both the user and creator to burn a FractionToken.
• Implicitly we've made the ClaimToken a non-burnable SBT; this also means it will always be displayed in OpenSea

Is this agreeable for you @holkeb and @ryscheng? Alternatively we allow the creator to burn the ClaimToken together with the FractionToken that holds all the units denominated in the ClaimToken.

[holkexyz]

Reg. your conclusions @bitbeckers

1. "Allow both the user and creator to burn a FractionToken." only if they own them, right? so the case 1 in my previous comment?
2. If the ClaimToken shows up in the wallets, we also need to have a clean narrative for it. Not yet sure if we want that. If everyone would mint only their own contribution, I think it would be cool to have this. However, if I mint this for two contributors, why does one have the claim token and the other don't. Would an alternative be that the ClaimToken is directly transferred to a null address? i.e. it is stored there to be referenced by FractionTokens?

[bitbeckers]

Yes to both.

There might be some checks in the underlying contracts regarding tokens owned by the zero-address, but I think your solution makes a lot of sense. I'll create an issue, make the changes and test them out.

[holkexyz]

I think for now this is the cleanest to not confuse people with multiple tokens. There is something in the back of my mind that makes sense as well though: If all contributors would have an SBT, they have prove of having done the work. Then they also have a hypercert that they can sell, but they always keep the proof that they did the work.