Hypercerts Architecture Idea

[carlbarrdahl]

I propose the following approach that would enable an SDK that can be used across platforms that does the following:

• Link Platform accounts to a canonical Hypercerts Account via redirect flow similar to OAuth but for web3 (linkable user identities)
• Create and manage Organizations and send transactions on behalf them
• Create Hypercerts
• Buy/Sell Hypercerts
• Withdraw funds from Hypercerts
• Create claims pointing to the Hypercert (in this model a hypercert is a container that can contain many claims)
• Verify claims to endorse work claims and/or Hypercerts
• Attach resources (media, docs, photos, videos, text, audio etc) to claims and evaluations

This Hypercerts primitive supports a wide-range of use-cases including funding research, environmental work, HyperSponsor, and many more. It maintains minimal infrastructure to run and use commonly used building blocks such as SmartAccounts, EAS, and ERC4626. The platforms can choose how to sign in their users and only need to provide a signer (Privy, Alchemy, etc provide Web2 UX for this so no web3 wallets needed).

Smart accounts are used to enable canonical accounts for both user and organization that contain metadata about them.

User accounts are multi-owner smart accounts in which the user can add additional signers directly from platforms. The user would sign in on Platform A and then link that account to the hypercerts account by opening a hypercerts web page where they can approve adding the platform wallet address. This makes it possible for platforms to choose how they sign in their users (metamask, rainbowkit, privy, alchemy, human wallet, etc).

Organizations are Safe accounts with a module plugin for metadata for name, description, and any other relevant data. This means the Hypercerts Indexer can pick this up and resolve the metadata so it can be queried and searched. Zodiac modules enable more granular access control to determine the membership roles and their access levels in how they can act on behalf of the organization. For example, admins might want to directly send transactions while members need approval from 3/5 signers for example.

This provides a powerful primitive for how organizations are managed that gives the ability for organizational ownership of assets that are governed by its members.

Both these accounts (Hypercerts Account and Organization) can be managed via a hypercerts web UI where they can enable passkeys, session keys, etc. Similar to any other OAuth provider.

Certs can be created directly from platforms via an SDK and on behalf of user or organization based on who the attester address should be.

Certs are created as smart contracts that are owned by its issuer. For example, a claim created by an organization is governed by it and can be transferred to another address.

Evaluations are represented as EAS attestations with the recipient as the impact claim contract address. This means when an impact claim is transferred, the evaluations are automatically included because they point to the contract.

Funds can be transferred to the contract and tokens emitted as a receipt of that funding that proves who funded what and when. Let's call them impact tokens.

The owners of the contract can withdraw the funded tokens and spend them to continue their work. Hypercerts are fundable.

Funders can also transfer the impact tokens back to the claim in exchange for usdc to "cash out" on their earlier investment. The value of the impact tokens is determined by the amount of usdc in the contract in ratio to how many impact tokens (shares) have been emitted.

Transferring usdc into the contract without minting new shares (for example grants) will increase the value of the impact tokens and thus providing a return of investment for the early funders if they choose to exit.

This mechanism is essentially a Vault (commonly used for staking and yield).

Adding metadata to the impact claim contract describe the what, when, and where.

Any kind of attestation can be created to the impact claim contract. Impact evaluations for example.

Example flow

A research paper has been written by Alice who creates a Hypercert (Vault). She adds metadata about the title and description. In addition she can create an attestation with the paper itself pointing to the Hypercert.

Alice's mentor Bob wants to support her work so he transfers $100 into the Hypercerts and receives 100 impact tokens (IT) at 1 IT = $1.

Carla later sends $50 and receive 50 IT.

The balance in the contract is now $150 with the shares:

• Bob: 100
• Carla: 50

A foundation discovers the paper and gives a grant of $1000. They do this without receiving any impact tokens so the balance is now $1150 with the same amount of shares.

Alice withdraw $100 to support her daily activities.

Bob and Carla's shares remain and the hypercert has $1050, each share now valued at $7.

Now, if Bob where to exit with his 100 IT he would receive $700, the cert would contain $350 with all shares owned by Carla.

Dave buys 200 IT for $2800.

Limits on how much or frequently the withdraws are allowed could be set by the contract.

This concept can be applied to other types of impact, for example:

• a group of people are planting trees, they create a Hypercert with the metadata and a geoJSON describing the area they are planning to plant in.
• on day 1 they plant 100 trees and create an attestation describing this to the Hypercert
• on day 4 they plant additional 150 and again attest to it. They also provide photos as evidence.
• they continue like this and on day 30 an organization visits the site and confirms how many trees they observe. These evaluations provide
• people and organizations fund this initiative and receive the impact tokens as proof of supporting the cause.
• the group can payout parts of the funding to cover expenses.

Adding vesting for how much funds can be paid out over time creates financial security of reliable source of funds and accountability to continue the work for more funding.

[carlbarrdahl]

Recorded a Loom showing the mechanisms for vaults described:
https://www.loom.com/share/df57f3c12d2e458582483855a1d1382d

[aspiers]

Thanks @carlbarrdahl for sharing this work so eloquently (Loom videos are super helpful!)

It does indeed look like an interesting way to distribute ownership of Hypercerts, which could well be useful in some use cases. I do feel pretty strongly that the Hypercerts protocol should not require this to be the only tokenization route (and I don't think you are proposing that anyway).

IIUC, one drawback of the 4626 approach is that it requires deploying a contract per hypercert. This could be fine for use cases with a low volume of hypercerts, but not for use cases with a high volume since the gas costs would be orders of magnitude higher (even when using minimal clone proxies). If we were operating in a centralized offchain world, this would be a bit like creating a new hypervault-123 database table (with identical schema to many other HyperVault database tables) every time a new hypercert row was created in a hypercerts table. An alternative might be something similar to 4626 which supports independently tracking shared ownership / funding of multiple hypercerts within a single contract, so that you don't need to deploy a new contract per hypercert.

Anyway, I am currently thinking the protocol should allow different platforms to devise different mechanisms for financialising hypercerts, which could be via your ERC-4626 mechanism, or via ERC-20, or ERC-1155, or perhaps even others or combinations of the above. I think this is broadly inline with v2 conversations over the last few months. It means that Hypercerts is not opinionated about how hypercerts should be funded / sold, and allows unlimited experiments by platforms to find what works for them.

This shouldn't pose a problem in terms of preventing overlap of hypercerts, since it's the impact claim data which needs to be analysed for that, not the token. There is a downside that the indexer for onchain tokens then needs to index multiple types of tokens. But maybe we could just stick to ERC-20 and 1155 and stipulate that these are deposited inside the ERC-4626 (or whatever other contracts people want to wrap around hypercerts) so that the HyperVault (btw cool name!) is purely a commercial mechanism for funding the Hypercert, and doesn't impose any hard architecture requirements on the Hypercerts protocol itself.

[carlbarrdahl]

IIUC, one drawback of the 4626 approach is that it requires deploying a contract per hypercert. This could be fine for use cases with a low volume of hypercerts, but not for use cases with a high volume since the gas costs would be orders of magnitude higher (even when using minimal clone proxies).

I've been thinking if it makes sense if the Hypercerts are a container to which a lot of smaller work is being done (work claims, verifications/evaluations etc). One organization might have a hypercert for each project or region and the work claims are being created to this contract address. This would reduce the token fragmentation and partly solve what you mention.

Anyway, I am currently thinking the protocol should allow different platforms to devise different mechanisms for financialising hypercerts, which could be via your ERC-4626 mechanism, or via ERC-20, or ERC-1155, or perhaps even others or combinations of the above.

Something to consider here is that the ERC4626 is actually a pair of ERC20 (assets and shares). So these shares are transferable like fungible tokens while the ownership of the ERC4626 itself can be transferred. So in some ways, it is similar to ERC1155 while still maintaining composability with defi.

[aspiers]

Yes totally agree on your points about abstraction layers! That's what I was trying to do last week with the list of abstraction layers I shared in Obsidian notes:

• Authentication
• Authorisation
• Identity
• Large data storage
• Small data indexing - querying
• Small (meta)data storage
• Tokenization

although I think you've persuaded me that there's another layer I missed:

• Financialisation / commercialisation

(Not sure if these are the best words to use, but essentially I mean ways of funding / selling Hypercerts.)

So in this architecture proposal, the use of ERC-4626 belongs in this commercial layer. That strongly suggests to me that it doesn't belong in the tokenization layer, because having a single smart contract span two abstraction layers feels like a design smell. So for example you could tokenize as ERC-20 or ERC-1155, and then deposit that token into the 4626 Hypervault to allow it to be funded / sold.

I've been thinking if it makes sense if the Hypercerts are a container to which a lot of smaller work is being done (work claims, verifications/evaluations etc). One organization might have a hypercert for each project or region and the work claims are being created to this contract address. This would reduce the token fragmentation and partly solve what you mention.

I'm not sure I understand what you mean here, but to me work claims, verifications/evaluations etc. should all belong in the data layer not the tokenization layer. The tokenization layer needs to reference them, but I don't think it should contain them because then we have hard-coupling between data and tokens which we had in v1 and are trying to avoid in v2. For example we are very interested in being able to keep all of that data offchain (although ideally we don't want to enforce that either). But please lmk if I'm misunderstanding something.

Something to consider here is that the ERC4626 is actually a pair of ERC20 (assets and shares). So these shares are transferable like fungible tokens while the ownership of the ERC4626 itself can be transferred. So in some ways, it is similar to ERC1155 while still maintaining composability with defi.

Yes, I think this is probably another way of phrasing what I was saying above, i.e. that a Hypervault can contain a hypercert (asset).

I think it's also worth noting that while an ERC4626 Hypervault is one way of tracking shared ownership of a hypercert, it is definitely not the only way. In fact there is a much simpler way, which is to simply support the normal transfer and balanceOf() functions provided by ERC-20 and/or ERC-1155. In v1, the non-standard usage of ERC-1155 prevented this and made ownership changes very difficult because they only allowed a balance of 0 or 1 and required splitting and merging to implement fungibility. However I strongly believe we should avoid that in v2.

[carlbarrdahl]

Here's how I see the layers:

• Authentication
• Authorisation
• Identity

These are handled by smart accounts. The user account (or HyperAccount) is a MultiOwner where we can add additional signers. This means that any of these signers can transact on behalf of the HyperAccount. The second, for Organizations, is a MultiSig with Zodiac to handle granular roles (if necessary).

The biggest down-side with this approach is how to handle cross-chain. The ATproto identity solves this but at the cost of requiring additional logic for juggling web3 signer + at proto identity (unless there's an elegant solution to this - essentially, how to send transactions from the ATproto account).

• Large data storage
• Small (meta)data storage

In the proposed architecture it's stored in EAS with pointers to storacha (ipfs). But again, I see the down-side of potential network fragmentation rather than putting it in ATproto. It is more censorship resistant though.

• Small data indexing - querying

A Ponder Indexer could aggregate the data from SmartAccounts, EAS, and ipfs for all the networks. So one indexer contains the data across chains.

• Tokenization
• Financialisation / commercialisation

These could be the same? If shares are represented by an ERC20 it connects to the defi ecosystems (amm, yield, lending).

I'm not sure I understand what you mean here, but to me work claims, verifications/evaluations etc. should all belong in the data layer not the tokenization layer. The tokenization layer needs to reference them, but I don't think it should contain them because then we have hard-coupling between data and tokens which we had in v1 and are trying to avoid in v2. For example we are very interested in being able to keep all of that data offchain (although ideally we don't want to enforce that either). But please lmk if I'm misunderstanding something.

Yes you might be correct. The way I was thinking about it is:

• an organization creates a Hypercert, which is the container for the work they are doing. This is represented as a smart contract (could be a simple Ownable that can be transferred or ERC4626, or a composition of many).
• all data connected to the hypercerts (work claims, evaluations, documents, etc) is using the contract address as the pointer / id
  • this data can be a tree structure and be constructed into graphs
• this means all the data connected to a hypercert can be queried and the hypercert connected to any specific data can be found

Something to consider here is that the ERC4626 is actually a pair of ERC20 (assets and shares). So these shares are transferable like fungible tokens while the ownership of the ERC4626 itself can be transferred. So in some ways, it is similar to ERC1155 while still maintaining composability with defi.

Yes, I think this is probably another way of phrasing what I was saying above, i.e. that a Hypervault can contain a hypercert (asset).

I think it's also worth noting that while an ERC4626 Hypervault is one way of tracking shared ownership of a hypercert, it is definitely not the only way. In fact there is a much simpler way, which is to simply support the normal transfer and balanceOf() functions provided by ERC-20 and/or ERC-1155. In v1, the non-standard usage of ERC-1155 prevented this and made ownership changes very difficult because they only allowed a balance of 0 or 1 and required splitting and merging to implement fungibility. However I strongly believe we should avoid that in v2.

The ERC4626 is actually just a container or a mechanism for what happens when tokens (eg USDC) are sent to the contract.

It might be that this proposal is too simplistic and doesn't cater for all the use-cases required. It also doesn't solve storing the data in a chain-agnostic way.

I just think the puzzle pieces fit neatly together and provide a lot of expressability and power with fairly little complexity.

[aspiers]

Here's how I see the layers:

• Authentication
• Authorisation
• Identity

These are handled by smart accounts. The user account (or HyperAccount) is a MultiOwner where we can add additional signers. This means that any of these signers can transact on behalf of the HyperAccount. The second, for Organizations, is a MultiSig with Zodiac to handle granular roles (if necessary).

It could work, but I have a few potential concerns about this approach:

1. web3 UX issues: Is it possible to require every user to have a web3 account whilst avoiding bad UX? While I'm generally quite bullish long-term (or even mid-term) on the potential of smart accounts to vastly improve web3 UX, in the short term I'm not sure whether we're there yet. (I'd LOVE to be proven wrong!) In contrast, we already know that using ATproto gives a very friendly UX for authentication, and doesn't require gas fees. How easily could we achieve both of these with smart accounts right now? And even if we can, would this lock us into using certain types of smart accounts? If so, what are the long-term risks of this lock-in?
2. RBAC: How easy is it to implement RBAC via Zodiac modules? My general feeling is that smart accounts were designed to handle custody of digital assets with better UX, but were never intended to be a general authorisation / RBAC layer. If they were, I suspect there would be no need for protocols like Hats. So I do worry a bit about trying to shoehorn RBAC into smart accounts.
3. Avoiding lock-in: While it's important to run experiments with different tech stacks in these early stages of v0.2, we shouldn't lock ourselves into long-term decisions around fast-moving technology areas like web3 authentication. My intuition is that we should choose technologies which we can switch out for alternatives fairly easily. Standardizing on DIDs for identity (without requiring use of a specific DID scheme) is one example. So a relevant question to the Safe / Zodiac approach would be: if we started building with that and then needed to switch to another solution, how easy would that be?

The biggest down-side with this approach is how to handle cross-chain.

The ATproto identity solves this but at the cost of requiring additional logic for juggling web3 signer + at proto identity (unless there's an elegant solution to this - essentially, how to send transactions from the ATproto account).

Yes exactly. I think the ongoing and planned PoCs around linking ATproto accounts with web3 accounts are really important:

1. Embedded wallets using Bluesky / OAuth for authentication
2. Embedded wallets using passkeys
3. Bidirectional linking of ATproto account with existing (BYO) web3 account

If we can gain confidence in these multiple approaches then it should be a big unlock.

• Large data storage
• Small (meta)data storage

In the proposed architecture it's stored in EAS with pointers to storacha (ipfs). But again, I see the down-side of potential network fragmentation rather than putting it in ATproto. It is more censorship resistant though.

Agreed on the downside and upside. In the Berlin workshop we raised quite a few concerns about the challenges of placing metadata on one chain and then having to either duplicate it on or move (bridge) it to other chains, both of which are ugly problems (I can attest to this from my Toucan experiences). But you are right that EAS provides a maximally decentralized solution to metadata storage.

• Small data indexing - querying

A Ponder Indexer could aggregate the data from SmartAccounts, EAS, and ipfs for all the networks. So one indexer contains the data across chains.

Yep. And anyone could be free to self-host an indexer. As with data on ATProto, this raises longer term questions about sustainability (i.e. who will pay for the index service availability) and verifiability (e.g. a malicious indexer could hide double-counting of impact). Perhaps solutions like EigenCloud could solve for this eventually. But probably we shouldn't get too distracted with those long-term challenges at this early stage.

• Tokenization
• Financialisation / commercialisation

These could be the same? If shares are represented by an ERC20 it connects to the defi ecosystems (amm, yield, lending).

To me, the tokenization layer is purely about tokenizing Hypercerts, not tokenizing derivatives like share schemes built on top of Hypercerts. I think it's important to keep them in separate abstraction layers, because the Hypercerts protocol needs to be clear about how it supports tokenization of Hypercerts, but it shouldn't be opinionated about how Hypercerts are funded / sold (otherwise it could easily prevent interoperability and innovation in this area). So I think tokenizing shares (e.g. via ERC-4626) is firmly in the financialisation / commercialisation layer, not the tokenization layer.

I'm not sure I understand what you mean here, but to me work claims, verifications/evaluations etc. should all belong in the data layer not the tokenization layer. The tokenization layer needs to reference them, but I don't think it should contain them because then we have hard-coupling between data and tokens which we had in v1 and are trying to avoid in v2. For example we are very interested in being able to keep all of that data offchain (although ideally we don't want to enforce that either). But please lmk if I'm misunderstanding something.

Yes you might be correct. The way I was thinking about it is:

• an organization creates a Hypercert, which is the container for the work they are doing. This is represented as a smart contract (could be a simple Ownable that can be transferred or ERC4626, or a composition of many).
• all data connected to the hypercerts (work claims, evaluations, documents, etc) is using the contract address as the pointer / id

That would require:

• a) the smart contract to be created before any of the hypercert metadata, which seems incompatible with our requirement to decouple metadata from tokenization, and
• b) one smart contract per hypercert, which presents scalability concerns due to gas costs.

• this data can be a tree structure and be constructed into graphs

I agree we should aim for graph structures - not sure why we would need trees though?

• this means all the data connected to a hypercert can be queried and the hypercert connected to any specific data can be found

Couldn't this be achieved with any uuid scheme for Hypercerts? I'm not sure why it would need to be a contract address. Also, a contract address doesn't uniquely identify which chain it lives on.

The ERC4626 is actually just a container or a mechanism for what happens when tokens (eg USDC) are sent to the contract.

Right. It could also hold one or more Hypercerts for which it's issuing shares. I think anyone should be free to implement financialisation mechanisms like this without needing them to be explicitly supported by the core Hypercerts protocol. The protocol should just make it possible as a result of choosing the right abstraction layers.

It might be that this proposal is too simplistic and doesn't cater for all the use-cases required. It also doesn't solve storing the data in a chain-agnostic way.

I just think the puzzle pieces fit neatly together and provide a lot of expressability and power with fairly little complexity.

Yeah, there are certainly a lot of interesting thoughts and potential experiments here. My main concerns are that we should maintain a clear separation between (meta)data, tokenization, and financialisation.

[carlbarrdahl]

Great feedback @aspiers! Thank you!
I hear the value proposition of decoupling metadata and tokenization as well as the web2 ux authentication and I think you're correct.

It would be fantastic if this can all be solved with an intuitive way for developers to implement and that still provides great ux.