Notes from the Sync session
Intent-centric Kickstarter
The idea is to build an intent centric version of Kickstarter which, in addition to being supply side-driven, can be demand side driven. Dominant assurance contract. A bunch of people who want something but only want to pay a little bit. High upfront cost and low marginal costs. If just marginal costs, don’t need to do intent matching. For example, Kickstarter frequently has art projects low cost of production. High cap ex low cost of production you sometimes see. The only way you can interact with Kickstarter as a producer. As a consumer you can’t say I want X, it’s not clear how to do a demand side service. Kickstarter doesn’t have solvers.
Kickstarter would need to dynamically match the demand side intents together. As a supplier, I can go to Kickstarter and say I want x now the second user says I want x’. Kickstarter could make a way for a user to say I want X and a user who wants x’ can piggyback off that intent.
This is the sort of theoretical concept.
Does it make sense and is plausible?
If we are talking about a real application of this, I think the use cases should be well scoped and narrow. Chains have requests for grants - optimism is like here are things we want people to research and build, and you can apply for this. The supply side is optimism committing to some funds partially.
I actually understand Optimism on the demand side. They are committing funds saying they want something. Optimism is just offering solo brands, they are not interoperating with Arbitrum.
So you want coordination to happen on the buyer’s side. Also, in that Delphi is pursuing this make ICOs great again project. Typically, how ICOs have been, that is the supply side. They rarely had minimums but also had maximums. Isn’t that crowdfunding, and don’t we have an abundance of crowdfunding use cases in crypto. There isn’t much matching on the demand side, and composing grants programs is very difficult. Need to figure out of Optimism and Arbitrum want the same thing for example partially social and technical problem.
Easy to think of as public goods? Kind of mostly just private goods which have capex. Multiple independent beneficiaries. We did discuss public goods, and it can be used for public good funding, but I don’t know if I would call it that.
Crypto use cases I think we should start with - grants are interesting
The hard thing about this app to build is how do you actually match the demand side? If the preferences are extremely specific, then this is an algorithm problem. Vague preferences are a bit more difficult to match. A simple use case is algorithmic optimization. I want to pay 5 tokens for a ZKP scheme that has a benchmark value under n seconds.
The second friction that comes after is how much everyone is contributing and if it’s all fair because you can free ride it right? I think this is true with true public goods which typically software is. In the above example, the benefit is 3 different rollup teams, but there would be friction who contributes how much.
In principle, they can just do their grants programs using this software. People doing algo optimizations don’t have to deal with many different grants programs.
Funding Hardware
The more specific something is the easier it is to run the matching algorithm. I could also imagine crypto crowdfunding for hardware which has high capex and low marginal cost. I will people would do ICS for hardware production - extend it beyond the production of protocols.
Hardware production thus far is incentivized by crypto economics - mining proving or solving yes. But hardware that users use like a phone. Imagine a Solana phone that is generic. Maybe Zcash has more specific requirements etc.
Currently, they are using this as a marketing this, right? Until there are real benefits. All of this stuff is compatible. Solana phone is a perfect example here. In fact, the real hardware production happens. They didn’t buy a facility to produce a phone, stuff like this type of crowdfunding.
A phone is a good example because it would be very useful as its kind of specific but not entirely - phones we can say the demand side consists of various phone preferences individual user won’t be writing intents. I want a phone with these specs, this enclave, this tech, unlocked carrier neutral, detailed specs are needed. The other thing in kickstarter is this reputation scheme. If you find demand side, you need to be okay with them and front them some capital. Maybe all the demand side is aggregated, they get bids, runs consensus and then determine what they pick. There might need to be multiple rounds of negotiation with a phone.
It feels like there would be a lot of back and forth until the whole transaction becomes a formal document that you sign.
In real life there are different documents at every stage - indication of interest being signed and terms are vague and then as you work on it, both sides work on a specific contract and each side lawyers change terms then we have a final contract. If it’s a repetitive thing, you might not need much back and forth anymore. Many social interactions in this specific example.
Maybe the question is there an elegant way to fuse these things. The first thing you need to do is discover who wants a phone? Perhaps the output of this step is you identify more about who wants something, then you modify intents. This can happen fractally or repeatedly in different places, and at some point there is a clear articulation of demand, and you edit intents back and forth. How to interface legal and digital contracts? Repeated interactions are a reputation system plus embedded organizational knowledge. On the other hand, it’s true in supplier-supplier relationships.
MVP
Can we do something like an MVP? Crypto people like gamification a lot. A donation use case
- I commit to donate x amount if Vitalik commits to donate x’ amount.
- Identity contingent commitments.
It could be for funding, even something silly like constitution DAO. Companies already do this in real life. It’s only credible because they have a reputation. We could enforce these commitments on chain. This works well between DAOs as well. This public good needs, some funding - enforced mostly with reputation than with actual smart contracts. It seems many Ethereum rollup teams feel pressure to donate to the protocol guild, for example.
In bridges, there are 2 chains that want to bridge, so they commit to provide x amount of liquidity if the other side commits. It could be part of the token allocation of the chain, so you wouldn’t need third parties to do this - governance decision.
It seems like people like Identity contingent donation stuff like donation DAOs or something. You need the ability to verify the name service and funds need top be locked for some amount of time. You can make commitments that people can cancel or withdrawal as well. Likewise, you want an interface where people can make these commitments. And Vitalik can also see what the consequences are. This seems workable.