In addition to the Tribe Turbo Launch Group post and discussion, this post starts the discussion around further analysis of Tribe Turbo with Gauntlet and a high level budget request.
Gauntlet is a simulation platform for on-chain risk management and parameter optimization. Gauntlet platform works with protocols to mitigate risk, optimize fees, calibrate incentives, and improve capital efficiency.
Tribe Turbo is the evolution of lending and credit in DeFi. It allows any market participant to issue FEI at zero cost and direct it to where the lending liquidity is needed most, and share revenues with the Tribe DAO and participating DAO.
Gauntlet can build and deploy a financial model focusing on continuous risk management and automating parameter controls for Tribe Turbo, to optimize the use and deployment and mitigate risk to the Tribe DAO.
One of the biggest concerns from a financial perspective is the risk that the FEI will be borrowed and sold (redeemed for PCV). Since the assets that collateralize the position are not owned by the Tribe DAO, it is essential that subject matter experts assist with risk management and the underwriting process.
Gauntlet engages similarly with Compound and other well-known protocols.
Gauntlet is proposing:
Minimal contract value of $1M (denominated in USD) for 1-year engagement.
Minimum commitment of 12 months
50% of each quarterly payment to be transferred with a 6-month linear vest
50% of each quarterly payment to be transferred with no vesting period
Service fee of 12.125% of revenue generated from Gauntlet parameterized strategies
Suggestions:
We should agree to a minimum contract value number and/or a service fee based model, not both. The service fee should also be based on profits, not revenue, as profits could be lower, and this could lead to the Tribe DAO actually losing money.
Gauntlet is running their simulations with agent-based models representing users interacting with a protocol. A model of a user is based on a set of theoretical assumptions about user behaviour patterns. This approach was developed for TradFi, where the bulk of real life data is either not digitised at all (much of the b2c interaction happens offline) or isnât available (much of market data is private). Hence, agent-based modelling with theoretical assumptions about incomplete data is justifiable. However, for DeFi agent-based modelling is a suboptimal legacy framework. Since all data about transactions and user interactions with the protocol is open and available for modelling, we can learn from real life data a model of a living protocol, or parts of it, and models of user interactions with it. Moreover, this model will be continuously fine-tuned with new data emerging.
Transactions model is only half of the story. The other half is community sentiment manifested on twitter, discord and discourse. In the offline economy inflation expectations and consumer sentiment influence consumer behaviour and central banks of the world gauge it with polls, when modelling national economies. In DeFi we have the luxury to model community sentiment not with approximating polls, but again with real life data, while constantly fine-tuning the model.
It might be ok as a temporary solution for the MVP, but would be suboptimal in the serious run.
Maybe as part of the modelling, simulation and risk management program.
Didnât they accidentally liquidate a bunch of Enjin depositors on Aave recently?
Looking at their work on other protocols, they appear to show up with opaque numbers that say âraise leverageâ and then claim they are owed lots of money.
Their dashboards are also sparse compared to protocols with internal risk.
Would they commit to showing how they arrive at their numbers?
Would they reimburse on the downside or only collect money on revenues?
I know they will chime in saying they are âquantitativeâ but they never show their work and just say to trust them. They say they are mitigating long tail risk, but they only use data from 1 year and go out to only two standard deviations assuming a normal distribution on volatility. That still means 5% chance of being wrong. That is not protecting against long tail risk at all.
For their price, just hire professionals. At least put out a call for proposals and get competing bids.
At a high level, ABS allows a set of âagentsâ (pieces of code meant to mimic actual user behavior) to make rational actions against DeFi protocols according to some âwhat-ifâ market scenario.
How close this mimicked user behaviour to actual user behaviour?
Each agent acts according to a set of rules to carry out rational (profit-maximizing) actions.
Thatâs basically XIX century economics. Nobel Prizes have already been given out for debunking the pure rational choice theory:
Theyâre using VaR as a risk measure. In fact, itâs outdated and being phased out in financial stress-test simulations due to its inability to capture tail risk in favour of Expected Shortfall.
Just to give some perspective here is a quote from âA revised market risk frameworkâ published by the Basel Committee on Banking Supervision (kinda regulation/overseeing body for wordâs central banks):
Move from Value-at-Risk (VaR) to Expected Shortfall (ES): A number of weaknesses have been identified with using VaR for determining regulatory capital requirements, including its inability to capture âtail riskâ. For this reason, the Committee proposed in May 2012 to replace VaR with ES. ES measures the riskiness of a position by considering both the size and the likelihood of losses above a certain confidence level. The Committee has agreed to use a 97.5% ES for the internal models-based approach and has also used that approach to calibrate capital requirements under the revised market risk standardised approach.
To me this seems insanely expensive. 12% of revenue and 1M fee? We are a DAO, why donât we just hire 2 engineers/quants for 250k/piece and bring this in-house under the Tribe umbrella? We save ~500k in fee and 12% of revenue. 12% of revenue especially, thatâs a hard No. Where am I wrong in thinking this? Itâs the same way how companies who know theyâll need recurring work-flow bring their talent under their name (dao)⌠it just makes way more sense
As Tribe DAO grows, this service will continue to be needed/iterated on, and a fee of this magnitude just seems way too high. We donât even yet know how profitable it will be (remember, revenue isnt profit)
Simply put: If this is the âmarketâ rate for this service, it seems the dominant choice is rather pay someone ($ and/or long term vested tribe) to figure out risk in-house
@Kazuya Agreed. Why would this be the smarter move over just hiring and retaining the talent ourselves? It would be far cheaper and in the long run more lucrative. 1 time off payments in huge amounts via DAO funds sounds like a disaster.
I like the idea of having more skilled people tuning the DAOâs parameters and generally knowledgeable about our products / able to understand and create DAO and pod actions, and incentives-aligned with our productâs successes, but :
With that kind of budget we could hire like 4 full-time contributors in the DAO, that seems excessive, especially when we donât know the value-add it represents.
Thought about this for another day since last post and bringing skilled ppl into the DAO full time to model risk/tune Tribe product suite seems like clearly the best play â in fact I canât even think much of a strong counterargument here given the scope of what Tribe is building. Hope we just tell Gauntlet thank you for the offer but itâs not needed currently and instead we hire a few bright minds to join the team who can meet these deliverables. I would see those hires as an investment with better aligned incentives and vision measured in years, I would see this Gauntlet offer as an ongoing recurring expense.
Storm- thank you for the kind words, and appreciate your questions. Answers below.
Revenue would be measured based on borrow interest from the Turbo/Fuse lending pools. Revenue generated from yield aggregation or stableswap liquidity provisioning is out of scope.
Our proposal supports the below parameters and SLAs. The Update SLA aims to be reactive and event-driven rather than a fixed frequency. Revenue attribution will initially be specific to Turbo/Fuse lending pools but we welcome discussions with other participating DAOs that are interested in (or have already expressed interest in) utilizing Gauntletâs services.
Parameter
Update SLA
Core Lending Model
Supply Cap
Weekly or Daily as needed
LTV
Weekly or Daily as needed
Global Parameters (support Q2)
Total FEI Supply (for boosting)
Weekly or Daily as needed
Collateral Factors
Weekly or Daily as needed
Turbo Boost Parameters (support Q2)
Boost Cap Per Strategy
Weekly or Daily as needed
Boost Cap Per Collateral
Weekly or Daily as needed
Turbo Clerk (support late Q2)
Fee % Overrides Per Safe
Weekly or Daily as needed
Fee % Overrides Per Collateral
Weekly or Daily as needed
After the 1 year service term, all payments to Gauntlet would cease under this proposal. In order to continue receiving payments, Gauntlet would have to put up a proposal to the Tribe DAO for contract renewal. Ahead of that time we will have provided a retrospective on Gauntletâs impact for the prior year with regards to risk mitigation and value creation.
While our models are not open sourced, we will provide details of our methodology so that the community can be confident in our parameter recommendations. Additionally, we will produce monthly forum posts recapping our recommendations and participate in community calls to discuss risk and parameter changes as well as any anomalies observed.
_
I also want to share an update from our end. At the time we sent this proposal to the FEI Core team we noted that we also had several other active proposals outstanding and operate on a first come, first serve basis. We do this to ensure that our resourcing aligns with providing the highest levels of service to our clients. Since that time, we have received a deposit from another protocol. With other prospective clients close to contracting it may make more sense to re-engage after protocol launch at which time weâd be excited to put forth another proposal.