EAS as Hypercerts Metadata

[ryscheng]

Describe the feature you'd like to request

Right now we have a hard-coded Hypercerts metadata. However, this leaves a lot to be desired because different use cases might have different refinements of the schema (e.g. a specific impact schema).

It'd be nice to be able to use any EAS attestation as the metadata of a hypercert. In other words, we can tokenize any attestation, with the current Hypercert metadata as a default fallback if EAS doesn't exist on some network.

Describe the solution you'd like

• Create an EAS schema with the current Hypercert metadata schema
• Give users the ability to fork that schema and make additions
• Provide some utility to check whether the resulting metadata "conforms". If it's too divergent, it makes it difficult for us to build the UX features we want.
• Update the contracts to be able to point to an attestation as the metadata, either on-chain or off-chain.
• Update the SDK to be able to fetch the metadata from all of these different options.

Describe alternatives you've considered

To be discussed!

[bitbeckers]

Great starter, thank you. Generally, I think implementing evaluations using EAS will be a valuable exercise and provide a lot of insight in how we can utilise EAS as a metadata-layer (e.g. on-/off-chain, unsupported chains, etc). So for now I'll try and focus on how we can leverage EAS schema to accomodate for multiple usecases.

Current

This is an example for the current hypercert metadata in an EAS schema: hypercert EAS schema

It basically captures the current data we already have, nothing magic. We did learn from experiments with FTC, da0, and Zuzalu that an application specific identifier is useful.

Application specific mints

With EAS we can wrap a schema in a schema, by either linking two schemas (similar to a lookup table) using the bytes32 UID as a pointer like in this schema

This might prove to be impractical because it'll require a series of signatures to attest to both schemas and their link.

What we can do, is add an applicationPointer to the basic metadata schema and utilise an applicationRegistry as a resolver contract. This allows projects/orgs to register who can sign attestations on their behalf. The schema would look like this.

When a user attests on behalf of an project/org, the registry would be called to validate whether the user is allowed to attest.

Domain specific information for work and/or impact in a generalizable manner

Work and impact is to abstract for robust indexing measures. One -ad hoc- example of a work attestation can be found in this schema. It brings a few things together:

• work type declaration
• metrics to quantify work done
• pointer to dataset
• arrays of external sources that can support the work claim
• applicationPointer similar to the pointer refered earlier.

In turn the basic hypercert metadata schema can be expanded to this schema. The primary changes would be:

• work as an array of bytes32 UIDs pointing to work attestations
• impact as an array of bytes32 UIDs poiting to impact attestations
• applicationPointer similar to the pointer refered earlier.
• the timeframes can be moved into the work attestations as well.

Contributors and rights could be represented on both levels.

Again, we could use a resolver to verify 1) supported work and impact attestation schemas, 2) authorisation on signers on behalf of an application. In the long run, this also is a step-up to splitting on work/impact because they're already compartementalized (on a basic level).

I think that in this case a set of attestations is less impractical because you can batch work executed at different points in spacetime into one hypercerts. Hypercerts becomes the de-facto container of work and impact.