TIYlab Expands to DEX Trading: Hyperliquid and Aster Are Now Live
TIYlab now supports 10 trading venues — 8 centralized exchanges and 2 decentralized exchanges — with all three Bitcoin strategies available on a single selected venue
TIYlab has reached another major milestone.
Hyperliquid and Aster are now officially supported as Live trading venues.
That brings the platform to:
10 supported trading venues
- 8 centralized exchanges
- 2 decentralized exchanges
And, importantly, this does not create a separate version of TIYlab.
The principle remains exactly the same:
one user → one selected venue → three automated Bitcoin strategies.
Users can now choose between:
Centralized exchanges
- Binance
- Bybit
- KuCoin
- OKX
- Bitget
- Gate
- MEXC
- HTX
Decentralized exchanges
- Hyperliquid
- Aster
All three TIYlab strategies are supported:
- Macro
- Adaptive DCA
- Adaptive Shield
---
Why Add DEX Support?
Until now, TIYlab was built around centralized-exchange APIs.
That architecture remains available and unchanged.
But some users prefer decentralized trading infrastructure and wallet-based accounts rather than opening another traditional exchange account.
The goal was therefore not to redesign TIYlab.
It was to make the existing system capable of running on selected decentralized venues while preserving the same core principles:
- one trading venue per TIYlab instance
- no custody of user assets by TIYlab
- deposits and withdrawals controlled by the user
- restricted automation permissions
- clear separation between simulation and Live trading
- the same Macro, DCA and Shield strategy logic
The result is not "TIYlab DEX."
It is simply TIYlab with more execution choices.
---
Hyperliquid and Aster Were Chosen for a Reason
For TIYlab, supporting a DEX requires much more than being able to place a swap.
A venue must support the complete portfolio architecture.
Macro needs:
- spot Bitcoin exposure
- perpetual markets for its hedge logic
Adaptive DCA needs:
- liquid Bitcoin spot execution
Adaptive Shield needs:
- controlled long and short BTC perpetual exposure
And all of this needs to work on one venue.
That requirement immediately eliminates many decentralized protocols.
Hyperliquid and Aster provide the combination TIYlab needs.
---
Hyperliquid
Hyperliquid provides both spot and perpetual markets within the same trading environment.
For TIYlab:
- Macro uses spot BTC exposure and BTC perpetuals for hedging
- Adaptive DCA uses the spot BTC market
- Adaptive Shield uses BTC perpetual exposure
- USDC is the relevant stablecoin
One technical detail is important.
Hyperliquid's spot Bitcoin exposure on HyperCore is currently represented by UBTC.
We do not describe this as native Bitcoin held directly on Bitcoin L1.
Native Bitcoin deposits and withdrawals are part of the Hyperliquid/Unit ecosystem and remain outside TIYlab's responsibility.
TIYlab never manages those deposits or withdrawals.
---
Aster
Aster provides the Spot and Perpetual markets required by the three TIYlab strategies.
For TIYlab:
- Macro uses BTCUSDT Spot and BTCUSDT Perpetual
- Adaptive DCA uses BTCUSDT Spot
- Adaptive Shield uses BTCUSDT Perpetual
- USDT is the relevant stablecoin
Aster also provides an Agent permission model particularly suited to TIYlab's security approach.
The TIYlab Agent is configured with:
- Spot trading enabled
- Perpetual trading enabled
- Withdrawals disabled
- TIYlab server IP restriction enabled
Those permissions are checked before Live activation.
If the expected security state is not present, TIYlab refuses to start automated trading.
---
TIYlab Never Manages the User's Deposit
This is an important boundary.
TIYlab does not try to become a wallet manager.
Before connecting TIYlab, the user creates and funds the Hyperliquid or Aster account independently.
TIYlab does not:
- request the wallet seed phrase
- request the master-wallet private key
- move assets out of MetaMask or another wallet
- initiate the user's original deposit
- control external withdrawals
Deposits and withdrawals remain entirely under the user's control.
Only after the account is already funded does the TIYlab connection begin.
---
The Free Simulation Remains Permissionless
Adding DEX support did not change the TIYlab onboarding philosophy.
In fact, decentralized venues fit particularly well with the progressive trust model introduced recently.
The journey remains:
Discover → Verify → Automate
① Discover
A user can start the free 14-day simulation.
No payment.
No card.
No API.
No wallet authorization.
No Agent Wallet.
No real orders.
Only virtual capital.
Hyperliquid and Aster can be selected just like the existing centralized exchanges.
TIYlab then simulates the three strategies using the venue-specific market environment.
---
② Verify
The user may later verify the selected DEX account.
For Hyperliquid and Aster, this requires only the public account address.
No trading Agent is created.
No trading signature is requested.
No private key is shared.
TIYlab uses public account information to verify compatibility.
The same free simulation continues.
The virtual portfolio, dates, equity and decision history are preserved.
Nothing is reset.
At this stage:
TIYlab still has no trading authorization.
---
③ Automate
Only if the user decides to go Live does the next permission level appear.
The user first chooses a paid plan.
Then a new dedicated trading Agent is authorized.
The important word is dedicated.
TIYlab never receives the user's master-wallet private key.
The Agent exists specifically for automated trading.
The simulated portfolio is also never converted into the Live portfolio.
No simulated position becomes real.
No simulated equity is carried forward.
Live execution initializes from the actual balances and positions on the DEX.
---
Hyperliquid Agent Security
On Hyperliquid, TIYlab uses a separate Agent Wallet.
The user's master wallet authorizes that Agent for automated trading.
TIYlab stores only the credentials required for the dedicated Agent.
It never receives the master-wallet private key.
The Agent is used to sign trading operations, while withdrawal and transfer authority remains outside the TIYlab Agent's scope.
The user can revoke the Agent independently.
TIYlab also periodically checks that the expected Agent relationship remains valid.
If access is revoked or the security state is no longer correct, automated execution is paused.
---
Aster Agent Security
Aster provides explicit Agent permissions.
Before TIYlab allows Live execution, it verifies:
Read access: enabled
Spot trading: enabled
Perpetual trading: enabled
Withdrawals: disabled
TIYlab IP restriction: correct
Agent expiry: valid
If withdrawals are not disabled, Live activation is refused.
If the IP restriction is not what TIYlab expects, Live activation is refused.
If the Agent expires or is revoked while the bots are running, TIYlab pauses execution rather than continuing in an unknown security state.
---
Security Does Not Stop at the Agent
Protocol permissions are only the first layer.
TIYlab also applies its own runtime controls.
DEX execution is restricted to the approved Bitcoin markets required by the strategies.
Additional protections include:
- maximum order limits
- maximum position limits
- leverage controls
- daily turnover limits
- slippage limits
- stale-price protection
- price-deviation protection
- duplicate-order protection
- margin checks
- liquidation-distance controls
- reduce-only validation
- circuit breakers
- periodic reconciliation
- Agent permission verification
The objective is defense in depth.
A trading Agent should have only the authority required to perform the strategy, and the strategy runtime should itself reject actions outside the expected operating envelope.
---
Macro and Adaptive Shield Share the Same Perpetual Market
Supporting the complete TIYlab portfolio on a DEX introduced another important technical problem.
Macro and Adaptive Shield can both require BTC perpetual exposure.
A decentralized venue may maintain only one net BTC perpetual position for the account.
TIYlab therefore cannot simply pretend that Macro and Shield each have completely independent exchange positions.
The solution is an internal Composite Perpetual Exposure Manager.
Macro maintains its own economic target.
Adaptive Shield maintains its own economic target.
TIYlab combines those targets into the single position that must actually exist on the venue.
Conceptually:
Macro target + Shield target = actual required BTC perpetual exposure
TIYlab still tracks the strategies independently for accounting and decision-making.
Only the execution layer is netted.
This allows the strategy logic to remain unchanged while respecting the actual position model of the DEX.
---
Macro and DCA Also Share Spot Bitcoin
The same principle applies to spot holdings.
Macro and Adaptive DCA can both own Bitcoin economically even though the DEX sees one total spot balance.
TIYlab continues to maintain separate internal ownership:
- Macro allocation and lots
- DCA allocation and lots
- actual venue spot balance
This is particularly important for DCA recycling.
A profitable DCA lot must remain identifiable.
The DCA engine must never accidentally sell a losing DCA lot or consume Bitcoin economically owned by Macro.
The internal accounting remains separated even when the exchange balance is aggregated.
---
Capital Requirements
The generic TIYlab requirement is now expressed in USDT or USDC depending on the selected venue.
For the new DEX integrations:
Hyperliquid: minimum 2,000 USDC
Aster: minimum 2,000 USDT
Venue-specific wording remains intentionally precise rather than pretending all exchanges use the same stablecoin.
---
Does This Mean “No KYC”?
DEX accounts are wallet-based and do not require a traditional centralized-exchange account through TIYlab.
TIYlab itself does not perform KYC for DEX connections.
But we deliberately do not market the integration as a way to bypass KYC or regulation.
Protocol availability can vary by jurisdiction, wallet provider and applicable rules.
Users remain responsible for determining whether a venue is available and appropriate for them.
---
DEX Does Not Mean Risk-Free
Moving from a centralized exchange to decentralized infrastructure changes the risk model.
It does not remove risk.
DEX-specific risks may include:
- smart-contract risk
- protocol risk
- oracle risk
- liquidity risk
- funding risk
- liquidation risk
- stablecoin risk
- chain or validator risk
- infrastructure downtime
- API changes
- protocol upgrades
- bridge or custodial-wrapper risk where applicable
These risks are now documented alongside the existing trading and exchange risks.
---
TIYlab Now Supports 10 Trading Venues
The platform now supports:
CEX
Binance
Bybit
KuCoin
OKX
Bitget
Gate
MEXC
HTX
DEX
Hyperliquid
Aster
All with the same three-strategy framework:
Macro
Adaptive DCA
Adaptive Shield
And the same progressive onboarding:
Discover without trading access.
Verify without trading permission.
Automate only when you decide to go Live.
---
What Comes Next
The DEX integration does not change TIYlab's immediate priority.
The product is already technically broad.
The next challenge remains adoption.
The free simulation exists precisely so that users can evaluate TIYlab without first granting control over a real trading account.
Hyperliquid and Aster now extend that same approach to decentralized trading.
The objective remains simple:
one TIYlab portfolio framework, one venue selected by the user, three complementary Bitcoin strategies.
---
Try TIYlab
Website
https://tiylab.com
Free simulation
Available directly through TIYlab
Live tracker
https://tiylab.com/en/tracker
Documentation
https://tiylab.com/en/docs
Security
https://tiylab.com/en/security
Pricing
https://tiylab.com/en/pricing
Telegram
https://t.me/TIYlabBot
TIYlab is software for automated cryptocurrency trading.
Cryptocurrency and derivatives markets involve substantial risk of loss.
DEXs introduce additional technical, protocol, liquidity and smart-contract risks.
Backtests and past or live performance cannot predict future results.
Never invest more than you can afford to lose.