The safety, decentralization and robustness of the Axial protocol is of utmost importance. To accomplish this to a desirable level, we’ve chosen to not use oracles. To explain why this choice was made, let’s first investigate what oracles are at a basic level.
What are oracles?
In practice, oracles provide smart contracts information from external sources. This usually refers to off-chain data. A simple and much utilized example would be to query token prices for a decentralized application. This is in fact a very real problem for most decentralized exchanges and other types of applications since achieving that on-chain is relatively complex.
In this example, an oracle would be able to provide token prices for the application, leaving its developers to be able to focus on other functionality, the quality of their smart contracts, etc.
Why not use oracles?
With all these advantages, comes some serious downsides to consider, including the following:
- Oracle Over-Reliance
- Centralization Concerns
- Security Concerns
The over-reliance on oracles ultimately adds constraints to the development of the underlying protocol. This means that situations may arise when developers want to add a new feature or token to a liquidity pool, but can’t because the oracle used doesn’t support that token yet. Avalanche is a fast-moving and rapidly expanding ecosystem, and Axial shouldn’t be limited in scope because of such constraints.
The concern over centralization is mainly due to the fact that the majority of oracles are centralized entities. This means they are not as secure or as hard to manipulate as decentralized applications. This creates a very visible attack vector for Axial, and is not something we wish to entertain. There are however decentralized oracles that — albeit expensive — can accomplish the same as those centralized ones. An example of this type of oracle would be Chainlink.
Security concerns, along with the ones mentioned above in terms of centralization, come from having any external connections at all. If it is possible to implement robust smart contracts that are publicly verifiable, immutable and encapsulate all our desired functionality, why would we utilize an oracle that could potentially introduce new external security issues? By keeping Axial entirely self-contained, we avoid any of the headaches that come along with oracle implementations, while remaining as agile as possible to build for our community.
How are asset prices managed on Axial?
Since we do not utilize oracles, Axial needs some way of accurately identifying asset prices for our many liquidity pools. Our smart contracts are forked from Saddle Finance, and follow many of the same concepts utilized by Curve. In both of these protocols, and now Axial, asset prices are managed through the ratios of each asset in a liquidity pool. Changes in such ratios allow for arbitrage opportunities that sell or buy assets at slight discounts or premiums, rebalancing the pool and returning the asset values to reflect their true price.
Most other Automated Market Makers rely on a ratio of 50/50, 25/25/25/25 or other similar ratios for their pools in order to maintain accurate asset prices. This is not the case with our smart contracts. This flexibility allows for liquidity to settle in a way that reflects what tokens are traded the most at any given time, leading to much higher efficiency when it comes to liquidity utilization.
Conclusion
At the end of the day, Axial is a truly native Avalanche protocol. From our governance structures and smart contracts, to the assets supported, we will always hesitate to introduce external factors when our ecosystem can be fully self-contained and more robust. We place great importance in developing native tools for Avalanche, since there is no one better to appeal to the needs of our community than the community itself.
About Axial
Axial is a decentralized value-pegged asset exchange with a focus on native Avalanche applications. Axial uses a model that provides ultra low fees and slippage for traders.
