🔮The Oracle Network
Oracle Network Architecture
Data Sources:
Primary Sources: Commodity prices, forex rates, interest rates, and other financial data from accredited financial data providers. Price feeds will come directly from verifiably original sources when possible.
Secondary Sources: Crowd-sourced data verified through consensus mechanisms and AI analysis for additional robustness. AI enhancements will be applied to scour global financial data sources to bring transparent pricing to assets with non-transparent pricing and opaque markets.
Oracle Nodes include data providers, data verifiers, and data consumers. These nodes fetch data from various sources to easily source data quicker, which is then verified and enhanced by AI to detect anomalies and prevent fraud.
Real-time updates in real-time to ensure that DeFi applications operate with the most current information. Price feeds will be maintained on the bitcoin native chain.
Price aggregation is conducted, in similar fashion of other traditional finance platforms like Bloomberg, Thompson One, and others. Supporting low latency and high frequency price updates.
Torram will eventually support all critical off and on-chain price feeds with a focus on traditional financial markets, event-based predictive markets, RWAs, and bridging the gap of web 2.0 and web 3.0, building the necessary price feeds required to support the net generation of bitcoin-native DeFi applications, and other decentralized applications.
Improvement and Changes to Stay Innovative
Based on Chainlink 2.0, we will consider similar styles of initial deployment with a rollout approach, focused on first only including a pre-built set of templatized executables and adapters to mitigate against new smart contract risks on bitcoin around flash loan-based attacks, and potential high frequency trading arbitrage and front running risks.
We will be agile and innovate solutions as we see risks emerge and enhance adaption and security using AI. With an eventual open-source role out, we expect the community will also help solve some of the major problems we cannot account for until production ready or testnet release.
It will be important to plan for emergency governance mechanisms, DON accountability, DON membership, DON service level agreement adherence, Future Fee Opportunity (FFO) through an Implicit-Incentive Framework (IIF) with the use of predictive AI based on empirical data. Fair Transaction Sequencing will also be critical.
Concepts like Secure Causality Preservation, Transaction Execution Frameworks are all newer concepts we need to consider regarding possible implementation or ML training to be able to implement AI enhancements to make Torram future-proof.
Phased Hybrid Decentralization Plan Long Term
TORRAM will possess all functionalities envisioned for the final network but will start with partial decentralization.
Initially, only key roles like block validation and query response handling will be on a decentralized path. We believe a certain degree of centralization is necessary for optimal and efficient performance. This is subject to change as we see how things play out, also based on drawback of current Ethereum based competitors.
Hybrid structures and setups, based on our experience, seem to be the most optimal node setup, so our plan is to become more decentralized over time, but still run a hybrid structure long term.
Over time, other functions, managed by centralized nodes, will transition to various independent operators within the Bitcoin blockchain ecosystem. TORRAM plans to release software for Network Operators to monitor initial centralized block production and later, to participate in block production and refining.
Additionally, a virtual setup will be available for those interested in managing their own query nodes, allowing them to manage their own or client requests.
Initially, essential services such as block production and refining will be centralized, operated by TORRAM engineers, and possibly outsourced to bitcoin mining partners.
This setup ensures that the network remains operational while transitioning towards a fully decentralized model.
This initial setup, though semi-decentralized, will still offer all features expected in the fully decentralized final architecture, including querying, staking, governance, and slashing functions. Decentralization will proceed in phases, dictated by the readiness of the software components to support fully decentralized operations.
Community governance will guide the prioritization of these phases, focusing first on roles that node operators are most eager to assume.
Dispute Resolution, Slashing and Bad Actors
Implementing robust mechanisms for dispute resolution, slashing, and punishing bad actors is crucial in maintaining the integrity and trustworthiness of decentralized networks like TORRAM, especially when operating on Bitcoin or its Layer 2 solutions.
Here are some ideas tailored for the TORRAM network that could effectively handle disputes and mitigate malicious activities: Each will need to be explored through testing to determine which mechanism is optimal.
Cryptographic Fraud Proofs Description: Implement cryptographic fraud proofs that allow participants to challenge the validity of data provided by oracles or indexed by nodes. If a verifier or a node submits data that is proven to be incorrect through a fraud proof, they are automatically penalized. Benefit: This mechanism deters malicious behavior by holding participants accountable through cryptographic evidence, reducing the likelihood of fraud as actors know that incorrect submissions can be unequivocally proven wrong and will lead to penalties.
Staking and Slashing Mechanisms Description: Require verifiers and data providers to stake TORRAM tokens as a form of security deposit. If they are found to be acting maliciously—such as providing false data or attempting to manipulate the network—their staked tokens are slashed (i.e., forfeited and possibly redistributed to affected parties or burned). Benefit: Staking incentivizes good behavior and economic security. By penalizing bad actors through slashing their stakes, it aligns their interests with the health and integrity of the network, discouraging them from committing fraudulent activities.
Decentralized Dispute Resolution System Description: Establish a decentralized arbitration system where disputes can be settled by a randomly selected panel of other token holders or trusted nodes in the network. This jury could review evidence related to the dispute and vote on the outcome. Benefit: This peer-to-peer resolution approach enhances the decentralization of the network and reduces the likelihood of bias or manipulation that might occur if a central authority were to handle disputes.
Economic and Reputation Penalties Description: Apart from slashing staked tokens, implement a reputation system where nodes and verifiers have scores that reflect their historical performance and reliability. Poor performance or malicious activities can degrade their scores, affecting their future potential to participate or their earnings within the network.
Benefit: A reputation system creates long-term incentives for good behavior and builds a trust metric that can be used by clients when selecting data providers or verifiers. Low scores could lead to reduced opportunities and financial penalties, encouraging nodes to maintain high standards.
These mechanisms leverage economic incentives and technological solutions to ensure compliance and integrity within the TORRAM network. They also promote a self-regulating environment where the community actively participates in maintaining the network's health, essential for its long-term success and scalability, especially in a decentralized context like Bitcoin's blockchain.
Risk Related to MEV/OEV
Risks related to OEV (oracle extractable value, a subset of MEV (maximum extractable value) as it relates to solving the problems related to frontrunning, arbitrage, and false liquidations.
Current value loss associated with existing OEV solutions has made it almost impossible for institutional traders, asset managers, HFT desks, and others to conduct business in web3 because certain dApps have not been developed due to profitability issues that hinder growth for platforms like Synthetix or GMX.
Torram looks to solve this problem using tiered pricing models, AI-enhanced meta transaction auctions, and ROFR to any entity that’s granted access to update data feeds with regards to OEV.
Other methods for toxic flow (frontrunning/arbitrage) needs to be considered when it comes and latency and diverse price inputs, so we believe having both first-party data and 3rd party from firms like Bloomberg will give us the most comprehensive pricing feeds across all asset classes. Bloomberg B-PIPE, Tradeweb, FactSet, MarketAxes, Reuters, Interdealer broker rates, corporate actions, SEC filings, overnight rates, FX rates, and more, need to be considered as primary real-time off-chain data that needs to be prioritized for institutional DeFi adoption.
Learning from some of the issues faced by Synthetix and focused on opening the doors to trillions in institutional assets to trade as close as possible natively on the bitcoin blockchain or bitcoin blockchain based L2s and sidechains, where security is highlighted over speed, adding confirmation periods will likely be the standard in order to reduce OF frontrunning.
To make this clear, the goal is not speed and fastest execution time and trade confirmation when it comes to most institutional asset managers looking to migrate to new technologies. The prime focus is on security of the transaction. When looking at traditional finance, which has been susceptible to T+1, T+2, T+3, and even T+5 settlements, waiting minutes or hours compared to days is what advancement looks like when trading billions with confirmation, settlement, and finality in the future.
At full scale post production, ideally, prices will be fetched using AI on a time delayed basis unless premium features are paid for to include real-time pricing.
We will keep this standard to existing TradFi markets of 10–15- minute price refreshes on most assets in basic packages. Other things to consider in detail would be Order Flow (OF) issues with generalised OF auctions and the need to consider new solutions like OF auctions specialize for OEV, and other solutions to solve for frontrunning.
OEV Relay need to also be considered in detail and is outline well in a paper written by API3 team. We’ll need to dive deeper into how these may affect or be relevant for implementation on the bitcoin blockchain, and how flash bots would be addressed.
We Will need to try different methods like a first-price sealed-bid auction process, or an AI-based randomizer. A lot of experimentation is due here to see how can use the advancements in predictive and generative AI to help mitigate risks and ensure optimal data feeds with the fairest of dissemination.
Last updated
