[OPEN CALL TBA] Bonding Curves and Curation Markets Research

Hello everyone,

i’m planning to host a regular session on Bonding Curves and Curation Markets here https://meet.jit.si/bonding-curves

Date and time for the next call to be announced, please suggest agenda topics

The idea is to discuss potential standards for new funding mechanisms but also for curated registries (which we could use for a decentralised aepp store).

There are many resources online about the topic. I’ll post a few to get started here.

Many more to follow!



Is the first one next week (or was it the day you posted)?

What time zone is it in? :slight_smile:

Next week March 20th 5:30pm CET :slight_smile: - just confirmed with Emin

1 Like

We will have a guest, @moritzfelipe from www.dacade.org will join us.


Article I mentioned on short selling in bonding curves: https://blog.oceanprotocol.com/enabling-short-selling-in-bonding-curves-part-1-af871ad75d40

Here is a link to the artice I wrote and briefly presented on “Curved Bonded Derivatives” https://medium.com/@moritzfelipe/introducing-curved-bonded-derivatives-c975a7cd09a

Thank you for the great meeting

We have spoken and mentioned a lot of things

  • game theoretical aspects
  • problems against scammer and solutions to prevent it (short selling, sell and buy curve)
  • if it can be used for crowd funding
  • how secondary markets come into play
  • how it is comparable to todays financial market with companies that sell shares and IPO later

And many other things. The whole recording will be available soon and i will post it here. Thank you everyone for participating.




Was mentioned too.

1 Like

Recording of the call


In order to find a better time and come up with an agenda for the next Bonding Curves Call

I would like to invite you to suggest agenda topics and a suitable time here.

In consideration of the time difference i’m suggesting a call around 11 am CET so people from China can more easily join.

An agenda topic i would like to discuss is a sample Sophia Smart Contract for a simple Bonding Curve.

1 Like

I just watched the recording. Thanks for hosting and recording @emin.chain !

As far as topics: I think it would be great to figure out what use cases can be tested in a proof of concept way [minimum effort, quick’n’dirty, small amounts] for the sake of taking the conversation from discussion to action/verification. For this we would need some technical people (like Milen) to participate (to help determine the difficulty of implementing different use cases, even in a POC way). I’m happy to participate as well [not because I know how to implement this on top of æternity, but because I can contribute to use cases discussions].

One point around the URL example that was discussed: while I think this would work in general (I invest in something which grows in popularity over time), it is rather difficult to find digital mediums to invest in, which can be protected. We discussed this at length in one of the sessions at the æpps summit, hosted by @RuFussed. A URL for example would be next to impossible to protect from sharing freely [to keep it scarce]. However an artist token might work… The problem there becomes around what is actually being bought and sold [what does the token represent? rights to future royalties, access to the artist, only the resale of the token?]… There is also the issue of is it a security or a utility token (ex. URL would likely be a security, as the holder is not actively participating in increasing the value… unless they were sharing the URL as a requirement… or unless one could prove that consuming media increases its value ;)).

In any case, I am sharing the sentiment above, to highlight that in depth discussions around specific use cases are needed to take this from concept to reality (even in a POC way). I personally do not think that creating a general API for this would be terribly helpful, because I doubt that it would serve the needs of specific use cases well.

I think a meaningful approach is to try to test specific use cases… and then maybe generalize the API as much as possible… but not the reverse [build a general API and hope someone will try a specific use case on it]. Maybe/hopefully I am wrong… but that’s how I see it with my current experience/knowledge. :slight_smile:

@emin.chain - there is already such a call with some of the smartest people in the space -

1 Like