As discussed in the Litepaper, Torque, a DeFi automation network, streamlines personal saving. This is accomplished through vertically-integrated products including Boost, Borrow, Farm, and more. Assets initially listed are the first of many. In this section, you'll dive deep into each of the Torque products to learn how and why they function.
Boost Managers are top-level, auto-compounding vehicles and the main entry point for Torque users seeking diversified yield across the decentralized finance space. Upon receiving assets, Boost Managers act as vehicles to handle appropriate child vault routing (
BoostETH for ETH,
BoostTUSD for TUSD). When a Boost Manager splits and deposits assets into child vaults, the child vaults mint
vTokens to the Boost Manager.
Users don't ask for
vTokens from Boost Managers. Instead, the Boost Manager mints its own liquid receipts, called
tETH for ETH deposits and
tTUSD for TUSD deposits), and transfers them to the users.
tTokens represent the user's claim on assets and yield earned across all multi-vault strategies. Boost Managers create a degree of separation between users and child vaults to ensure proper protocol accounting.
Vehicles are Boost Managers which aggregate strategies. For example, the
BoostETH vehicle aggregates the strategies of
StargateETH. When assets are deposited to a vehicle, the vehicle allocates and deposits these assets into the underlying child vaults based on the dynamic allocation. The child vaults then mint
vTokens representing the deposits. However, instead of going to the original depositor, these
vTokens are transferred to the vehicle. This allows vehicles to track aggregated positions across all the underlying vaults.
The foundational layer in our system, containing the core logic for each specific strategy. They interact with underlying DeFi protocols to maximize yield on deposited assets. For example,
GMXV2ETH is specific to GMX V2 for earning yield on ETH, while
CompoundUSD interacts with Compound for stable asset liquidity provisioning.
Boost paired side-by-side with Borrow enables a powerful, DeFi 2.0 saving experience. When
borrow is called, a CDP-based loan is created by routing collateral to Compound for a USDC loan, and using that USDC to mint TUSD which is ultimately delivered to end users. On the opposite side, when
repay is called, the position is unwound. Users may initially deposit wrapped BTC or ETH and earn claimable TORQ rewards on top.
Compound V3, popularly known as the Comet deployment which isolates risk across markets and further improves capital efficiency through optimized reward structures, is integrated with Torque USD. This enables an improved borrowing experience through best-in-class loan rates as TORQ accrues to users while COMP accrues to the treasury.
The TUSDEngine is responsible for minting, burning, and liquidating positions related to Torque USD. Functions are called by users and related ecosystem contracts in a public fashion. It is a fork of the Maker DAO DSS system and mandated to maintain peg at $1.00 for mint and burn via Chainlink oracles. In the case a Chainlink oracle becomes stale, a secondary oracle such as Uniswap's V3 TWAP is swapped in as a temporary replacement. The price of Torque USD on secondary markets such as Uniswap and Curve should remain stable as liquidity is concentrated but may fluctuate depending on market conditions. Thus, in the event secondary markets experience a depeg event, users are directly incentivized to purchase it and redeem at the USDEngine for $1.00 of backing assets.
In this context, a stable pair is two tokenized dollar assets within a Uniswap liquidity pool such as USDC/TUSD or FRAX/TUSD. These pools generate fees and TORQ rewards for liquidity providers based on trading volume and distribution rates. IL applies in the same way it does for volatile assets, but is beautifully offset due to the stable factors. As Torque is built on Uniswap V3, a 50/50 balance of assets provided to the pool is only optional.
Volatile pairs empower global liquidity providers to maintain exposure to digital assets of their choice, while at the same time increasing or decreasing exposure to said asset. For example, if a user bullish on TORQ, they may set a liquidity position such that the TUSD within is converted to TORQ through different price ranges. This process enables liquidity providers to scale in and out of positions over time versus jumping in and out all-at-once.
Once liquidity has been provided to Uniswap, a user will begin earning trading fees and become eligible for additional TORQ incentives by calling
stakeToken on the respective USD Farm pool contract. This will then transfer the LP NFT to the staking pool and begin the user's TORQ distribution block-by-block. After a user is satisfied with earnings, they may call
claimReward to fetch TORQ and
unstakeToken to retrieve their LP NFT. Once back in a user's wallet, liquidity can be adjusted further. This can be done through the Torque Inc. provided USD Farm interface, on Uniswap, or directly through the contracts.
One key characteristic of Torque is it's decentralized nature. To accomplish this, TORQ is distributed to protocol participants across Boost, Borrow, and Farm. Holders may delegate voting power to themselves or an aligned entity to shape the future of Torque. Complete decentralization will be effective once ownership of TORQ has been transferred to the Hamilton governor contract. This and other items will be voted on by the community.
The Hamilton contract is a governance mechanism using OpenZeppelin's framework. It operates based on a specified token, represented by
_token in the constructor. It is integrated with a Timelock Controller, ensuring approved proposals are delayed before execution to provide participants time to react against malicious proposals.
There is a delay of 50,400 blocks (roughly 7 days) before a proposal can be voted on and a voting period of 50,400 blocks (roughly 7 days) during which token holders may cast their votes. There is an initial 10m minimum TORQ requirement to submit a proposal and quorum set at 10% of the total supply. Holders may propose changes by specifying
calldatas, and a textual description.