How does it work?
The original Triple Confirmation trading strategy establishes the base of our automated trading strategy. Our signal generator starts by focusing only on market conditions where a clear TC is found
The original Triple Confirmation trading strategy establishes the base of our automated trading strategy. Our signal generator starts by focusing only on market conditions where a clear TC is found. Next, noise is filtered out with additional indicators acting as guardrails for the trading bot. From there, our decision maker – written and executed on TradingView – submits position decisions to our Trading Engine, shown as the light blue rectangle on top. Finally, our Trading Engine acts as a dispatcher, submitting the appropriate position to the smart contracts, which trade the user funds and the chart on our website. Trades pushed to the website chart are logged and saved into persistent storage to maintain a running tally of all transactions taken.
Most of the infrastructure shown in the above diagram relates to the frontend user interface. The only necessary parts for executing trades are:
- The TradingView PineScript
- The Trading Engine server
- The Avalanche blockchain contains our ecosystem of smart contracts
Deliberately written as a separate system, execution of trades and fulfilling user actions – meaning user-requested deposits or withdrawals – do not rely on the website or any publicly accessible servers. Should the website be unreachable, users can verify funds and even push deposits or withdrawal requests directly to our
Frontend.sol smart contract (labeled as Smart Contract #2 on the above diagram). The beauty of on-chain trading is the blockchain itself acts as the ultimate security measure. Decentralized ledgers are trustless, and smart contracts are immutable. As such, only the blockchain needs to be active for users to be able to deposit or withdraw their funds.Compare that to Binance or Coinbase. User funds deposited there are seizable assets and are subject to theft should the centralized exchange become insolvent. Read their terms and conditions. No such risk is possible with our system since funds are only withdrawable back to the original depositor. In addition, the team is explicitly unable to touch any user funds.
The internal files for Smart Contract #1 and #2 shown on the above diagram are
BotTrader.sol and Frontend.sol, respectively. Those names were chosen because BotTrader.sol trades user funds and Frontend.sol interfaces with the user interface. Users get assigned to a particular BotTrader smart contract when they first deposit.When deployed, a BotTrader smart contract is locked to a given strategy with two token addresses hardcoded: One being a cash and the other being an asset. All BotTraders under a shared strategy are traded the same way, and since the token addresses are locked, you can be assured that your funds will only be exposed to the cash or asset token addresses.
For example, let's say you select a strategy trading
USDC / WBTC.e. In this instance, the cash token is USDC. The asset token is WBTC.e. At any given time, the BotTrader attached to that strategy can only ever hold USDC or WBTC.e, thereby adhering to a guiding principle for our project: The user should always have complete control over their funds.Last modified 1mo ago