Exploring Hypercert Transfer Mechanisms

[daviddao]

Describe the feature you'd like to request

As the hypercerts ecosystem grows, we need to carefully consider how hypercerts can be transferred between parties while preserving their core properties and supporting various use cases. This discussion aims to explore the design space of hypercert transfers and their implications for impact claims, incentive structures, and market dynamics.

Describe the solution you'd like

Current State

Hypercerts currently implement basic transfer functionality through the ERC-1155 standard, allowing for both whole and fractional transfers. However, as we consider more complex use cases and ecosystem needs, we should examine how transfer mechanisms might evolve to better serve the purpose of impact claims and rewards.

Key Considerations

Atomic Properties of Transfers

The fundamental nature of hypercert transfers raises important questions about what exactly is being transferred. A hypercert represents a claim on retrospective impact, which has several implications:

When a hypercert is transferred, we are transferring the claim on the impact, not the impact itself. This distinction is crucial because it affects how we think about divisibility, aggregation, and the preservation of claim properties during transfers. For instance, if a hypercert represents the impact of reducing carbon emissions in a specific region, subdividing and transferring portions of that claim should maintain the integrity of the original impact measurement.

Economic Mechanisms

The transfer system could incorporate various economic mechanisms to align incentives:

Automated distribution mechanisms could ensure that value flows back to impact creators during transfers. Market-making mechanisms could help maintain liquidity while preventing manipulation. Bonding curves or other price discovery mechanisms might help establish fair values for impact claims.

Verification and Attestations

Transfers interact with the verification status of impact claims:

We should consider how transfers affect existing attestations and verifications. Should attestations transfer with ownership? How do we handle partial transfers of verified claims? What happens to verification status during aggregation or decomposition operations?

Questions for Discussion

1. What are the essential properties that must be preserved during hypercert transfers?
2. How can we balance transfer flexibility with impact claim integrity?
3. What role should automated economic mechanisms play in transfers?
4. How can we ensure transfer mechanisms scale efficiently?
5. What verification requirements should transfers impose?

Describe alternatives you've considered

Not allowing transfers after initial sale

[holkexyz]

Thanks @daviddao

Reg. the verifications and attestations: From my perspective and how it is implemented at the moment, the attestations are always linked to a whole hypercert. If a fraction is sold, the new owner of the hypercert has a proportional claim on the impact. The attestations aren't transferred directly.

To use the CO2 impact as a simple example (w/ the risk of oversimplification), suppose:

• A hypercert describes the protection of a forest for a given year
• An attestation is made to the whole hypercert that the work described sequestered 500 tons of CO2
• A hypercert fraction of 20% is sold to an new owner

Then:

• The new owner owns 20% of the hypercert that represents a claim to the impact of 100 tons of sequestered CO2 (based on that attestations)
• The attestation is still connected to the whole hypercert

As there can be additional other attestations, the sale of the 20% indirectly transfers the proportional impact claim of all of these attestation.

[holkexyz]

Reg. the economic mechanisms and verification, here is the spectrum of options:

1. Full transferability
2. Transferability only to whitelisted users, the whitelist is controlled by the hypercert creator
3. Transferability only from and to the hypercert creator
4. Only allowing an initial sale
5. No transfers

An interesting additional aspect is how profits are distributed if transfers are allowed, e.g. there are options such as

• Any profits a user makes is distributed to the original contributors, i.e. the project who did the work. This means that a user who bought a hypercert can only receive back the funds they paid originally (potentially allowing an additional "service fee")
• All funds are always distributed to the original contributors

I believe projects as the hypercert creators should be empowered through these rules. If a third-party creates a hypercert for a project, the project should still be the one benefiting from these rules.

While we could give hypercert creators the choice to choose their transferability rules, it is likely to be confusing for buyers if every hypercert has different rules. Hence, we should limit the options for simplicity of the whole system (at least initially).

[daviddao]

Thanks for this detailed exploration of hypercert transferability options! I agree that we should empower users to select their preferred transferability model, while being mindful of keeping the system intuitive and aligned with impact claims.

For the full transferability option, I strongly support the suggestion to limit it to non-revenue generating transfers (except for potential service fees). This creates a good balance between flexibility and maintaining the core purpose of hypercerts as impact claims rather than speculative assets.

Would it make sense to start with a limited set of well-defined options (like the spectrum outlined above) but with these revenue restrictions on the full transferability model?

[holkexyz]

Great. I briefly explored the option with @bitbeckers during a call. Enforcing only non-profit generating transfers for hypercerts everywhere, incl. outside of our systems, probably involves some significant changes. We should investigate this further, especially the technical options.

We could of course enforce it more easily either on our frontend or on our marketplace contracts.

[LuukDAO]

Hey folks, love the conversations going on here.

In our pilots in the Caribbean, we realized that the degree to which an asset is visible (in their wallet / UI) and portable (usable in other applications) greatly contributes to the users' (purchaser) perspective of something being "real" and having "value".

@holkexyz Is there a technical or other blocker to having Hypercerts shares be transferable ERC20s?

Given the broad (UI) support and utility of ERC20s, I'm confident the average "value" of a Hypercert share would increase significantly if issued as an ERC20.

[holkexyz]

Thanks @LuukDAO. I see the value in the composability of ERC20s with other applications. In theory hypercerts could be used with different token standards, every one having some pros and cons. For now I think there is value in not confusing users with multiple token standards of hypercerts, but lets discuss in our next sync if it is worth running an experiment.

[holkexyz]

@LuukDAO regarding the visibility in wallets: Hypercerts should show up in wallets if they support 1155s. Below you see an example from metamask, which also shows some issues with it

• Ideally it doesn't say "unnamed collection", but "Hypercerts"
• The pictures of the hypercerts should be shown
• I think not all of my hypercerts are actually displayed

@bitbeckers do you think this is something we can fix?
@LuukDAO I think there is still a case for ERC20 hypercerts, but I think this would be good to have in any case