Comment on page
Exploit Prevention
We believe the best answer to exploits is to prevent them in the first place. Throughout the Web3 space we see hacks, exploits, unintended code results, and lapses within Dr. James Reason's Swiss Cheese Model. Thus, we've taken steps to thoroughly consider all potential exploits with greater mitigation practices put in place with proportional likelihood and severity considered. To assist in our identification, we've grouped exploits into one of five categories. Each category listed below contains robust and lengthy information about our mitigation measures. Please note that like aircraft manufacturers, we've undertaken tremendous efforts to build multiple and redundant systems with the singular goal of reducing all exploit potential to asymptotically nil.
- 2.
- 3.
- 5.
As a proud non-custodial project, we never have custody of anyone's capital. Rather, our BotTrader smart contract is the only place where capital is held; except in the case of a deposit while a trade is in progress, in which case the pending deposit amount is held in the BotPool until the trade's conclusion. Each strategy has its own BotTrader but all strategies share the same BotPool.
Only the depositor address can withdraw their funds. There exists no mechanism to redirect withdrawals away from a depositing address. This means if a depositor were to lose their private key, their position and funds will be irreversibly lost. We are the self-custody solution to fully managed trading where the benefits and drawbacks are the same: No one can steal your funds since you alone control their movements. At the same time, should you lose access to your account, no one can help you recover control of your funds.
We firmly believe that self-custody is the best path forward and is the best mitigation against theft of capital. We purposefully omit the ability to withdraw funds from Account X to Account Y. Our smart contracts only offer the ability to withdraw funds deposited by Account X back to Account X.
The only movement of funds functionality the Triple Confirmation team can perform is looping through each depositor and withdrawing their full balance back to them. In this case, your balance is moved in full from the Bot back to your wallet.
Our smart contracts have no ability to freeze withdrawals. Any and all depositors will always be able to withdraw their funds at any time.
Unlike most other DeFi protocols, we don't issue balance-tracker tokens such as LP tokens or aTokens. This means that so long as a depositor has control of their wallet, they can always retrieve their funds from our smart contracts. No depositor need ever worry about transferring away their portion of ownership in any of our strategies. As an aside, our refusal to mint balance-tracker tokens and instead maintain an internal ledger dramatically reduces the danger of self-custody rookies losing their funds. If you have control of your wallet, you'll always be in control of your funds.
Our smart contracts offer two levels of privileges: The
tradingWallet authority level and the adminWallet authority level. The adminWallet is our 5 of 7 Gnosis Safe multi-sig wallet located at: https://snowtrace.io/address/0xc25f0b6bdbb2b3c9e8ef140585c664727b3b9d60The
adminWallet authority level is able to adjust trading fees, prevent deposits, adjust the TCC farm reward rate, migrate Vesting+ TC to a new BotPool, and execute trades. The tradingWallet authority level is only able to execute trades.The
tradingWallet we use on our Trading Engine is a hot wallet. Ownership of the tradingWallet would only permit a bad actor to perform loss-incurring trades for all Bot participants. Importantly however, there exists no monetary incentive to execute bad trades. The tradingWallet is neither entitled to nor collects any trading fees.Our trading fees are collected exclusively to our 5 of 7 multi-sig
adminWallet meaning only if that wallet were to be compromised could a hacker steal funds from the Triple Confirmation team.Once again, deposited funds are protected since there doesn't exist any mechanism to directly withdraw other people's capital thus ensuring our non-custodial promise.
We rely on Safe's multi-sig wallets. These are well-audited and routinely battle-tested with hackathons and bug bounties. The only way to compromise our
adminWallet is to socially engineer a full 5 members to either sign a malicious transaction or to directly relinquish control of their wallets (obtain 5 separate private keys).If our
adminWallet were to be compromised, a bad actor could steal all the funds in our project's treasury but, very importantly, would be unable to steal the funds of our depositors. Since we are non-custodial – we do not have any control over redirecting withdrawals nor any ability to transfer balances between accounts – user funds are safe. The worst damage a hacker could do would be to increase the profit share percentage to a hardcoded cap of 40% and then perform profitable trades. Well, that doesn't sound too bad to Bot participants now does it? 🎉
We have succeeded where other on-chain automated trading systems have failed. Submitting orders on the blockchain comes with the hidden risk of significant price impact. Blockchain liquidity is extremely fragmented with liquidity pools (LP) on each DEX offering a slightly different price to each other. DeFi heavily relies on arbitragers to negotiate prices between non-custodial decentralised exchanges (DEX's) and custodial centralised exchanges (CEX's). Slow arbitraging can mean a wildly different price on a given DEX than exists in the rest of the market. Low liquidity within an LP can mean a massive price impact.
In extreme price impact cases, performing a large swap on-chain can result in an instant -99.99% loss of capital.
We solve this issue by:
- Breaking entries and exits into partial orders
While we first employ and rely on 0x's safeguards, we have two additional layers of protection. The first takes place at the Web2 level inside our Trading Engine. The second takes place at the Web3 level inside our BotTrader smart contract at the very end of our on-chain transaction.
At the Web2 level, our Trading Engine will perform a swap on a locally forked blockchain running on
localhost and verify the price paid post-transaction. Only after this check succeeds does the transaction get submitted to the blockchain.At the Web3 level, our BotTrader smart contract will perform the swap using 0x's
swapCallData and closely examine the price obtained. If the price is bad for the Bot's position beyond x.xx% – ex. the price slipped into the Bot's direction during an entry transaction or price slipped against the Bot's direction during an exit transaction – then our Bot will revert. Reverting on the blockchain means abandoning the swap and thereby not changing the Bot's position at all. Our BotTrader is given the minimum price to accept by our Trading Engine which itself fetches and aggregates prices from over a dozen sources including Coinbase, Binance, Chainlink, Uniswap, and TraderJoeXYZ.Frontrunning our Bot is very difficult. For starters, we can only be targeted if someone frontruns our order in the same trade direction in the same liquidity pool. To successfully frontrun us, someone would need to spin up their own node to constantly scan their
mempool for our Bot's transactions. Once our Bot's transaction is found, the transaction's bytes would need to be reverse engineered (decompiled), interpreted, and copied. The Avalanche blockchain has a time-to-finality of approximately 2 seconds meaning all of the above would need to be executed within that time to fit within the same block as our Bot's transaction. If instead the copier's transaction falls into the next block – which is quite likely – then by the very definition they're not a frontrunner and instead a simple copytrader.Assuming someone does successfully copy our order and submit it in the same block, they'd still need to submit their transaction to the same liquidity pool or liquidity provider as us to adversely impact our Bot. In this instance, we have a number of prevention measures as outlined above. Our transaction would revert if any one of the aforementioned protections calculates slippage beyond our limit.
Even if the frontrunner controls the liquidity pool/provider to which our order is submitted, our Bot's funds are still protected since we have our own in-house price protection system.
Our one year long Alpha testing phase was crucial to delivering these lessons. Throughout Alpha, we developed substantial resistance to executing trades at disadvantageous prices and built very robust protections.
The highest compliment a project like ours could obtain!
On a serious note: Let's assume someone successfully copy trades us. Since their trades will always come after ours – thanks to our depth of price protection and the complexity in frontrunning our Bot – their entry and exit prices will always be worse than ours. Overall this means less profit for them and much higher management costs in both time and money.
The easiest way to leverage our successful strategies is to integrate our Bot at the smart contract level with our Whitelabel DevKit.
For additional risk analysis, see our Ecosystem Partnerswhere we perform third-party risk assessments. Every piece of our infrastructure is under continuous observation of risk, exploit potential, and improvement. Preventing the unnecessary loss of capital is of paramount concern to us.
Last modified 3mo ago