Exploit Prevention
Prevention is the best Treatment
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.
Stealing of Capital
Non-Custodial
As a proud non-custodial project, we never have custody of anyone's capital. Rather, each user's smart contract is the only place where capital is held. Each user's smart contract has an OWNER address which is assigned upon deployment to the msg.sender (the person who pushed the transaction). Since the user deploys the smart contract themselves, they become the OWNER and thus all funds in that smart contract belong to them. The OWNER of any Pooled smart contracts is the Controller.sol smart contract which the team control. Importantly, Pooled smart contracts keep track of all deposits and ownership percentages such that whilst we can execute withdrawals from Controller.sol we cannot redirect those withdrawals. Only each member (depositor) can receive their proportion of funds back to them.
Only the depositing address can withdraw funds. There exists no mechanism to redirect withdrawals away from an Individual mode OWNER or Pooled mode member. This means if a depositor were to lose their private key, their funds will be irreversibly lost as is the case with self-custody. We are the self-custody solution to fully managed trading where the benefits and drawbacks are two sides of the one coin: 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.
No Redirection of Withdrawals
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 team at Trendespresso can perform is looping through each user and withdrawing their full balance back to them. In this case, your balance is moved in full from your smart contract(s) 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.
No Balance-Tracker Tokens
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. No depositor need ever worry about their funds being accidentally transferred away as can happen when a project issues balance-tracking tokens. Our system instead maintains an internal ledger which dramatically reduces the danger of self-custody rookies losing their funds. If you have control of your wallet, you have control of your funds.
Bad Actors
Making Bad Trades
Our smart contracts offer two levels of privileges: The trading authority level and the admin authority level. All wallets at both levels are tightly controlled by the team.
The admin authority level is able to adjust various parameters of the platform, withdraw users their funds, and to execute trades. The trading authority level is only able to execute trades.
The trading level wallet we use on our Trading Engine is a hot wallet. Ownership of the trading level wallet would only permit a bad actor to perform loss-incurring trades for all strategy participants. Importantly however, there exists no monetary incentive to execute bad trades. The trading is neither entitled to nor collects any trading fees.
Our trading fees are collected to the Treasury wallet (default: 0x75730E051C54c592f72Ec818B175150EA77545Fc) associated with each strategy. A bad actor could alter the Treasury wallet of a given strategy to route future trading fees to a wallet they control. Importantly however these fees would only be collected if the trade(s) were profitable! Thus even if a bad actor were to change the Treasury wallet, the bad actor would only see any income if they make positive, profitable trades for our users. Game theory putting in work.
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.
Liquidity
We have succeeded where other on-chain trading funds have failed. Submitting orders on the blockchain comes with the hidden risk of significant price impact. Blockchain liquidity is extremely fragmented with liquidity pools ("LPs") on each DEX offering a slightly different price to each other. DeFi heavily relies on arbitragers to negotiate prices between non-custodial decentralised exchanges ("DEXs") and custodial centralised exchanges ("CEXs"). 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
Utilising 0x for liquidity aggregation and best-in-market pricing
Tapping into 0x's private liquidity
Reverting on high slippage inside 0x's Router
Running all trades through our in-house price protection system
Reverting in your smart contract(s) if we were frontrun
Price Protection System
Whilst 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 your 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, your smart contract will perform the swap using 0x's swapCallData and closely examine the price obtained. If the price is bad for your position beyond a data-driven x.xx% threshold determined programmatically – meaning the price slipped unfavourably against the direction of trade – then our trading smart contract(s) will revert. Reverting on the blockchain means abandoning the swap and thereby not changing your position(s) at all. The minimum or maximum price too accept is submitted by our Trading Engine which itself fetches and aggregates prices from over a dozen sources including Coinbase, Binance, Chainlink, Uniswap, and TraderJoeXYZ.
Altogether then we ensure to the best of our ability that low liquidity will never result in instant losses.
MEV Bots (Frontrunners)
Frontrunning our system 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 trade transactions. Once a trade transaction of ours 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 trade transaction. If instead the copier's transaction falls into the next block – which is highly 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 the price we obtain. 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, your funds are still protected since we have our own in-house price protection system.
We have implemented robust resistance measures to prevent the execution of trades at disadvantageous prices.
Copy-trading
The highest compliment possible!
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 transactions – 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 system at the Web3 smart contract level with our Whitelabel implementation.
For additional risk analysis, see our Ecosystem Partners page where 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 updated