Below, you can learn how to use the Itemsy newsletter creator to send out emails with inspiring link curated by you:

Finally, here is what you newsletter sign-up form would look like in action:

Set up your Itemsy account today. It’s free!

Add email newsletter subscribe form on Medium was originally published in I T E M S Y on Medium, where people are continuing the conversation by highlighting and responding to this story.

• stop using multiple reading lists, notes, keep tens of tabs open
• always be able to go back to or find new interesting reads
• when time is right, receive my personal email newsletter

One-click save

You come across an interesting article, website or video. Simply save it for later using Itemsy Chrome or Firefox extension. Add a note to remember why you’re saving it.

Alternatively, add it to your Saved items at itemsy.com or email the link to my@itemsy.com.

Scroll through Picked for you

Feel like discovering something interesting to read? Go back to itemsy.com and check out items Picked for you.

We developed an algorithm that looks at content you like, click on, share or save and suggests what else you might find interesting.

What’s picked for you is based purely on your interests, not on how much advertisers bid on a particular link or how “clickable” it is. Suggestions get better tailored to your taste the more you use Itemsy. Needless to say, no two user’s Picked for you will be anything alike!

Personal newsletter — just for you

Don’t worry about remembering to actually go through the items you’d saved. They will be delivered to your inbox as an email newsletter. You can set it to fit your schedule, for example at 5pm on weekdays.

Start using Itemsy today. It’s free. Register at itemsy.com, download our Chrome or Firefox extension or simply email items to read later to my@itemsy.com

Daily reading routine using Itemsy was originally published in I T E M S Y on Medium, where people are continuing the conversation by highlighting and responding to this story.

This short blog post explains how to add a newsletter to your blog using Itemsy in 3 quick & easy steps.

Step 1/3

Create an Itemsy profile:

Step 2/3

Every time you post on your blog, publish the link on your Itemsy profile

Step 3/3

Share your Itemsy profile for people to subscribe to. They will receive all new posts straight to their inbox.

P.S. In case you need inspiration, that’s one interesting profile set up on Itemsy:

3 Random Wiki (3randomwiki) - I T E M S Y

How to add newsletter to your blog was originally published in I T E M S Y on Medium, where people are continuing the conversation by highlighting and responding to this story.

Last Friday, we launched I T E M S Y on Product Hunt with almost no preparation. We were very positively surprised by the response and wanted to share some lessons learned.

1. Great product is the single best marketing channel

It may seem like a good idea to spend time asking friends for support. But in the end it’s a numbers game and what counts is upvotes from Product Hunt regulars who visit the website every single day. So you might as well focus all your energy on making a product people want rather than spend the whole day asking your friends to create an account and upvote. It’s convincing the daily Product Hunt users that is key to success!

2. Quickly launch the most basic version of your product

This will help you in two important ways: you can launch sooner and you’re more likely to test whether your core product actually solves a real problem. If it’s unclear what your product really does, all your experiments will give ambiguous results.

Bonus: people who comment on Product Hunt are likely to request the exact features you’d already built but haven’t yet unveiled . That’s what happened to us and that’s a good place to be!

3. Your one-liner must be crystal clear

Hopefully, the above one-liner is 100% clear 😉. If someone who read just your one-liner is unable to explain to their friends what your product does, you’ve failed. Ask yourself if you would have (i) understood exactly what your product does and (ii) visited your website only having read your one-liner, nothing else. Also, fewer photos that are clear and simple is usually better. Most people will spend very little time on your PH profile.

4. People want to instantly try out your product

This obviously puts more complex products at a disadvantage but is very important. At an early stage, you want to make it as easy as possible for people to try out your product and teach you how to improve it (that’s through analytics that you carefully set up before launching, didn’t you?).

Signing up to I T E M S Y takes 10 seconds and just your email. What’s even cooler is that you actually don’t even need to sign up! Just start using it by sending links to my@itemsy.com. The way we onboard users is that everyone is already onboarded.

5. Choose the right day of week

Landing in top 5 Products of the Day is what you want. Top 5 make it to the next-day Product Hunt newsletter which is a big win. But be careful, Friday is an exception where you need to compete with Saturday and Sunday people for the Monday newsletter spot (which we learned the hard way…). On the other hand, competition for the top 5 is probably more fierce Monday — Thursday (curious, can anyone confirm?).

Final thought

Product Hunt is not a one-off effort but rather a long-term asset that brings traffic to your site. Keep it in mind and make sure it ages well.

5 non-obvious lessons learned from our Product Hunt launch was originally published in I T E M S Y on Medium, where people are continuing the conversation by highlighting and responding to this story.

Came for the data, stayed for the Excel

Spreadsheets have become a natural end point for every BI, accounting or data management tool. No matter how sophisticated, slick or “made with ❤️ in SF” the tool is, eventually you’ll always want to export data to Excel.

As a result, data is always centralised on a local hard drive and shared with others via dozens of emails. Arguably, Excel has become the most popular database (and programming language) in the world which makes email with an .xls attachment the most popular medium of data exchange.

Even if you do store all your spreadsheets in the cloud, it is anything but easy to fish out the specific number or insight you’re after. You’ve always got countless outdated and duplicated spreadsheets floating about.

While Dropbox made it easy to store files online, there is no good solution to quickly set up, share and edit data in the cloud.

Those Excels your whole team needs to share

How would you like a private database that takes 30 seconds to set up? Everybody on your team immediately gets access to all the data. And it’s as easy to use as Google. I mean, just try it.

We believe you should be able to pick up a new software tool and get value out of it in 30 seconds.

Also, it needs to be fast. And look good.

Go to equityfront.com and see how you can get set up in 30 seconds

Turn all your spreadsheets into a lightweight searchable database was originally published in Equity Front on Medium, where people are continuing the conversation by highlighting and responding to this story.

One thing that makes marketplaces so complex is feedback loops.

Let’s say we want to estimate the effect of spending $1,000 on supplier acquisition. That will result in some change in suppliers’ behaviour. While that’s difficult enough to estimate, it will also affect customers’ behavior. That, in turn, has an effect on suppliers. Eventually, the whole system converges to an equilibrium that is notoriously hard to predict.

That’s not totally unlike the problem of designing economies of blockchain smart contract systems. And that’s something we’ve done before.

Go ahead and use the same technology to simulate your marketplace with human-like AI agents.

The Simulation Tool allows marketplace creators to:

• Experiment with different pricing models
• Simulate the effect of different customer acquisition efforts
• Customise for their particular scenarios and KPIs

If interested, watch the demo, try it yourself and reach out to have your marketplace simulated before your next big decision!

The hard thing about marketplaces was originally published in Incentivai on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Augur system was simulated using the Incentivai tool. This blog post summarises some of the findings and agent behaviour patterns found during the analysis.

Key findings

1. Agents convinced about their belief choose to exit Augur rather than migrate to a losing universe. Often, they would migrate to the winning universe and exit.
2. Expected lower trading volume => Lower expected income from fees => More speculative use of REP (compared to use of REP for reporting)
3. Overwhelming fork majority =>Scarcity of false outcome token => Speculative trading or migrating => Artificially inflated price
4. Expected higher trading volume => Believers in minority outcome migrate to winning universe and exit sooner (because the REP price there is higher)
5. Reporters likely to change their mind AND Unsuccessful dispute stake being returned => Stakers disputing correct outcomes
6. Lower resolution fees before market closes compared to after it has closed incentivise higher trading volume

Reporting and forking

The Augur protocol allows anyone to setup a prediction market on any piece of information of their choice. The correct resolution of markets is ensured by means of specially designed reporting and forking mechanisms.

This section walks through a number of simulation scenarios highlighting the key findings. Each scenario features a number of agents who interact with the Augur simulation environment by making decisions about which actions to take. The choice is determined by their strategy aimed at optimising for long-term profit conditioned on private belief about which outcome is true.

Scenario 1

Scenario 1 looked at a typical prediction market with two possible outcomes: A and B. Approximately 70% of users are assumed to believe that B is the true outcome. Following a dispute process, the market is assumed to go into a state of fork.

The fork is decided in favour of the true outcome B (orange), 25.4% REP gets migrated to universe A (blue). What helps resolve the fork with a larger margin is that some A-believers migrate to the winning universe B and sell their REP.

Agents convinced about their belief choose to exit Augur rather than migrate to a losing universe. Often, they would migrate to the winning universe and exit.

The graph below shows the evolution of order book mid-prices of the newly-created REP tokens in universes corresponding to outcomes A (blue) and B (orange).

What is interesting to observe is the fact that initially, the price of false outcome REP A is kept relatively high before it decreases. Part of the reason for it is the fact that some B-believers were willing to buy some of REP A purely speculatively. Even though they considered the token worthless, they were willing to buy it hoping to later sell with profit.

Scenario 2

In this scenario, all agents are assumed to believe that A is the true outcome. Additionally, it is assumed that following the fork, trading volume (thus income from fees) is expected to decrease.

What results is an interplay of the following factors:

• Low REP valuation in the winning (A) universe
• Great scarcity of false outcome (B) token

As a consequence, even though all agents believe B to be the false outcome, its price is kept artificially high due to its scarcity. Additionally, due to low REP valuation in the winning universe, reporters that have migrated there are relatively open to allocating some of their budget to speculation. That involves trading the REP B token or even migrating some of their original REP to the false universe.

Expected lower trading volume => Lower expected income from fees => More speculative use of REP (compared to use of REP for reporting)

As a consequence of expected low trading volume, price of the winning REP A drops to a lower level soon after the fork starts. Price of REP B, on the other hand, is kept artificially high by the factors described earlier.

Overwhelming fork majority =>Scarcity of false outcome token => Speculative trading or migrating => Artificially inflated price

As a result, in this particular scenario, price of the losing universe token is at times higher than the winning one. Fortunately, that effect is very far from threatening the outcome of the fork.

Scenario 3

In this scenario, 80% of agents are assumed to believe that B is the true outcome. This time, trading volume (thus income from fees) is expected to increase following the fork. Additionally, this scenario explores an assumption inspired by bounded rationality concepts. It is possible for agents to change their private belief about which outcome is true based on how other agents have been staking/migrating so far (follow the majority).

During the fork, migration to the false universe A occurs only early on and quickly stops. One contributing factor is the follow the majority assumption which means that over time agents who initially believe A is true are increasingly likely to change their mind. Additionally, due to expected high trading volume, REP B price is high which makes A-believers more likely to “give up” and exit Augur by migrating to the winning universe and selling. That is a desirable effect which helps the fork resolve with a larger margin.

Expected higher trading volume => Believers in minority outcome migrate to winning universe and exit sooner (because the REP price there is higher)

Interestingly, price of the winning universe REP (B, orange) token is initially inflated and corrected afterwards. Demand for REP B is only satisfied once migration has progressed enough and its supply has expanded. Agents who have migrated to the losing universe A only start trying to exit on their tokens later on (following the REP B price correction) and are forced to set the price low due to little interest in speculation from winning universe reporters.

Scenario 4

In this scenario, all agents are assumed to believe that A is the true outcome. The follow the majority assumption is also included.

It is assumed that the first reported outcome is B, the false one. Therefore, in the first dispute window, a large amount of stake is deposited to dispute it. Naturally, it is successful and another dispute window starts. What is surprising is that some stake does get deposited on disputing the true outcome. While it is nowhere near enough for a successful dispute, it is informative to explore the likely reasons behind that behaviour:

• Unsuccessful dispute stake is being returned which makes that action relatively low-risk
• Under the follow the majority assumption, the small chance of gathering enough momentum to change the outcome might be enough to justify the cost of transaction fee required to submit the dispute stake

Reporters likely to change their mind AND Unsuccessful dispute stake being returned => Stakers disputing correct outcomes

Trading

This section looks at some aspects of trading on Augur. Agents are assumed to have noisy private belief about probability of outcomes A and B on a particular market.

Transaction and resolution fee

Augur traders are subject to two types of variable fees. Transaction fee is associated with Ethereum gas cost. Resolution fee is incurred whenever a trader who owns outcome shares resolves with the market. That may occur either when market closes or when two sell orders get matched.

Whenever a sell order gets submitted, it may either get filled or matched. From trader’s point of view, the former is preferred since in the latter case they are subject to both transaction and resolution fee.

Manual vs UI users

Whenever traders who use the Augur UI submit sell orders, they don’t know whether they would be subject to the additional resolution fee. Such users, for whom trading is overall more costly, will be referred to as UI users.

Manual users are assumed to be able to manually submit well-timed sell orders, thus make it much more likely that they be filled rather than matched. As a consequence, manual users may be able to trade at lower cost but at the same time they would be under more pressure to try and exit on their shares early rather than hold until market closes.

What follows is comparisons between manual and UI user behaviours. A number of simulation scenarios were run assuming different transaction and resolution fees. Interestingly, it will shed light on a more general problem of how adjusting mid-market and closed-market resolution fees might affect traders’ behaviour.

Trading volume

Not unexpectedly, trading volume was observed to be lower in scenarios with higher transaction fee for both user types. What makes the difference between manual (blue) and UI (orange) users’ behaviour is resolution fee.

As resolution fee increases, the difference in trading volume between manual (blue) and UI (orange) users becomes bigger.

One way to interpret the difference between manual and UI users is that the former effectively pay a lower mid-market resolution fee. They are incentivised to try and exit on their shares before market closes. As a consequence, trading volume increases.

Lower resolution fees before market closes compared to after it has closed incentivise higher trading volume

Volume of buy orders

For UI (orange) users, volume of buy orders decreases consistently for higher resolution fees across low, medium and high transaction fee values.

It is interesting to observe that for manual (blue) users, when transaction fees are not too high, the volume of buy orders is almost independent of resolution fee. Agents are willing to buy shares almost regardless of higher resolution fees since they rely on being able to time sell orders well and exit before market closes.

High transaction fees (bottom graph) make trading more costly. That results in UI users’ volume of buy orders more sensitive to increased resolution fee.

Conclusions

Simulation allowed for identifying and analysing potentially beneficial mechanisms and potential threats to Augur reporting and forking processes. Those included exit strategies for believers in losing outcomes, artificially inflated false outcome token price and consequences of users following majority.

Trading simulation allowed for identifying and exploring the impact of lower resolution fees before market closing. That mechanism may be used to tune the tradeoff between fee amount and trading volume.

I would like to thank the Augur team for their invaluable suggestions and support while completing this work.

Please read the Incentivai legal disclaimer

Simulation of the Augur economy was originally published in Incentivai on Medium, where people are continuing the conversation by highlighting and responding to this story.

Many people give blockchain technology too much credit. Many give it too little credit. I believe that is at least partly due to there being a confusion as to what it is really that we can do now that we couldn’t without blockchain.

What is it that makes something a C thing? I believe there are two requirements. If either of them is not strictly necessary, it’s a B thing.

What you want to build is a C thing if and only if it is required to be:

1. Decentralised
2. Self-executable

I will provide explanations and examples to add more colour to the above. Before that I do want to say two things.

The above definition is not rigorous because neither of the above two is binary and fully well-defined. For example, there might be different levels of decentralisation. The same design might be sufficiently decentralised for one application, not another. Ultimately, it is a matter of subjective judgment.

It is not to say that blockchain should only ever be used for C things. There are many reasons why it should also be used for B things, for example for educational purposes.

Decentralised

A system is decentralised if no one person or entity can decide its outcome without first coming to an agreement with others.

If 10 people go on a trip and it’s Franek who decides whether it’s going to be to Cambridge or Oxford, it’s a centralised system. If everyone votes and majority decides, it’s a decentralised system. If 3 people go to Franek and say “you decide, please vote on my behalf”, the system becomes more centralised.

Systems can be decentralised to a certain degree, it’s not binary. What makes it sufficiently decentralised for a particular use case is a matter of judgment.

Self-executable

A system is self-executable if, based on its operation today, there are sufficient guarantees that it will continue operating in the foreseeable future. The definition only considers systems that require human input, thus have an economy element to it. (strictly speaking “the Sun rising every morning” is also a self-executable system)

Bitcoin, the bank where you keep your savings, the API your company uses to stream weather data can all be considered self-executable to a certain degree. Maintainers of those systems would incur substantial financial loss if they were to suddenly stop operation.

Some people describe the above concept by calling blockchain trustless or the trust machine. Self-executable systems replace the strong assumption that people are trustworthy with a much weaker assumption that people are economically rational.

Not decentralised, self-executable

Most of what we interact with in the world today, belongs to this category. If I am reading a newspaper today, I am fairly confident that the next issue will be available tomorrow. Me being able to purchase it today is a sufficient proof that publishing newspapers is a profitable enough business for it to be available in the foreseeable future.

However, whether the newspaper is still a reliable source of information tomorrow depends on just one entity, the publisher. If they are economically irrational, or have incentives external to making a truth-seeking customer happy (e.g. focusing on ads or promoting particular political views), they have enough power to overnight decide to stop being one.

Decentralised, not self-executable

This one takes a bit more imagination.

Imagine I am running a small shop that sells fruit and vegetables. I want it to be completely decentralised. Every morning, I ask every single person in the city what they think the price of every product should be and then use the median vote as the actual price.

Some people might think that average would work better than median so if more than 50% back that proposal, it gets enforced. Some might think that 50% is too low of a majority and voting time should be extended to 2 days. If those get enough backing, they get enforced too. In short, I simply provide the suggested initial rules of the system and they are free to be disputed and changed by the city population.

That solution seems very decentralised but at the same time not self-executable. It seems highly likely that running the shop and constant voting would make the business very unprofitable. Me, as the shop owner, would quickly decide to give up on it or would never have started it in the first place.

Decentralised, self-executable

Most of you probably found the above scenario quite ridiculous. Please note, however, that there is only one element missing from making it essentially what Bitcoin is today: make it self-executable.

Remove the shop owner and add clever technology to make running the shop and voting smooth. As long as users believe that other users see value in a shop where no one person can change its prices or shut it down, the shop will run forever.

Not so fast

It’s not that easy though. What stops me from bribing a lot of people to vote to set the price of apples to $0.0001, buy all of them and later sell on the black market? Hopefully, the rules are set up in such a way that that scheme (or any other I could possibly think of), wouldn’t work. I would either end up losing money, or other people wouldn’t be interested in accepting my bribes.

We need to come up with every possible attack and make sure it doesn’t work. What if we missed something?

There is no way to stop the shop once it’s been launched. We might start a new, improved shop v2.0 and hope that all people switch to that one. It is possible that they will, especially if the change is in their benefit. But that also comes at a cost. Switching once every few years is probably fine. Switching as frequently as iPhone app upgrades is certainly not fine.

It would be really great to get it right the first time…

What do we do?

Great question.

Test for all the possible attacks?

Sounds like a lot of work. Also, you need to be confident that none of the numerous grocery-hackers eyeing millions of $$$ worth of apples would be able to outsmart you.

Define all actors, their objectives, dominant strategies and find the equilibrium?

That sounds tempting. Maybe we can make assumptions about who is likely to use the shop and what they care about. Then we can find their optimal strategies and the equilibrium state the system will naturally converge to.

That’s a very hard problem. We could try to make it easier by making more assumptions. Then again, assumptions about what real humans care about are likely to be wrong. Finally, how likely are users to not only find their optimal strategies but also follow them?

Enters Incentivai

That is exactly where Incentivai was born.

Let’s not make assumptions about what people care about and how rational they are, but rather, treat those as parameters.

Let’s have human-like ML agents find optimal strategies given what they care about as we explore the space of all the possible ways we can be wrong in our assumptions.

Let’s take a step back, look at how the system operates as a whole and see if we are happy with how robust it is.

Bonus

Wait! I thought Incentivai was about smart contracts and so far in this article you didn’t mentioned blockchain once! one might say.

Of course, they would be wrong. I mentioned blockchain several times.

But yes, design of economic incentives applies to self-executable systems that are decentralised to a varying degree. If your Uber for X startup launches a new referral scheme to acquire new customers, why run 1000 A/B tests if you can run just the top 10 most promising ones according to simulation results?

There is no free lunch, however. It’s not easy to throw a 7-layer deep neural net at the hardest problem out there and, just like that, get it to work quickly. Not to mention generalise to all other, simpler problems.

Blockchain is the dream world of any ML algorithm. Everything is structured, everything is a number. No wonder computers have been beating us at chess for decades yet would still be nowhere near able to comprehend why this photo is funny.

We know where to start and we know where we’re headed.

If you got this far and at any point thought to yourself well this is pretty cool, I guess I could see myself working on this sort of thing maybe, find out more and I’d love to hear from you.

Tokenised ecosystems (e.g. curation markets) require effective mechanisms for distribution of their native tokens. Bonding curves are a promising continuous token model where early adoption is incentivised and price is adjusted based on current supply.

It is however extremely difficult to reason about the likely user behaviour resulting from a particular bonding curve setup. We believe that modelling and simulating the system can provide invaluable insights and guide the design process.

1. Introduction

This report discusses the results of testing a Bonding Curve setup using the Incentivai simulation tool. The purpose of the analysis is to observe the behaviour of greedy Machine Learning agents to identify behaviour patterns likely to occur once the system is deployed to real users.

This introductory analysis focuses on the behaviour of greedy speculators (users seeking profit rather than purchasing asset tokens for their functionality) and the overall characteristics of the system. Follow-up analysis should include and not be limited to:

• model for utility of the asset token (usage and potential intrinsic value)
• prevalence and characteristics of possible front-running attacks
• alternative characteristics and parametrisation of the bonding curve
• embedding the bonding curve simulation as a component of the large system being designed

The plan of this report is as follows. The next section summarises key findings and conclusions. Sections 3 and 4 introduce main concepts behind token bonding curve and the Incentivai simulation setup, respectively. Experimentation results are discussed in section 5 with a focus on agent strategies in section 6. Finally, visualisations of 5 simulation runs are included in the Appendix.

2. Key findings

• Asset token price consistently reaches and oscillates around the value of 50,000 (given the bonding curve setup and assumed users’ budget)
• Asset token price is more volatile when its initial distribution is uneven

3. Bonding curve

Bonding curve is a token pricing model where the buy price, tp, is determined by the current supply, tc, of the new token (source). The new token is referred to as asset token and its price is relative to the reference token which is assumed to be the means of exchange. In this analysis, the curve follows equation:

Therefore, the cost of purchasing volume v tokens can be determined as the relevant area under the bonding curve from equation:

Speculators may take advantage of the system by buying into the asset token, waiting for others to follow and exiting their position. This attack is sometimes referred to as pump and dump since speculators attempt to artificially increase the token price which drops substantially as soon as they sell back.

Sections 5 and 6 analyse this kind of behaviour in more detail. The main consideration is to find the right time to exit when token price is unlikely to inflate any further.

4. Simulation setup

The bonding curve system is represented as an environment where ML agents can observe its current state and possible actions: no action (skip) or buying/selling tokens subject to their budget constraints. Agents estimate which action is the most beneficial to them based on their objective which in the greedy case is to accumulate as much wealth as possible (be it in asset or reference tokens).

The simulation setup allows for observing the behaviour of the system as a whole and, in particular, the evolution of asset token price with time. Additionally, the Incentivai tool gives insights into strategies considered by agents by looking at their confidence in choice of optimal action and other actions that have been considered (see section 6).

Simulation assumes two types of users taking part:

• Agents who follow simple heuristics and form the background for the analysis. They are willing to buy into the system but are constraint by their budget and unlikely to take on significant risks.
• Machine Learning agents who make decisions based on the current state of the market and their estimate of what is likely to happen in the future. They are willing to take on risks and speculate as long as the estimated consequences of their actions are beneficial to them.

5. Results

Quadratic curve is an aggressive pricing model where a lot can be gained by speculators who manage to buy in with significant volume at a low price and then sell at the right time. Scenarios A and B show different simulation realisations of the same initial setup.

What one can observe is that the behaviour of users who are the first ones to participate in the bonding curve scheme has a big influence on subsequent system performance. In particular, uneven token distribution makes the token price more volatile. The asset token price moves around a similar equilibrium (50,000) yet with a larger amplitude.

5.1 Scenario A

Figure 2 presents scenario A where one user (agent 18) manages to buy 100 tokens early on. The blue curve represents asset token price changing over time. Important events (high-volume transactions of volume 30 or above) are marked on the chart.

In the scenario above, agent 18 manages to take control of large proportion of tokens early on. This results in the token price being very volatile since the agent is able to single-handedly cause large price movements.

Agent 18 sells most of their asset tokens early on and then decides to enter another large position (volume 50). Once token price inflates further, they are able to exit and finally sell most of the rest of their tokens later (volume 60). Each of these high-volume transactions significantly moves the price.

• Sell 70 in timestep 101
• Buy 50 in timestep 137 and sell 60 in timestep 240
• Sell 60 in timestep 347

As a result of this uneven asset token distribution, its price moves significantly up and down the 50,000 value reaching maximum around 70,000 and dropping to as low as 30,000.

5.2 Scenario B

In scenario B (figure 3), 5 different users buy in early on which results in a more even distribution of the asset token.

It is still possible to observe similar enter-exit schemes performed by individual agents. They are however of lower magnitude and spread among different users rather than dominated by one:

• Agent 19: Buy 30 in timestep 6 and sell 30 in timestep 46
• Agent 16: Buy 30 in timestep 333 and sell 30 in timestep 340

As a result, asset token price is less volatile when oscillating around the value of 50,000.

6. Analysis of agents’ strategies

The Incentivai simulation tool uses custom code thanks to which it is white box. It is possible, to some extent, to unpack and understand decisions taken by agents. They approximate their optimal strategy based on what is likely to follow in the future before they choose what to do now. This gives insights into why an agent decided to take a particular action.

6.1 Scenario A

In scenario A (figure 2) timestep 101, agent 18 decides to sell 70 out of their 100 asset tokens. The table below gives insights into that decision by showing the top 3 short-term strategies considered by the agent. As an example, strategy I would involve selling 70 asset tokens immediately and 30 at the next occasion (subject to agent’s trading frequency).

All three top strategies involved selling almost all tokens very soon. Interestingly, strategies II and III suggested holding off, presumably in the hope that other users would purchase tokens and increase the price in the meantime. Agent estimated that the risk involved would be too high and chose to sell 70 asset tokens immediately.

6.2 Scenario B

In scenario B (figure 3) agent 16 buys 40 asset tokens early on (timestep 4) and does not make a high-volume sell until timestep 199. We can analyse decisions made along the way that have led to holding rather than selling early.

At timestep 7, the price has already reached 36, 100 but agent’s estimates suggest that it is likely to go further up. In fact, the optimal strategy they have found is to buy 5 more asset tokens with the plan to hold and sell 40 later.

At timestep 86 when the price has gone up further still, agent’s decision is still to hold but there is less confidence around it.

Finally, at timestep 199 when price has crossed the 55,000 mark, selling immediately becomes the estimated most beneficial action to take.

Conclusions

Modelling and simulation with ML agents allows for estimating the likely behaviour of users interacting with the bonding curve system. Greedy agents where found to buy tokens and exit when the price was estimated as unlikely to increase further. This resulted in price volatility which was particularly high when token distribution among users was uneven.

Appendix

If you found that analysis interesting, please follow Incentivai or visit the website to learn more. If you and your team would like to use the Incentivai simulation tool for your analysis, please reach out.

Acknowledgments

I would like to take this opportunity to thank Trent McConaghy, Dimitri De Jonghe & Fang Gong from the Ocean Protocol team for their input and support. Also, I found the insights and resources on bonding curve models published by Simon de la Rouviere invaluable.

Please read the Incentivai legal disclaimer

Bonding curve simulation using Incentivai was originally published in Incentivai on Medium, where people are continuing the conversation by highlighting and responding to this story.

e^👁🥧 on Twitter

Going to create a site where the public can rate the core truth of any article & track the credibility score over time of each journalist, editor & publication. Thinking of calling it Pravda ...

How do you design such a system? How do you reward and penalise users such that their dominant strategy is to be honest, reliable, unbiased and hard-working? It’s all about the incentives.

We might also want to decentralise our system such that nobody owns it, or rather, everyone owns it. Enter blockchain and smart contracts. News curation is just one application among many: DAOs, insurance, prediction markets, lending, storage, compute power and many more…

Getting the incentives right is all about mechanism design. Mechanism design is hard.

If there is no free lunch in machine learning, in mechanism design there is nothing to eat at all.

At Incentivai, we build a tool for testing the incentive structure of your system. We simulate your environment and observe the behaviour and failure modes identified by ML agents. One way to look at it is that the agents approach your smart contract system the way AlphaZero approaches chess.

See our case study, the first two blog posts and the concept paper to learn more.

Why Machine Learning?

The use of Machine Learning agents in simulations is critical for several reasons:

• agent behaviour is real-world-like
• agents are capable of identifying new failure modes
• agent behaviour quantifies the importance of failure modes

Will they offer bribes? Will they accept bribes?

The recently published analysis looked at the Nexus Mutual system (decentralised alternative to insurance). One of the key failure modes is the possibility of submitting false insurance claims and offerring bribes to users who vote to accept them.

While it is obvious that such an attack exists in theory, it is crucial to simulate and check under what circumstances it is more prevalent and how to tune system parameters to mitigate it.

For the attack to be a real threat, there need to be both users who find it beneficial to offer a bribe and those who are willing to accept it. During simulations, Machine Learning agents make decisions that are most likely to be beneficial for them.

One way to discourage users from accepting bribes is to increase the amount they put at stake when voting. They would only accept a bribe if they strongly believe others will vote the same way, otherwise the risk is too high.

In the graph above we can see that increasing the bond size to a relative value of 30, reduces bribe acceptance rates across all scenarios to around 20%.

The human factor

The users of your system will eventually be real people, so modelling the human factor is essential.

Taking insurance as an example, it is particularly important to go beyond modelling humans as rational profit-maximising agents. They need to be assumed to be risk averse (continuous low cost preferred to one-time large losses in spite of higher expected long-term return on the latter).

In order to make the system robust, it cannot assume a certain risk profile. Your design must not be too sensitive to any particular assumption made but rather perform well across a wide range of scenarios.

The graph above is equivalent to the one shown earlier except it assumes that users are less risk averse. Even though, as expected, they purchase fewer insurance covers (50–100 as opposed to 200–250), their willingness to accept bribes follows a similar pattern. This shows that decreasing the bond size is a robust measure against bribing schemes.

Conclusion

Reasoning about interactions in complex systems and designing incentive structures is hard. However, getting them right is a crucial prerequisite for widespread user adoption.

Running simulations of your system prior to deployment allows for iterative improvement of your design. Machine Learning agents make simulation results more insightful and real-world-like.

Agents make decisions that are best for them the way humans do. That way they are capable of identifying and quantifying various failure modes.

If you and your team would like to use Incentivai to test the incentive structure of your system, please reach out or check us on Twitter.

Please read the Incentivai legal disclaimer

Modelling incentives: importance of ML-based approach and the human factor was originally published in Incentivai on Medium, where people are continuing the conversation by highlighting and responding to this story.