Aster security is a contract-permission and withdrawal control process

Aster security is a risk-control process that confirms what a wallet is authorizing, where deposited assets move and whether funds return through the intended network. For Aster Pro, the decisive checks are the signed message, ERC-20 allowance or Solana program instruction, agent permissions, builder fee cap, contract address and completed test withdrawal. These checks separate a wallet connection from spending authority and separate trading authority from withdrawal authority. They also expose dependencies outside the wallet, including Aster’s internal account ledger, Ceffu custody for USDF reserves and blockchain confirmation. The sections below turn those trust boundaries into a repeatable pre-deposit workflow with concrete stop conditions.

Walk through permissions before the first deposit

Three Aster permission checkpoints should precede the first deposit: identify the network, decode the authorization and prove the return path with a small transfer.

Match the network and address format

BNB Chain, Ethereum and Arbitrum use 20-byte EVM addresses rendered as 40 hexadecimal characters after the 0x prefix. Their chain IDs are 56, 1 and 42161. Solana uses 32-byte public keys encoded in Base58. That distinction matters because an EVM-shaped address does not validate a Solana destination. Compare the selected network, token contract and receiving address in MetaMask, Rabby, Binance Wallet or a WalletConnect session before authorizing the transaction.

Read the requested action

A connection signature proves control of the wallet; it does not move an ERC-20 token. An approve call creates an allowance for a named spender, while a deposit or transfer changes balances. On Solana, inspect the program ID, accounts and token mint rather than searching for an ERC-20 allowance. The action shown by the wallet should match the next visible step in Aster.

Prove the exit before adding size

Use one small amount that remains meaningful after network fees. Complete the entire cycle before adding collateral:

• Record the wallet address and selected network.
• Confirm the token contract or Solana mint.
• Read the spender, program and authorized amount.
• Deposit the small test amount into Aster Pro.
• Withdraw part of it and confirm the receiving chain record.

How should a test withdrawal be structured?

One Aster test withdrawal should reproduce the planned route with limited value, a known destination and an independently visible blockchain transaction.

The sequence begins after the deposit appears in Portfolio. Close or reduce any exposure that would leave a negative asset balance, select the same network used for the test and send a deliberately small amount to the original wallet. Wait for the Aster status to complete, then check the receiving address in BscScan, Etherscan, Arbiscan or Solscan. A success label inside the interface is only one record; the destination balance and transaction record complete the test. Keep enough native gas to move the received asset again, because receipt without usable gas leaves the next action unfinished.

Aster Pro settles in USDT and supports multiple collateral assets. Realized losses, funding fees and commissions can create a negative balance in one asset. The withdrawal screen requires that deficit to be resolved through a deposit or the rebalance function, which appears as an auto-conversion in transaction history.

The published route references distinguish account processing from confirmation time. BNB Chain USDT lists 80 seconds for deposits and 8 seconds for withdrawals. Arbitrum USDC lists 6 minutes and 5 seconds, while Ethereum ETH lists 6 minutes 20 seconds and 10 seconds. Solana USDC lists 10 seconds and 5 seconds. Actual arrival still follows blockchain confirmation and service controls.

A delayed result becomes actionable when the chain record, Aster status and wallet balance disagree. Save the transaction identifier, network, asset, amount and destination address before changing settings or resubmitting. That evidence distinguishes a confirmation delay from an internal balance condition and prevents duplicate transfer attempts.

Wallet connection, token approval and agent authority are separate layers

Three distinct approvals govern Aster access: a login signature, a token allowance and delegated agent authority for API or builder workflows. This separation is central to Aster security because each action grants a different capability. MetaMask and Rabby show login signatures as messages, while ERC-20 approvals name a spender and amount. Aster agents add spot, perpetual and withdrawal switches, plus an expiry, IP whitelist and builder fee cap.

Aster Pro withdrawals expose the internal-account dependency

Four supported network routes feed Aster Pro’s account system, so direct wallet control ends when the deposit transfer reaches that account, which is discussed in Aster questions.

The Portfolio balance is an account claim used by the order book and matching engine, not simply a token balance at the connected address. A withdrawal therefore depends on the internal ledger recognizing available collateral, the chosen chain remaining operational and the transfer passing platform controls. This workflow differs from a direct wallet-to-contract swap that settles output to the same address in one on-chain transaction.

The trust boundary becomes visible in three records: the wallet’s deposit transaction, the Aster account credit and the later withdrawal transaction. If one record is missing, increasing collateral enlarges the unresolved dependency. A completed round trip demonstrates that the selected asset, account and network work together for that wallet.

Asset wrappers add custody and strategy dependencies

Three asset forms - USDT, USDF and asUSDF - create different withdrawal paths even when their displayed values appear closely related.

USDT collateral

USDT deposited into Aster Pro functions as the settlement asset for trading. Withdrawing it follows the Pro account route, while holding it in a personal wallet retains direct token control. USDT also carries an issuer dependency on Tether and the selected blockchain’s token contract.

USDF redemption

In that configuration, Aster’s USDF redemption path converts USDF to USDT at 1:1, charges 0.1% and processes most requests in 1–2 days, with larger requests taking up to 7 days. Minting USDF transfers corresponding USDT into a managed reserve process involving Ceffu and a delta-neutral strategy connected to Binance liquidity. Redemption therefore adds reserve availability, custody operations and a claim step beyond a normal ERC-20 transfer. PancakeSwap offers a market swap route instead, where pool price, fee and liquidity replace the queued redemption terms at execution. One path uses Aster’s defined redemption process; the other accepts an automated market maker quote that can deviate from the 1:1 conversion.

asUSDF claim step

asUSDF represents staked USDF, so exiting requires an asUSDF-to-USDF claim before any later USDF-to-USDT redemption. Each conversion has its own status and output asset. Ceffu holds ISO 27001 and ISO 27701 certifications and SOC 2 Type 1 and Type 2 reports, yet those controls do not collapse the multi-step asset path into a single wallet transfer.

Which withdrawal signals deserve a pause?

Five observable Aster withdrawal signals deserve a pause: an address mismatch, broader permission, negative balance, missing chain record or unexpected asset output.

An address mismatch means the token, spender or destination differs from the intended route. Broader permission appears when canWithdraw is true for a trading-only agent, an ERC-20 allowance exceeds the planned deposit or a builder fee cap is absent from the message. A negative balance blocks Aster Pro withdrawals until deposit or rebalance resolves it. A missing chain record means the interface status lacks settlement evidence. An unexpected output, such as slisBNB after an asBNB withdrawal, requires understanding the product’s defined redemption asset rather than assuming the input token returns unchanged.

Status alone does not identify the layer that stopped progress. Compare the wallet prompt, Aster transaction history, chain explorer and receiving balance in that order. The first disagreement identifies whether the next step belongs to permission review, account reconciliation, network confirmation or asset conversion.

API delegation needs tighter limits than manual trading

Ten seconds is the maximum permitted difference between server time and the microsecond-precision nonce used by Aster’s combined agent-registration authorization.

Agent permissions

An Aster agent exposes three boolean switches: canSpotTrade, canPerpTrade and canWithdraw. A trading integration needs the first or second switch, while withdrawal should remain false unless the workflow explicitly sends funds. The agent also carries an expiry timestamp in milliseconds. Short expiry and a narrow IP whitelist reduce the authority that survives after a session or backend change.

Builder fee caps

A builder approval remains separate from agent approval even when both appear in one Enable Trading flow. The user signs a maximum fee rate, and each order’s feeRate must stay at or below that cap. A registered builder must maintain at least 100 ASTER in its Aster contract account. Deleting the builder removes its fee authorization.

Signed domain parameters

The combined registration path supports two signing algorithms: EIP-712 with hexadecimal encoding for EVM addresses and Ed25519 with Base58 for Solana addresses. Its EIP-712 domain uses version 1 and a 20-byte zero address as verifyingContract. The endpoint assigns signature chain ID 56 to EVM addresses and 101 to Solana addresses. These fixed parameters make the expected authorization environment visible:

When should permissions be revoked?

One unused Aster permission should be revoked immediately after the related trading, builder or withdrawal workflow ends, rather than waiting for wallet cleanup. Delete an agent to disable its signer, delete a builder approval to remove its fee authority and set an ERC-20 allowance to zero when the spender no longer needs tokens. Revocation does not close open positions or reconcile negative balances, so complete those account actions first. A confirmed receiving balance closes the Aster security loop.