While launching the $GURU token, it is important for us at DexGuru to maintain the community values that brought us to web3. This begins by ensuring that we, as a DAO, are building in public and not in private. The $GURU token is the first major project of GuruDAO and should be a function of our values and act as the glue that ties the community together. Without consensus around token structure and distribution, DexGuru can’t reach its full potential. Keeping this in mind, this document outlines the first steps towards the $GURU token.
The $GURU token will be built using the ERC20 token standard on Ethereum. As the core token of the DexGuru platform, it will initially act as a governance token. Meaning, that $GURU token holders are granted voting rights in the maintenance and evolution of the project. As discussed in GuruDAO documentation, DexGuru will evolve with time and so will the $GURU token. Later on, the $GURU token could double as a utility token, subscription pass and more. Sky is the limit and it is GuruDAO deccsions that controls token supply and demand. As for token structure, the maximum supply of $GURU is capped at 100,000,000 and can not be changed under any circumstances.
In DAO Bootstrap Phase, we will have to decide how to distribute 60% of community-owned tokens. We can expect 1-5% of tokens allocated for early community participants’ rewards, 20-30% allocated for LBP, and the rest set for vesting into GuruDAO treasure. It is up to DAO to decide exact allocations prior TGE.
DAO can not change existing investors, team allocations, and vesting schedules. 40% of GURU tokens allocated with two years vesting with six months cliff following TGE. None of the team or investors will have liquid tokens at the token launch day.
It is important to note that at any given moment the GuruDAO will control more voting power than the team and VCs combined. This is essential to the maintenance of GuruDAO as voting power is distributed to lean towards the community. In the unfortunate event that there is a disagreement between $GURU holders, the community DAO will have the largest say in the final outcome of the dispute.
DexGuru isn’t traditional Saas, and $GURU token isn’t a traditional protocol governance token. Instead, we want to build first of a kind, genuinely community-owned Product DAO that would develop and deliver great tools for modern web3 traders.
Traditional Saas business cash flow comes from monthly recurring subscriptions that fuel product development and marketing spending. What if we can replace recurring subscriptions with ve-Tokenomic flywheel and DAO-owned liquidity?
ve-Tokenomic model allows us to create a long-term alignment between token holders, community, DAO, and the product. The core component of any good tokenomic is a balance between token supply(sell pressure) and token demand (buy pressure). DAO governed with vote escrowed token and controlling own liquidity can achieve perfect balance between supply and demand.
Subscription-based monetization for DexGuru product always was a part of the plan. This is how it will work with DAO and ve-tokenomic. When users purchase paid subscription plan for DexGuru analytics platform, under the hood smart contract purchases $GURU from the $GURU/$ETH pool, and transfer $GURU tokens to a vested time lock safebox in exchange for platform access. This creates constant and predictable cashflow for GuruDAO and $veGURU tokenholders. DAO controls how vesting safebox splits the profits from DexGuru between DAO treasury and $veGURU tokenholders who earn a share of the revenue that the platform pays out.
This system is showcased in the graphic below.
Participating in GuruDAO governance requires that an account have a balance of vote-escrowed GURU (veGURU). veGURU is a non-transferable ERC20 implementation, used to determine each account’s voting power. $veGURU is a token that is issued upon the locking of $GURU tokens in vote escrow smart contract. The amount of $veGURU received in exchange for $GURU tokens is dependent on the lock period. The longer $GURU tokens are locked for, the more $veGURU received in exchange. A user’s veGURU balance decays linearly as the remaining time until the GURU unlock decreases. For example, a balance of 4000 GURU locked for one year provides the same amount of veGURU as 2000 GURU locked for two years, or 1000 GURU locked for four years. The voting power is equal to the amount of veGURU on a user’s balance.
Instead of the team deploying smart contracts, we want to let our community do it. The exact mechanism is TBD now, but we are looking at Gearbox Protocol DAO-first launch as a good example.
A big decision has to be made regarding the DAO Treasury. As a community, GuruDAO needs a treasury to manage and step one is ensuring that it gets filled. There are a few options when it comes to bootstrapping token liquidity but a recent poll by 0xMaki shows the web3 community prefers Balancer LBP (Liquidity Bootstrap Pool) as the most fair, effective & best usability for participants.
With a Balancer LBP, the pool is able to dynamically change the weighting of the token pair over a certain period of time. With the majority of pools requiring a 50/50 split from token A/B, the dynamic Balancer LBP has advantages. The first being that the sell pressure from the change in weighting creates a generally agreed upon market price. On top of that, since the LBP starts with a high price, it disincentivizes bots and whales from snatching up all the liquidity from the beginning. Finally, the starting capital can be small, saving upfront costs.
In order to set up a LBP launch, GuruDAO needs to set the details and parameters:
Minimum purchase amount:
Initial pooled: ____ GURU : _____ WETH
Starting weights: GURU 95%: WETH 5%
Ending weights: GURU 50%: WETH 50%
100% of funds raised during the LBP will be set aside and DAO governed. Using protocol owned liquidity, GuruDAO will be able to build liquidity on-chain using the native token, $GURU. The DAO also earns trading fees from this liquidity pool that benefits the DAO and token holders.
GuruDAO treasury is 100% on-chain and community governed. Using the SafeSnap module from Gnosis, off-chain votes can be handled and processed for on-chain execution. For vote collection and verification, Snapshot is used by the DAO while the funds are stored in a Gnosis safe. As a safeguard, multi-sig is set up so that the owners are able to veto malicious actions and have power in the case of an emergency.
Some of the leading projects using the SafeSnap module are: Yearn, SushiSwap, Synthetix, Balancer, mStable and many others. For a further breakdown of SafeSnap, check out the documentation from Gnosis.
Here is a non-final list of proposals we have to discuss and decide on:
- Exact token allocation and distribution schedule for 60% of token supply earmarked for GuruDAO
- LBP details and parameters
- Who will be on a safeguard multisig
- GuruDAO governance quorum and proposal threshold for veGURU.
- Initial product’s subscription parameters
- Deploy $GURU token smart contract
- Deploy LBP