 This talk is all new content, and I hope to leave you with some new perspectives on what hyper-serts are all about, and why they're a good idea, and how we could go about making a hyper-sert system in the real world, by which I mean on a blockchain. Anyway, to go into what hyper-serts are about, I'm going to start by stepping back for a minute and talking about what certs are at all. What is the problem space that impact certificates are trying to address? Well, when a contributor performing an activity produces a public good, it's often the case that some members of the public, such as philanthropists and others, would be happy to exchange money for that impact having been realized. But unfortunately, because it's a public good that was produced in the past by this point, there is no one to give the money to and nothing to exchange it for, so this transaction doesn't really seem feasible. What the funder really wants to do is to send the money back in time and retrocausally use it to fund that activity, making it more likely to have already taken place. But unfortunately, this seems physically infeasible, but there is the potential of using a wormhole. A less costly idea is impact certificates. This represents the right to future retroactive rewards for a public good-producing activity, and whenever an asset that represents the right to a future cash flow is on the table, that induces the presence of a special kind of person called an investor who specializes in anticipating future cash flows and exchanging money for them today. In a transaction where they purchase an impact certificate from the contributor in advance of the activity, thereby providing the funding signal that anticipates the future rewards that are caused by the impact, and closing the loop here actually also makes that transaction possible by giving the public someone to hand the money to after the fact, and a plausible story about how doing so actually does retrocause the activity to be more likely to have been funded via the investor's anticipatory signal. So that's what impact certificates are trying to do. In reality, activities are not isolated points like individual paintings that one might trade in an NFT market. They're highly interconnected, so when one of them produces a public good, it's not always obvious who owns the right to that retroactive funding. That's where hyper-serts come in. I introduced this concept of the public goods space. This is a sort of geometric space with many axes. For example, the time the work was done and the scope of the work. And a hyper-sert represents a territorial claim in this public good space. It represents the right to retroactive rewards that are attributable to that region of public good space. Here we've pictured a two-dimensional slice, but there are actually more dimensions than just that. The full space, in addition to time of work and scope of work, also includes the time in which the impact actually bears fruit and the scope of the impact. Different kinds of funders might be interested in different sorts of impact ranging from carbon capture to averting an existential catastrophe from AI. There's also an axis for the set of contributors who are included and an invariant maintained by the system that all contributors who are listed consented to the minting of the certificate at some point along the way. And there are different types of rights. That's another axis. Most of them will be the right to retroactive altruistic rewards, but some of them will be deprived of that right and retain only bragging rights, while others may contain additional rights such as the right to passive income from intellectual property licensing auctions. That's the name hyper-serts. There's really a hyper-space and a hyper-sert as depicted here in a square is really a hyper-cube in that region, or a claim on a hyper-cube. Now I'm going to talk about the core operation that hyper-serts need to support, which is atomic merge and split, and I'm going to go through some examples. So if I have two hyper-serts, call them Y1 and Y2, and the owners of those hyper-serts want to propose a different way of splitting up the same region of the public good space, then as long as the different before and after sets add up to the same region, then this is an allowable transaction, and now these hyper-serts exist instead. Here's another example. Here we have three incoming hyper-serts. These add up to the same region as these two outgoing hyper-serts. That's a valid transaction. Finally, third example, the region doesn't have to be contiguous. This is just the same geometric subset of public good space, not necessarily contiguous. We wanted to make it have to be contiguous, that would just be more complexity in the code to check the condition, and there's no problem. All the invariants are maintained regardless of that. So this is another example. Now you're probably wondering why. What's the point of supporting this seemingly bizarre and complicated operation? Well, let me give you a user story. Imagine that hyper-serts existed as a functioning market in 2013, and Juan, the net, is making IPFS, and every quarter he mints a hyper-sert and offers it to his funder or sponsor in exchange for funding. Now, at some point, when this reaches a critical mass and the work really begins to pay off, the funder can make a more appealing NFT out of this collection of hyper-serts by merging them into one hyper-sert that represents inventing the first version of IPFS instead of just one particular quarter of work, even though the funder wanted to do the funding transaction one quarter at a time while it was happening. Now suppose this NFT is successfully auctioned off to some other trader participating in the hyper-sert market. This trader now considers that there are some people out there who would value the conceptual development of the IPFS concept almost as much as this entire body of work, and yet there are other people who would value the actual implementation of the first working version of the IPFS almost as much as the entire body of work. So the trader can realize a higher total value by splitting along the scope of work axis and then selling the separated hyper-serts to different parties who have different value functions. Rotating now from the time of work axis into a different axis, the time in which impact is realized. Here by default, both of these hyper-serts cover the entire scope of time, but when it comes to evaluating impact, assessing what the actual impact is or is likely to be, well there's obviously a difference between assessing past impact and future impact. Past impact is about observation, future impact is more about prediction. There are completely different sources of uncertainty and different methodologies. So when it comes time to assess, it's often going to be useful to split the hyper-serts along the time of impact axis, separating the past impact from the future impact and assessing them separately. And when another assessment is performed, the hyper-serts which had previously been the future, it will make sense to split them again into the newly passed impact and the still in the future impact and assess those separately. Because the times at which assessments happen are not necessarily fixed upfront, it's valuable to be able to perform these splits dynamically in the future. That's a segue into another benefit of the hyper-sert scheme which is to make the job of impact assessors a little bit easier. If I were hired to assess an impact NFT, at least for me, some of my first questions would be like, are we talking about past or future? Can we split those up somehow? What scope of work exactly is covered? Who were all the people that were necessary to make it happen? Did they all agree to this? Did they agree to the allocation that's being proposed that's listed on the certificate? When was the work that's supposed to be evaluated done? Am I supposed to be considering the prospect of future work on this project? Am I supposed to be evaluating like last month? Can we please like freeze an interval of time so that I can take some space to consider the work that had been done in that period without it changing as I'm evaluating it? So hyper-serts answer a lot of these questions right off the bat and they make the others a lot easier. It doesn't immediately answer the question, did all of the people who are necessary to make this happen sign on because some people could just be left out. The impact assessors just like in an ordinary impact certificate market will have to do some interviews and do some digging to satisfy themselves that there aren't people who are being unjustly left out, but other than that, the hyper-sert basically does the bookkeeping to keep track of at least that the people who are listed signed with their cryptographic identities and agreed to the split and so on. Another advantage is for a type of participant called a donor. A donor wants to contribute to a project and not receive anything, any tradable asset in return, there may be all sorts of reasons why that's the case, but they do want to have some on-chain bragging right to say like, hey, I'm one of the donors who supported this. Hyper-sert supports this by default because a donor can engage in a transaction where they merge into the contributor list, a hyper-sert that they meant themselves, in exchange for a transfer of ETH to the existing project team and leave the ownership of the entire hyper-sert in the hands that it's already currently in without taking any extra for the donor. This is a transaction which would then be on the chain and that donor would be listed as one of the contributors in the project from there on out. It's sort of like a transaction in which you get listed in the special thanks at the end of a YouTube video for being a Patreon subscriber. We could even imagine without changing any of the underlying hyper-sert framework building smart contracts on top of this, which would automate a Patreon-like system where every time there's some new piece that comes out and a new hyper-sert is minted, a transaction takes place, some ETH is taken, you get listed on the special thanks list, i.e. the contributor dimension, and so on. So these are just a few examples of some unusual use cases that we've thought of since devising the hyper-serts framework, which it already permits because hyper-serts sort of seem to accommodate all the transaction patterns that you would expect, like, oh, that should be allowed. That should be something you can do with property rights in public good space. And that's basically what hyper-serts are. They're a representation of allocation of property rights in public good space that allow exactly all the things that don't break some fundamental invariance, like every point in space is either unclaimed or fully claimed. The contributors for a given slice of public good space have to approve minting in that slice. Claimed space, once it's claimed, never becomes unclaimed. You can burn a certificate, but you can't make it unclaimed such that someone can show up in the future and claim it again. Owners must approve transfers, very basic invariant of any kind of bookkeeping system. So basically, hyper-serts are a great platform for experimentation with different kinds of mechanisms and different kinds of transaction patterns because it just takes care of the bookkeeping and makes sure the invariance are upheld while providing a great amount of flexibility for all sorts of different patterns and ways of getting public goods provisioned. And it will also enable the different experiments to interoperate with each other to exactly the extent that such interoperability would make sense from a property rights point of view. Another thing is, I don't have too much time to talk about this, hyper-serts is only about 10% of what I work on, and I also think about a lot of other mechanisms for provision of public goods. And hyper-serts integrates well with those. Part of that's about intellectual property, open auction based licensing. Part of that is about causal modeling of impact with formal road mapping. And part of that is about mechanisms for collectively allocating attention based on future, you know, anticipations of reward based on causal models and so on. All of these would be much easier with hyper-serts than with an unstructured kind of impact certificate. Okay, final question, how do we do this? So to answer that, I'm going to start by talking a bit about the OCO 1155, which I'm sure you've all heard of, and that's one of the first things that people will suggest as a way of approximating something like a hyper-sert ledger. It's the latest sort of Ethereum community accepted standard for non-fungible and also semi-fungible tokens. Hyper-serts are not exactly non-fungible in that I think it's important for hyper-serts to be infinitely divisible, or, you know, divisible up to 10 to some large number. But they are semi-fungible because there are many different types of hyper-serts which are not interchangeable with each other. Required operations for ERC 1155 are just transferring from an address to an address, importantly, a particular token type, an amount, and then some callback data, and getting the balance. How much does a given address own of a given token type? And there's batch versions of those, and there's a couple functions to delegate authority to approve transactions, and that's it. Those are the interface operations required for ERC 1155. Some key facts about this that I didn't know when I gave my last talk at Funding the Commons in March. One ERC 1155 contract doesn't just manage a single token type like ERC 20 does. It manages a whole suite. There is this argument, a UN 256 or 256-bit token ID that you can use to specify which token you're talking about to a single contract which manages all of them, and that's important because the atomic merchant swap transaction is one that cuts across many different types of tokens and even creates and destroys types of tokens, so there needs to be, nor does it be practical, a single smart contract that manages all the tokens, and the ERC 1155 allows that. Also an important fact that I didn't quite realize a few months ago is ERC 1155 is just a protocol specification. It's not a piece of code. There is, of course, a piece of code written by Open Zeppelin that is often copied and used to implement the interface for standard NFTs and SFTs, but it's not required that you copy that piece of code and have those behaviors to comply with the specification. The token types in ERC 1155 don't have to be URLs. It is, I was over-indexed on how everyone associates NFTs with actually just naming a single URL and saying, okay, now this is a tokenized thing. It would be a little bit difficult to wedge this idea of regions of this high-dimensional space into a URI, but that's not how it has to be. In fact, URIs are an optional extension to ERC 1155, and that extension is implemented not as a data field, but as a function, so it can be programmatically constructed based on data that's tracked in other formats. So our hyper-sourced contract can track all the extra structured data about what region of public good space is represented by each token ID that's been used so far. And finally, ERC 1155 doesn't mandate a too strict kind of invariant that would be appropriate if it were really NFT only. It doesn't, for instance, mandate that tokens not suddenly disappear for reasons unrelated to any operations requested through the interface. That's actually fine with ERC 1155, and that's great news for hyper-sourced because when someone wants to invoke an atomic merge and swap transaction, that's not part of the ERC 1155 interface, and it'll cause some tokens to spontaneously disappear. That's fine because we know what our invariants are as a hyper-sourced market, and ERC 1155 will just handle it and report it to its report events that these tokens have been transferred now. So, since hyper-sourced should support functions, the basic functions, like getting the balance of how much of one somebody owns, and transferring an amount that somebody owns to someone else without doing any fancy stuff, then hyper-sourced should be ERC 1155 compliant in addition to providing implementations of a more complex interface for atomic merge and swap that's hyper-sourced specific. The data structures and the algorithms for doing the Boolean algebra to check that an atomic merge and swap is valid are not trivial, but it's far from a grand challenge. The biggest risk is that it might cost a lot of gas. This is something that we should work out, try doing some implementations. I'm optimistic that there will be something that's not too hard to manage. My current estimate in terms of complexity is that this will be somewhere between basically three to five times as complex as vanilla ERC 1155, which is really not that bad, although it's going to be expensive to formally verify something like that, but we can get started without doing any of that. So then complying with this standard means that we'll be able to integrate with a lot of platforms directly without doing anything. It also, besides OpenSea and rarebo, IXO and others use ERC 155, there will be work to do to make that integration a good experience. There's also a need for a specific web platform that's specific to doing these hyper-sourced specific operations. And this will require a lot of thoughtful development of a product across all spectrums. And then there will also be work to do to convince people on various sides of this market that they actually should mint and trade and buy hyper-sourced and not just use NFTs for science and that sort of thing. Basically, marketing. So in summary, the wish lists for hyper-sourced for this year, there's a need for experienced EVM contract developer to actually implement the interface. There's a need for product user experience, web interface development, a backend to connect the web interface to the actual Ethereum blockchain and some kind of community manager. So if you or anyone you know might be interested in helping us make hyper-sourced a reality, please reach out to me or Holke Brammer who is also working at Protocol Labs and spearheading our hyper-sourced effort. Thank you. Thank you.