Sentinel Data Aggregation Oracles
The centerpiece of our ecosystem.
The Defyre Sentinel Data Aggregation Oracles will sit as the centerpiece of our ecosystem, as one of the most advanced blockchain security projects ever developed.
The whole purpose of these oracles is to bring off-chain security related data directly into the blockchain for smart contracts and DApps to interact with data points that are otherwise not available, enabling development teams to create intelligent security-driven applications, prevent fraud, and foster trust within the user community.
Oracles
Our oracles collect and aggregate security data points regarding specific smart contracts and DeFi projects, and brings that information directly back into the blockchain itself, making it publicly accessible to any on-chain smart contract and DApp over standard ERC20 interfaces.
Some of these data points include:
  • Smart Contract Security Audit results, for audits performed by Defyre's audit team.
  • Overall Risk Scores.
  • Developer Reputation Scores.
  • Static Code analysis Results including Smart Contract Weakness Classification findings from the SWC registry.
  • Liquidity Risks including risks related to malicious "rug pulls".
  • Social Sentiment scores.
  • Contract Verification status from official sources (e.g. BSCScan.com, EtherScan.io).
Oracles run on external infrastructure hosted on major cloud providers, collect the relevant information on a set frequency (e.g. hourly, daily, monthly, depending on the data point) and push this information directly into our ERC20 smart contracts that can be queried by other contracts in the network using read operations and/or ERC20 interfaces. Example workflow:
This will allow any ERC20 smart contract on the Mainnet to interact with the data, and for DApp development teams to create intelligent security-driven applications, reducing risk for their users.
Use Cases
One very clear example where this can be extremely beneficial to the crypto community specifically relates to Automated Market Makers, or "AMM" for short.
One common problem that has plagued AMMs involves malicious users creating new coins, or faking coins from other popular legitimate projects, creating liquidity pools on the AMM, and then pushing users to trade those coins over social platforms such as Telegram, Twitter, etc.
Unsuspecting users then trade those coins thinking they are getting them at a discount, and the malicious user then removes all of the liquidity, leaving everyone else with worthless coins. These are commonly referred to as "rug pulls", and unfortunately, are extremely common in the crypto community. Because of the code logic from the AMM's liquidity pool contracts, there is no technical way to prevent this as it openly allows anyone to create liquidity pools.
This is where our oracles help in solving a major problem in the industry that has caused millions of dollars in damages to unsuspecting users around the world.
For example, what if the AMM's contract would first check our oracles for risks, prior to allowing a token to be added into the pool? Problem solved.
The Process
The "Get Rich Fast" (GFT) Token
  • A malicious developer creates a token, Get Rich Fast token (GFT).
  • The token is launched on the BSC or ETH Mainnet.
  • The token is marketed on Twitter, Telegram, and other channels.
  • The developer tries to create a GFT/ETH liquidity pair on a popular AMM.
  • The AMMs smart contract interacts with our oracles to check the status for GFT:
    • Is the contract audited?
      • No.
    • Is there any current information available in our oracles?
      • No.
    • The AMMs smart contract calls a write operation in our contract to initiate data collection, paying a small fee in DFUT to Defyre which goes to our Infrastructure Overhead Costs wallet.
  • The AMMs smart contract denies the liquidity pair creation, displaying an error to try again in 24 hours.
  • Our sentinels fetch information on the contract, metadata such as creator, holders, verification, website (if posted on BSCScan.com, EtherScan.io), transactions, etc., and performs static analysis on the smart contract code for the GFT token.
    • The audit assigns the GFT token a risk score of 10/10 because of several red flags.
  • The developer waits 24 hours, and tries again. The AMMs smart contract interacts with our oracles again to check the status for GFT:
    • Is the contract audited?
      • Yes.
    • Is there any current information available in our oracles?
      • Yes.
    • What is the risk score?
      • 10/10 - High Risk.
  • The AMM smart contract denies the liquidity pair creation again, preventing the malicious developer from cheating the community.
  • The audit report for the token becomes publicly available on Defyre's Data Platform, where the original contract creator can request a revision of the contract if in fact the token was not created maliciously.
The community now votes on whether this contract should be audited, or the token creator pays a fee to conduct an audit that's published to the community.
What's Next?
All of the detailed mechanisms, contracts, and code involved in these operations will be posted in this article and our GitHub repository once they become available according to our official roadmap.
Last modified 8mo ago
Copy link