Autonomous Augmentations — Volume One
This is the first post in a series featuring ideas for autonomous services from Autonolas community members. It’s brought to you today by guest author and community member Odin.THOR. Odin.THOR has been doing some impressive thinking about compelling ideas for autonomous services and we wanted to share them with the community. Let us know what you think, and feel free to also share your own ideas with everyone on Twitter or Discord–you might be the next author featured on the blog!
Welcome to the first volume of Autonomous Augmentations!
With more and more of the Autonolas stack being released, this series hopes to provide new (and existing) members of our growing community a ‘feel’ for application types uniquely suited for the robust, fault-tolerant and highly flexible nature of our framework. Each installment of Autonomous Augmentations will aim to introduce a novel project idea to the community with the goal of fostering an atmosphere of open collaboration and continual innovation.
We encourage anyone intrigued, excited or even wary of the ideas discussed here to visit our Discord and share their thoughts and/or suggestions! As always, anyone interested in building with Autonolas should feel free to reach out to our core team on Twitter/Discord!
Without further ado, let us dive in!
#1 : Dynamic ‘Real’ CPI Oracle
Purpose: To provide inflation-resistant stablecoins with a transparent, reliable & customizable alternative to Government-issued CPI statistics.
Overview: Inflation-resistant stablecoins have seen growing adoption as a simple recourse to avoid the ever-pervasive effects of inflation.
VOLT & FPI, the two predominant options, both update their peg on the basis of CPI data published by the US BLS. Many have raised concerns regarding the accuracy of this CPI data, suggesting those responsible for its publication have motive to misrepresent the reality of inflation. Frameworks like Autonolas can allow DeFi to avoid inheriting the opaque nature of the current system by deriving a price index using information drawn from open-source price-monitoring APIs. The product categories and sources used can be weighed dynamically to develop a variety of index types (Eg: An index which mainly tracks the purchase price of fuel). This data can then be packaged into a multi-chain Autonolas Oracle.
Additionally, both VOLT & FPI draw their CPI data from the same Chainlink Oracle (See: 1,2), making them susceptible to attack and/or hostile manipulation via centralized vectors. An Autonolas Oracle can potentially provide a more decentralized publication mechanism for otherwise excellent open-source inflation estimators such as Truflation, which is also primarily published through Chainlink. Truflation’s openly available methodology could act as a solid template for anyone attempting to build their own inflation estimator on Autonolas.
Path to Implementation: A network of Autonolas agents is configured to interact with open-source web-scraping services which collect price data for everyday goods from online storefronts. Agents themselves could be trained via machine learning to expand the sources they draw from through intelligent identification. Price data for universal goods such as grain and medication could also be collected from storefronts that cater to different socioeconomic demographics to add further nuance to calculations (Eg: Whole Foods vs Walmart). Product categories could also be weighted differently based on protocol demand to develop a range of specialized inflation estimators.
#2 : Active Bridge Sentry
Purpose: To allow quick, automatic responses to hacks/rug-pulls in relation to wrapped tokens & real-world backed assets.
Overview: Some of the largest hacks in DeFi history have involved wrapped tokens and bridges. The sheer quantity of constantly shifting components involved with bridges make them vulnerable to a particularly wide surface of attack. In the case of the recent Axie Infinity hack, the attack itself was not noticed for 6 days, allowing the perpetrators ample time to redirect compromised funds.
Taking the Axie Infinity hack as an example, imagine a similar situation involving a service which bridged ETH from Ethereum to Avalanche. On Day 1, an exploit was carried out, the keys on the Ethereum side of the bridge were compromised, and all ETH was stolen. Like the Axie hack, news of the exploit did not spread until Day 6.
Between Day 1 — Day 6, the wETH market on Avalanche remained unchanged since the effects of the hack were not widely known. (Until Day 6, wETH = ETH)
If a user had tasked an Autonolas service with monitoring the bridge for unusual activity and enabled it to take action on Avalanche, any wETH the user owned would likely have been entirely salvaged without additional input. The Autonolas agents would have noticed the emptying of the bridge’s ETH wallet on Ethereum and would have quickly converted the wETH on Avalanche for a different wrapped version or stablecoin, before a market response to the hack.
Conversely, if the bridge provider had enlisted an Autonolas network to monitor the bridge, they could have been notified via a Web2 notification the moment Autonolas agents detected unauthorized activity, allowing for a much faster response to the attack.
Even non-DeFi users have begun to notice bridge hacks.
A similar system could also be designed for BUSD and USDC, since Binance and Circle publish attestation reports regarding the solvency of their stablecoins. In the unfortunate event either BUSD or USDC becomes under-collateralized, and this information is included in the Binance/Circle report, an Autonolas service could begin converting any BUSD/USDC under management for a different stablecoin before the rest of the market starts to panic.
Path to Implementation: A network of Autonolas agents is configured to monitor bridge wallets on both involved chains and tally data collected from both sources to search for discrepancies. In the event of a major discrepancy, the agents will initiate the conversion of affected assets they manage (on behalf of a user/DAO) to a predetermined ‘safe asset’ (Eg: USDC).
In the case of BUSD/USDC solvency monitoring, Autonolas agents will be instructed to compare the value of assets listed by Binance/Circle in their report to the quantity of BUSD/USDC in circulation. If major under-collateralization is detected, the agents will begin converting managed BUSD/USDC to a ‘safe asset’ (Eg: USDT/BTC/ETH).
In both cases, a Web2 notification will be pushed to the user as soon as unusual data is identified.
#3 : Single Step Speech-to-Contract Transmutation
Purpose: To allow users without a programming background to independently design and deploy smart contracts in a trustless manner.
Overview: This idea was originally inspired by Valve’s Proton. Proton enables the direct translation of DirectX game code to Vulkan, allowing it to be run natively on non-Windows systems, all while retaining the nuance of the programmed instructions.
In Autonolas’ case, the goal would be to extend similar ‘logic-extraction’ to cover plain-speech descriptions of DeFi functions such as loans and token-issuance. Imagine if a user could simply write out their design for a new product or primitive and feed it to an Autonolas service for deployment. The service could then be forced to come to consensus regarding the ‘logic-map’ the plain-speech input describes, transcode it to Solidity, and seamlessly deploy it as a smart contract.
Such a service will undoubtedly require extensive effort to design and bring to fruition. However, successful execution could open the development of DeFi to a massive demographic of talented people who do not possess either the skillsetor inclination to learn Solidity.
Path to Implementation: Autonolas agents are trained via machine learning to identify relationships between the documentation and smart contracts used by several popular projects. The results of the training can be periodically reviewed by a team before updates are pushed to the stable version of the tool.
On the user side, example instructions can be provided to suggest ideal pattern types for different genres of plain-speech instructions. Users can also be given a graphical representation/flow-chart of how their smart contract will behave prior to deployment to ensure accuracy.
#4 : Inputless Arbitrage Income in Inefficient Markets
Purpose: To allow DAOs to expand their holdings by filling arbitrage opportunities generated by unusual market activity.
Overview: This use case is mainly targeted at large-capital investors (DAOs/Whales) who already make use of a low-risk yield-farming strategy.
Large arbitrage opportunities appear with surprising frequency among popular assets as they change hands and management decisions are made. Those who profit from these openings are typically experienced arbitrageurs with dedicated bots aimed at specific asset types. Services such as White Whale have made considerable headway in democratizing access to arbitrage to anyone willing to devote capital to fund shared arb-bots.
DAOs generally search for low-volatility yield-generation opportunities in order to keep their assets productive but not expose them to unnecessary risk. Consequently, the yield-generation strategies they employ tend to be relatively low-reward. Arbitrage, also being particularly low-risk, has the capacity to complement DAO-centric yield-generation strategies and enhance returns, making it a prime opportunity for Autonolas to capitalize on.
The issue with high-frequency arbitrage is that large quantities of capital can only be made fully productive when significant divergences occur in the price of an asset across separate markets. These opportunities are relatively rare. Furthermore, the decentralized element of the Autonolas Stack is not particularly suited for high-speed trading. Therefore, shared arb-vaults would need to be used from a service like White Whale. Since such vaults share profits between all depositors, they result in somewhat low income when all funds in the vault are not actively used (as is the case without a significant price divergence).
Arguably the simplest solution in this situation is optimization — to make use of traditional yield-farming ordinarily and to shift funds to arb-vaults when the market becomes particularly conducive. Autonolas agents can be used to detect such openings and move funds when appropriate.
Path to Implementation: Autonolas agents identify large divergences in the price of a managed asset across chains and/or DEXs. Agents may even be designed to predict price divergences by monitoring the activity of the largest holders of a token and pre-emptively reacting to behavior associated with large purchases and sales. After identification, the agent network deposits managed assets into the corresponding arb-vault on a service like White Whale. After the divergence has been corrected, funds can be returned to the original yield strategy.
Thank you for taking the time to read through these ideas! Once again, if you find any of them to be of interest to you or your team, visit our Discord to start a conversation with the community.
Sign up for updates