Update TIP-133.md

TIPs/TIP-133.md

@@ -13,18 +13,18 @@ Due to delays and cost inefficiencies of using Chainlink Node infrastructure, I
 
 ## 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.  
+Overtime is currently using Chainlink nodes to create markets, update odds and resolve markets. Market creation and resolving are performed only once per market/game, 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  
+By using centralized bots for managing odds I estimate we can:  
+- Reduce our gas costs 3x-10x
 - 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. 
+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, but should an attack take place, pDAO can cancel the affected markets thus not allowing attackers to take profit. 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.