The Power of Defaults in the Commons Configuration Dashboard

The Commons Config Dashboard is the next big product to come out of the Params Working Group. It is inspired greatly by the Hatch Config Dashboard and the Commons Simulator.

The scope is ambitious. We want to create an easy experience for the TE Commons (and other future Commons) to configure their Commons Upgrade. This will be a robust tool that encompasses configuring the Augmented Bonding Curve, Token Thaw, Disputable Conviction Voting, and Disputable Voting Aragon Apps.

There are well over 30 parameter choices that can be configured. Creating a dashboard that educates our community about the impacts of every possible choice would make for an extremely complex user experience, and would take many many months to execute. Fortunately, not all parameters are created equal. They each have a varying impact on the organizational structure, varying ripple effects on the larger system, and varying complexity. In the case of some parameters, the effect of customization is very small in comparison to the effort required to make sense of the parameter.

To reduce the scope, while still empowering our expert users to design the full Commons configuration, we will have a configurable “Advanced Area” with parameters that, in our opinion, have minimal impact, excessive complexity, or both!

The parameters in the Advanced Area of the dashboard can still be changed, and their impacts will be visible in the Commons Config Dashboard, but these impacts will not be emphasized. Why do we do that?

We have chosen, to some extent, to rely on the Power of Defaults. We do not take this decision lightly; the Default Effect is real and could be abused to influence our design in ways that contradict our intention to end the crypto technocracy. This is why we are explicitly stating this here and will have open discussions with various working groups to determine the defaults.

Commons Config Dashboard Parameters

The parameters that we will focus on ensuring the community understands and can configure:

Token Thaw

Opening Price: ___ wxDai

Token Freeze: ___ weeks

Token Thaw: ___ weeks

Augmented Bonding Curve

Commons Tribute (formerly Hatch Tribute): ___ % of Hatch Funds

Entry Tribute: ___ % of conversion

Exit Tribute: ___ % of conversion

Disputable Conviction Voting

Spending Limit (formerly Max Ratio): ___ % of Common Pool

Conviction Growth (formerly Half-life): ___ days to 50% voting power

Minimum Conviction (formerly Min Threshold): ___ % of Conviction

Disputable Voting

Support Required: ___ %

Minimum Quorum: ___ %

Vote Duration: ___ days

Delegated Voting Period: ___ days

Quiet Ending Period: ___ days

Quiet Ending Extension: ___ hours

Execution Delay: ___ days

Parameters Left Out

There is still some engineering work being done to fully map the configuration parameters for this deployment, so not all the parameters are known at the time of writing this post. For now, the parameters slated for the Advanced Area are:

Augmented Bonding Curve

Transferability: Yes/No

Token Name: Token Engineering Commons

Token Decimals: 18

Virtual Supply: ___ TEC

Virtual Balance: ___ wxDai

Disputable Conviction Voting

Minimum Effective Supply: ___ % of Total Supply

Disputable Voting and Disputable Conviction Voting

Proposal Deposit: ___ xDai

Settlement Period: ___ days

Challenge Deposit: ___ xDai



Hatchers that Ragequit: ____ wxDai

Initial Buy: _____ wxDai

TEC Minting Rate: 1 TEC/TECH

Gardens Specific Params

Common Pool Amount: 0 wxDai

Honey Token Liquidity In xDai: 100 xDai

Garden Token Liquidity: 1 TEC

Reasons for Exclusion & Proposal for who will pick the Defaults

This is the working proposal for our direction for these parameters, please comment in this post if you have any suggestions

Transferability, Token Name

  • The choices and their impacts can be easily understood and defined by social consensus in the forums so we removed them to cut scope and streamline the user experience.
  • Will be configurable in the Advanced Area.
  • Defaults decided by the Stewards.

Virtual Supply & Virtual Balance:

  • Have a very complicated impact on the ABC and should only be used in specific instances with a lot of consideration.
  • Will be configurable in the Advanced Area.
  • Defaults decided by the Commons Swarm.

Min Effective Supply

  • Edge case protection for Conviction Voting, unlikely to be important after system initialization
  • Will be configurable in the Advanced Area.
  • Default decided by the Commons Swarm.

Initital Buy into the Bonding Curve

  • It is still a work in progress, we will have to make an estimate.
  • This Parameters and its impact can be easily understood and defined by social consensus in the forums so we removed it to cut scope and streamline the user experience.
  • Will be configurable in the Advanced Area.
  • Default decided by the Stewards.

Proposal Deposit, Challenge Deposit & Settlement Period

  • Gardens is set up to have the same settings for these for both Disputable Voting and Disputable Conviction Voting.
  • Parameters and impacts can be easily understood and defined by social consensus in the forums so we removed them to cut scope and streamline the user experience.
  • Will be configurable in the Advanced Area.
  • Default decided by the Stewards, potentially adjusted at the last minute if it changes.

Permissions for changing all Parameters and general DAO functionality

  • Originally there was a plan to have multiple Disputable Voting instances, but this customization complicates launching with Gardens so, if desired, it will need to be done after the Commons Upgrade is complete with a vote.
  • With one Disputable Voting instance, the permissions that make sense for the community to choose are all the same, the one Disputable Voting instance will end up with the power to change all the relevant parameters via a vote, so there aren’t any choices to be made.
  • Other Permissions are somewhat complicated and very much only configurable by the Commons Swarm, they mostly consist of different apps having special privileges to interact with each other, like the Disputable Conviction Voting app being able to spend funds out of the Common Pool Agent app.
  • Configured by the Commons Swarm. Permissions will not be shown in the Advanced Area for simplicity.

Hatchers that Ragequit

  • This is not actually a parameter for the Commons but an assumption that must be made for the dashboard to be accurate.
  • It will have a very complicated impact on the dashboard outputs.
  • Configuring this choice should be used cautiously and before submitting it should be set back to the original default value.
  • It is important that its impacts can be easily understood and defined by social consensus in the forums so we removed it to cut scope and streamline the user experience.
  • Will be configurable in the Advanced Area.
  • Default decided by Params based on the current value and an estimate.

TEC Minting Rate & Token Decimals

  • The Hatch Minting rate was selected in the Hatch and is assumed to carry over for user experience reasons. People will send 1 wxDai to mint 1 TECH, so there is a natural expectation that 1 TECH = 1 TEC.
  • The Decimals would change this ratio as well, but in a very non-intuitive way, which is inaccessible to us because it is configured in Gardens, so no-go.
  • As the code to change will not be included in the scope of the Commons Upgrade so it will not be configurable.
  • Default decided by the Commons Swarm. Will not be shown in the Advanced Area.

Common Pool Amount, Honey Token Liquidity In xDai, Garden Token Liquidity, Existing Token Liquidity

  • The Commons Swarm is using the Gardens Template to complete the Commons Upgrade. These parameters are latent to that template and are not needed as the liquidity requirements of our project are solved by our Augmented Bonding Curve.
  • The Commons Swarm will work with the Gardens Swarm to better understand how these Parameters can be utilized by the TEC.
  • Names are still a WIP.
  • Default decided by the Commons Swarm. May not even be shown in the Advanced Area, these impacts are still being researched and it’s inclusion will be determined during the Hatch.

I don’t really think we need to vote on this like a formal proposal unless there is contention some where… This is posted here more to get feedback if anyone has any and to bring awareness to some work this week and next on picking defaults!

I’m wondering… could we offer ‘default to so and so’ on the included dashboard parameters?

That way, people can add their input for the params they have a good understanding of, and choose to relegate the params they’re uncertain of to defaults that have already been decided by the stewards or the commons swarm. We’d be encouraging the community to get educated but negating people feeling pressured to educate themselves on all params (maybe they don’t have time, or they just don’t understand that particular param).

A kind of pick and choose: educate and give your input where you can/want to, choose the default option where you want to.


Wow that is a serious concept laid-out very clearly. Another rabbit hole to explore! The ‘default effect’ is so interesting. I think most people are prone to use defaults very frequently. Probably the less serious the decision the more likely defaults get used. Reviewing these variables was good education for me. Need to ruminate on this for a while so not many comments at this point however I do think completeness is more important than clarity. So we should publish most variables on the interface.

The advanced area is sufficient to protect the items from being mistakenly operated. If something is extremely dangerous it can still be guarded with an extra click-to-confirm warning.

We want to ensure the most information gets to the most people enabling them to have the most control over their own economy. I usually speak from a position of increasing transparency and individual-control, and that is the case here too. We should build the interface to provide maximum information.

Great work on this doc Griff and I look forward to testing out the dashboard interface.


Kind of! We will start with a full design, and whenever someone makes a proposal, you can fork it and change just the 1 or 2 params that you like!

Most params are all very connected, so making a default for them would be really complicated…

1 Like

Ah, that’s a shame. But thanks for considering it as an idea :slight_smile:

1 Like

Edited to fix some units and names & add initial buy from: Should we do the initial buy into the bonding curve?

1 Like