Everything you wanted to know about Flowertokens but were afraid to ask — Part 4: Blooming- and Infrastructure Pools
This post serves as a explanation of the underlying smart contracts and the economic system behind the Flowertokens experiment, a discussion of its flaws, as well as what we learned from the process of designing and implementing it. If you aren’t familiar with the project, you can get familiar here.
When designing the economic system surrounding the ER721 tokens, we thought about ways for users to earn their initial investment back; an idea strongly grounded in our belief in regenerative ecology. In the long term we want to dive more into schemes whereby the natural system can generate a return through ecosystem ‘services’ (for example C02 certificates) and pay the user back (at least partially). However, since the experiment takes place on a small scale and the system is not locally bound to other ecological cycles, where would the value for the repayment be generated?
On every token trade (buying/selling a Flowertoken) we charge a 10% fee. Half of this fee (i.e. 5% of the total transaction amount) is used to cover the running costs via being fed to our infrastructurePool contract (https://etherscan.io/). The other half of this fee is fed into the Blooming Pool.
The Blooming Pool is a contract which will, over the course of the project, pay certain token holders based on the current state of their flower. Once a week the Oracle checks if a flower is blooming (through PlantCV). If a flower is recognized as blooming, the Oracle will call a function of the contract and generate a share which is owned by the owner of the corresponding Flowertoken. Once the share is generated it can be withdrawn by its owner for a equal portion of the current pool. The total number of shares is always dependent on how many people withdraw: withdrawing (which destroys your share) therefore makes the most sense when the pool has a high volume and doesn’t contain that many shares besides yours.
Lets have a look in how user could value their flower with the help of the Blooming Pool:
The way users determine the value of their flower is subjective — but in the best case based on the information of the Oracle (such as growth rate, height) and information which can only be obtained by viewing the livestream. The information not provided by the Oracle could be:
- What does the shape of the flower look like?
- Does it look healthy?
- Colour / Leaves etc
With this information, the user could calculate how high the chance of their flower is to bloom before other flowers.
Lets say for example the user expects their flower to bloom third: the Oracle might generate 3 shares at the beginning of the first week. The current value of the Blooming Pool is around 0.5 Ether. That means when the user withdraws they will get a 0.16 Ether payout. Lets say in the second week the Blooming Pool contains 9 Shares and holds 0.4 Ether: the payout would be 0.04 Ether per share.
This system might help users to calculate how much their flower is worth (aside from using the three examples given above) and how much they can expect as a return from the system.
All Code related to the smart contracts can be found here:
https://github.com/terra0project/source/tree/min_dapp/ERC721
EDIT: The contract is now also verified on etherscan so all functions can be called from there.
https://etherscan.io/address/0x43c9b7b7ce699ac2c1d3aad3b5a78274a0f9c86d
