MetaGame Funding

Novel funding mechanism are coming - Let’s play with them!

Collateralized Smart-Contract with automatic market-makers governed by token-bonding curves IS the next big next thing our ecosystem! Why? Because they align collective and individual incentives! Yes, they provide funds to purpose-driven communities while allow investors and speculators to profit from price variation of a token/share.

Really!? Are this ready to be use by MetaGame?

Well, this depends do you ask… If you check The Commons Stack (CS), you will see they are putting a lot of efforts in developing and deploying the right design tools like cadCAD so the right curve would be designed for the right people.

See in this demo how that would work -->

(you can also go to and play yourself with the JS simulator)

But these are still in a Design phase, and still need further R&D to see these operating in a smartcontract.


Aragon has developed already the so-called fundraising app (still in beta) that already allows this kind of fundraising with an usability that in my view, still has some room for improvement. Anyhow, if deployed well, and with a proper community behind us, this could grand continuous funding coming into the MetaGame.

For deep insights about how the fundraising, best thing is to check this guide.

Be aware! The Augmented-Bonding-Curve described in the demo above from CS has a complete design paradigm than the Aragon fundraising app, which curve is governed by the Bancor formula, and which a governance-funding model pretty close to what Vitalik described a couple of years ago as a DAICO.

This is so cool! Let’s do it Now!

STOP!!! :no_entry:

Just a second! We need to unerstand that this is super experimental! and that indeed we could harm some people here! I mean, people that would like to invest in the MetaGame DAICO (crap! I’m just naming the thing :sweat_smile:) will contribute to the project, and will have the opportunity to profit out of that, even if MetaGame won’t deliver value (of course we’ll do tho), just by the dynamics we set on the bonding curve… If you check how a bonding curve works, you will realize that price of the token increases automatically by the primary market governed by the curve/smart-contract, but at the same time, the price decreases when people sell… So if you are a newcomer arriving in a late state, you are risking that people that bought the token at a lower rate will sell now, making you lost valuation in your token… Of course, if your motivation is to fund the project and participate in the governance of the funds to be used by the community (with the limitations set by the Aragon FR App, of course), you wouldn’t care that much if the price decreases, maybe you see that as an opportunity to buy more tokens, contribute more to the MetaGame continuos funding and gain governance over the funds there.

Nice Let’s Do This!! :love_you_gesture: :love_you_gesture:

First on Rinkeby please!!

So… I would start by deploying a RinkebyDAO myself and transfer Council tokens to those already signed in the MetaGame Mainnet Aragon DAO, setting the curve parameters, launch the funding phase and play arround with some testnet fake DAIs… but I won’t, I have already done this for another community, and I think it’s important that other people pass throught the process in deploying this DAO. Also, I would wait for comments from the rest of the community about this an hope that a true MetaGame leader (I’m just a wannabe here :joy:) make a step forward and deploy the DAO without asking permissions to anybody, but with the enought coodination to avoid we will have 5 DAOs lol…

Here below, I’m just sharing the whole DAO deployer experience so you would have an idea about what to expect…

Deployment Process

After you select the Fundraising template and give a name claiming an ENS domain to you Aragon DAO. The D-App allows you to set up configuration for three key points:

  • Define Council Members: project team to be funded by the project campaign.
  • Define Governance Token: It holds most of the governance rights over the organization, it’s minted and burned according to their funds contributions or retrieval.
  • Configure Fundraising features husohdosd

Define Council Members

The Council is describes as follows:

Yoy can then configure council members and its token (multi-sig rights and features) as:

Define Governance Token

The emission of this token is ruled by a Token-Bonding Curve that will be defined in the following step (Fundraising Features).
The token holder definition and vapabiliries are the following:

Configure Fundraising features

There are two main phases for the fundraising:

  • A pre-seed phase with a constant price, token holders can only buy tokens from the Aragon Smart Contract.
  • A seed phase with a Token price ruled by the bonding curve we are configuring here. In this phase people can buy and sell Tokens against the smart contract.

Presale Terms

Initial tokens offered % describes the percentage of the initial SOT token supply that will be offered during the presale. The remainder of this supply will be minted and sent to the council if the presale succeeds.
Project funding % describes the percentage of DAI raised during the presale that will be sent to the council (to bootstrap the campaign’s underlying project) if the presale succeeds. The remainder of the raised DAI will be sent to the automated market maker’s reserve pool to support trading of $SOT.

Contribution Terms

Cliff period describes the length of time required before any SOT tokens purchased during the presale become transferable.

Vesting schedule describes the length of time required for all SOT tokens purchased during the presale to become transferable. For example: 120 days.

Operation Terms

Tap rate defines the amount of DAI which can be released every month from the market-maker’s reserve pool to the council-controlled vault. For example: 3000 DAI / month. This is the flow of funds that will actually support the campaign’s underlying project.

Tap floor defines the amount of DAI which will be kept in the market-maker’s reserve pool regardless of the tap rate. For example: 5000 DAI. This ensures that the market-maker’s reserve pool can’t be emptied - and thus that the SOT price can’t fall down all the way to zero - even if over a long period of time.

Maximum monthly tap rate increases and tap floor decreases defines how fast you can increase the tap rate and decrease the tap floor each month. For example: 50%. This protects holders by controlling how quickly the flow of funds from the market-maker’s reserve pool to the council-controlled vault can evolve.

Trading Terms

Initial price per SOT will be the price in DAI for each SOT token when trading initially opens. Afterwards, the price will automatically adjust according to the market.

Expected growth is the expected long-term market capitalization growth of SOT. We use this value to set the parameterization of SOT’s bonding curve such that the token’s price will be 10x its initial trading price once its reached this capitalization. Setting a high expected growth will cause the bonding curve attached to SOT to be more sensitive to volatility.

Market Making Terms

This is and advance set up for protecting against Front-running which is an attack where a malicious node observes a transaction after it is broadcast but before it is finalized, and attempts to have its own transaction confirmed before or instead of the observed transaction.

Batch length defines the number of blocks a trading batch will last. For example: 2 blocks. All orders opened during a given batch will be matched at the exact same price (though this price may be different for buy and sell orders). This prevents front-running attacks and enables slow trading.

DAI slippage % defines the maximum price slippage in DAI that may occur on orders during any given batch. For example, with a value of 25%, this would mean that:

  • The price of any buy orders in a batch can’t rise above 125% of the batch’s opening price
  • The price of any sell orders price in a batch can’t fall below 75% of the batch’s opening price.

Any order that would break these limits will automatically be dismissed.

ANT slippage % defines the maximum price slippage in ANT that may occur on orders during any given batch. For example, with a value of 25%, this would mean that:

  • The price of any buy orders in a batch can’t rise above 125% of the batch’s opening price
  • The price of any sell orders price in a batch can’t fall below 75% of the batch’s opening price.

Any order that would break these limits will automatically be dismissed.

And that’s it… Who wanna play???


Sounds damn awesome. Thanks for the extensive explanation. Kinda thinking about trying to get something like that running on a testnet at ETHLondon next weekend.

@Gus thanks for putting this together :slight_smile:

FTR, if anyone is concerned about immediate effects of open markets on a community’s sentiments or incentives you can open the bonding curve with a pre-sale and hten create a vesting schedule for token holders. That way people can support the community, but tokens are only trade-able after a certain window of time.

1 Like

Hey christofon, I’ll also be going to EthLondon. Hit me up on Telegram @jadbox

1 Like

This not a completely accurate statement. The Augmented bonding curve is designed using a mathematical model for bonding curves which has an equivalence class with what is commonly called the “Bancor Equation”. Bancor uses fixed reserve ratio to determine bonding curve “curvature”. Normally when projects use the Bancor equation they choose a particular coef. in place of this parameter, that choice uniquely defines the kappa parameter in the bonding curve as applied (and augmented) in the ABC .

The actual difference between the DAICO and the ABC, is when and where funds are syphoned away from the reserve and into a funding pool. In a DAICO this happens via a tap mechanism, but in the ABC this happens when you withdraw. However, the underlying bonding curve mechanism has the same underlying invariant principles.

For more on the ABC variant, see:

It wouldn’t be a huge leap to describe the DAICO in the same way.

Honestly, the most natural thing would be to extend the existing DAICO code to include BOTH parameters for capturing funds on the inbound (bond-to-mint) and the outbound (burn-to-withdraw) mechanisms. That would create a class of funding bonding curves which could include the existing Aragon fundraising model and the Commons Stack one. (I’ll reserve for the moment the formal justification for why I think capturing outbound funds is more sustainable long term~ think strategic asymmetry.)


Thanks for the correction Z!

hey Chris! did the experiment in ETHlondon? tell us about it!!!