TIP-133

TIPs/TIP-132.md

@@ -1,6 +1,6 @@
 | id | Title | Status | Author | Description | Discussions to | Created |
 | ----------- | ----------- | ----------- | ----------- | ----------- | ----------- | ----------- |
-| TIP-132 | Change how min_spread variable is applied on Overtime| Draft | Danijel (@danthales)| Change how min_spread variable is applied on Overtime| https://discord.gg/thales | 2023-03-06
+| TIP-132 | Change how min_spread variable is applied on Overtime| Draft | Danijel (@danthales)| Change how min_spread variable is applied on Overtime| https://discord.gg/thales | 2023-03-15
 
 
 ## Simple Summary

TIPs/TIP-133.md

@@ -0,0 +1,43 @@
+| id | Title | Status | Author | Description | Discussions to | Created |
+| ----------- | ----------- | ----------- | ----------- | ----------- | ----------- | ----------- |
+| TIP-133 | Allow centralized keepers to update odds on Overtime| Draft | Danijel (@danthales)| Allow centralized keepers to update odds on Overtime| https://discord.gg/thales | 2023-03-16
+
+
+## Simple Summary
+
+This TIP proposes to allow whitelisted keeper bots to update odds on Overtime
+
+## Abstract
+
+Due to delays and cost inefficiencies of using Chainlink Node infrastructure, I am proposing to allow whitelisted keeper addresses to perform odds updates
+
+## Motivation
+
+Overtime is currently using Chainlink nodes to create markets, update odds and resolve markets. Market creation and resolving are performed only once per market type, and thus are not a huge cost driver, however, updating odds can take place tens if not hundred of times per market, and can thus drive significant costs.  
+I estimate that we currently spend 5-10 ETH per chain to run Overtime oracle update. 
+Due to these costs, we make compromises on how frequent we ask for latest odds and have thresholds of e.g. only updating the odds when they are changed more than 5% from last written odds to contracts. As our total margin is sometimes less than 5%, this obviously isn't the perfect solution, and the goal is to keep reducing that threshold.    
+
+Additionally, each update of odds is delayed at least 15 seconds, which is the minimal time it takes a CL node to respond to a on-demand request. When multiple games need updates simultaniously and calls pile up, the delay can be much larger. This allows for potential frontrunning opportunities.   
+
+I estimate we can:  
+- Reduce our gas costs 3x-6x by moving to centralized keeper bots  
+- Expedite how frequently the odds get updated  
+- Allows bigger batches of paraller updates  
+
+In terms of centralization risks, I am only proposing using keeper bots directly for odds, and still using CL nodes for market creation and resolution. Centralizing the odds updates has no risks for end users, as they always see which odds they are getting when trading. However, it does include an additional risk for liquidity providers if those bots are compromised. Circuit breakers which we have built in mitigate this attack vector to some extent. Besides adheering to cyber security measures to protect the whitelisted wallets, Council could consider introducing an insurance fund for Liquidity Providers, or using the SafeBox for that purpose. However, at this point the proposed solution is likely a good compromise for Liquidity Providers as it ensures sharper odds and mitigates frontrunning surface. 
+
+I am a big proponent of decentralized oracles, and will still be on the lookout and how to get back to using more decentralized solutions once better tooling is available. With regards to gas costs, EIP-4844 should introduce significant L2 gas costs reduction (planned for Q3 2023), so we could revisit this decition once its live.  
+
+Additionally, tools such as Chainlink functions could provide an alternative solution, but its still early for production use of those.     
+
+## Specification 
+
+Allow whitelisted addresses to directly update odds on Overtime. 
+
+## Implementation
+
+TBD
+
+## Copyright
+
+Copyright and related rights waived via CC0.