I think we should focus on adoption (i.e. marketing). More ERN in circulation would mitigate the problem. Less price swings and more volume bringing in more 3rd party bots all working together keeping ERN closer to peg. Less people get redeemed. Problem solved
1 Like
1- My question was exactly the opposite when we started: why not do it ourselves and make profit? if others can do it more efficiently and wants to make money, they can compete for the most efficient bot.
2- I wouldnât care much about this, I donât expect bot profit to be too relevant, it is more about keeping price closer to 1 usd than making profits (imo). About the % I would say mace (in order to be incentivized to make the bot efficient and active and us / bOath / foundation
Hello everyone! I really appreciate everyoneâs feedback. I have revised the proposal based on the feedback and think it is more in line with what the ecosystem/foundation need, and also clarifies some parts as well.
Proposal Title: Ethos Reserve Redemption Monitoring System & Bot Proposal
Chain: Optimism
Type: Token Grant Proposal
Author: MacePapa
Date: 1/31/2024
Executive Summary
This proposal will outline the objectives and budget behind building an Ethos Reserve monitoring system for redemptions and a bot that will execute redemptions. This bot and monitoring system will aid in keeping the protocol healthy and an open source baseline bot that anyone can use and build on top of to try to compete for redemptions. Overall the goal of this proposal is to build infrastructure to keep the Ethos System healthy and aid keeping ERN around $1.00. The major changes between this new proposal and the original is the narrowing of scope, decreased overall ask, and focus on an MIT licensed, highly documented, set of software that can easily be used and improved by others who are interested in running their own redemption bot.
Proposal Motivation
As a long-time Byte Mason product user, I want to help contribute to the ecosystem and provide access to data and tools to aid in product system health, dApp transparency, and build an automated system to redeem troves based on ERN health.
Team Experience
This is a one-person team so the development budget can stay lean. MacePapa, the author of this proposal, will complete all development work and maintenance. I am a Full Stack Software Engineer who has been working in the blockchain space doing development for two and a half years. I have worked in a variety of projects across the space, mostly working on the Fantom blockchain. I also spent a short time as a Byte Masons team member as a Full Stack Software Engineer.
Key Objectives & Success Metrics Key Objectives
Successful Development and deployment of:
- Backend Monitoring Service
- Smart Contracts/Backend Integration
Success Metrics
Backend Monitoring Service
a. Successfully pull redemption fee metrics/analytics from chain data
b. Successfully pull redemption hints from available chain data
c. Successfully monitor on-chain events and trove MCR to identify viable redemption scenarios
e. Successfully pull collateral and ern price data from on-chain oracles/TWAP
Smart Contracts/Backend Integration
a. Monitoring service successfully identifies redemption scenario and passes helper variables to smart contract
b. Successfully deploy smart contracts to carry out redemption of ERN for collateral
Length of Engagement & Budget Breakdown
Development Time Summary Estimation
Development - 2 months
Backend Monitoring System
Smart Contracts
Audits, Reviews, Testing - 1 month
Integration - 1 week
Total - 3.25 months
Budget Considerations
Total Project Development Costs - 180,000 OATH
- 1st distribution on delivery of backend and relevant documentation - 90k OATH
- 2nd distribution on delivery of contracts and relevant documentation - 90k OATH
Community Support
N/A
Partnerships
N/A
Risk Assessment
The main risk of this project is to the owner of the funds that the redemption/liquidation bot uses. Failed attempts at liquidation could cause the bot to lose money in a transaction, and redemptions can sometimes be a net loss after the transaction is complete. Because of this, the main risk, even in the case of a smart contract vulnerability and/or failure, or downtime in the monitoring system, results in no loss of funds to the greater public.
Additional Details
N/A
1 Like
- BS currently donât have spare man power to do it, at least in the short term, and the uneasing feeling about being redeemed is raising greatly inside the community.
- Itâs more than a psychological âtrickâ than a real source of profit, users will feel more care and protected, instead of feeling scare of being redeemed as it is right now.
1 Like
about manpower: that is exactly why I support an external source like @MacePapa doing the job. he is not part of the team and can do the job
about being redeemed: it is part of the system to be redeemed in order to keep ERN close to the soft peg range. if you dont want to be redeemed you should be safer and safer. if you think that you should have an option to never redeemed against, that has nothing to do with redeeming bot, it has to do with a change on how the protocol works and may be something for a chapter or so.
Ps: sorry for the double deleting, forum got a bit buggy on my end
1 Like
Nice one Mace,
Happy with the scope refinement and articulation of compensation.
Iâd be happy to review with GPRC and will take on any additional feedback that comes to the forum.
3 Likes
Ready for review by the GPRC.
Looking good, sorry for the delay Mace!
Ready for GPRC review.
1 Like
ready for GPRC review
1 Like