Vertexprotocol required deposits to complete additional account setup

Last updated 13 Oct, 2026

Vertexprotocol required a deposit to complete additional account creation in its August 2024 web app. Naming an account and choosing an avatar left setup unfinished until funding arrived. An unfunded account disappeared after the app was closed or refreshed. Each account had separate positions and risks under the same wallet. This onboarding flow preceded the exchange’s July 2025 shutdown.

The account selector determined the destination, while token allowance and deposit processing controlled different parts of funding. A transaction confirmation and the account’s credited balance could therefore answer different questions. Preparation could stop before the deposit transferred assets.

In the August 2024 app, naming an additional account did not complete setup; funding determined whether the account persisted.

Wallet access and the intended deposit destination

A connected wallet identified the owner, while the account selector identified the particular trading account that would receive a deposit. The August 2024 interface exposed account selection through the Portfolio page and Account Center. Creating an additional account involved its own name and avatar. Those display choices helped distinguish accounts, although funding remained necessary to finish creation.

The active selection governed deposits, trading information and account history in the web app. Its green dot marked the selected account. A wallet address therefore provided less information than the combination of that address and its chosen account. During setup, the destination needed to match the account being created.

Shared margin within an account and separation between accounts

Additional accounts had separate positions and risks, with cross-margin calculated within each account. Allocating capital across accounts split the available collateral even though the same wallet controlled them. Keeping eligible positions together preserved their shared margin calculation. This gave account organization a financial consequence beyond its name or avatar: assets assigned to another ordinary account did not automatically support the newly created one.

The funding requirement in the August 2024 app

In the August 2024 creation flow, refreshing or leaving the app before funding caused additional account setup to restart. A name and avatar could appear during preparation without establishing a persistent funded account. The deposit supplied the assets that completed that creation flow.

Assets held in the connected wallet remained outside the exchange account until deposited. Their appearance in a wallet balance did not establish collateral in the new account. Funding also had a different purpose from choosing a market or submitting an order. Completing account setup did not require opening a trading position.

Authorization and the transfer of collateral

Permission to spend a token

Token allowance authorized the deposit contract to spend the relevant assets. The Python SDK exposed allowance approval and allowance queries separately from deposits. Approval established spending permission; it did not itself credit the trading account.

Assets entering the protocol

A direct EVM collateral deposit moved tokens from the depositor through Endpoint to Clearinghouse. The deposit identified the recipient subaccount and the product whose balance would receive credit. Once that transfer succeeded, the assets had entered the protocol. Closing the app afterward could not undo the completed transfer.

Funding-source choices and token amounts

Direct collateral deposits and Checkout

The exchange supported direct collateral deposits and integrated Checkout, powered by FUN, into its deposit interface. Checkout added funding from a preferred token, a centralized exchange or a card.

View full-size image

The direct contract path used a product ID to identify a supported token. A token’s presence in a wallet was insufficient to establish that product mapping. Product selection also governed which asset’s balance the protocol credited, so the source of funds and the recorded collateral asset needed separate attention.

Value thresholds and token precision

The published EVM core set a minimum first-deposit value of 5 quote units for an ordinary unregistered subaccount, valuing the quote product at a unit price and other products using the protocol’s price feed. The deposit amount used the token’s smallest units. The check normalized that amount, with a maximum supported token precision of 18 decimals. Different token quantities could meet the same value threshold. For an ordinary unregistered subaccount, a deposit below that threshold was rejected before tokens transferred.

A transaction record and a credited balance

A successful token transfer and a credited subaccount balance described different states in the direct EVM deposit path. Endpoint transferred the assets and queued the collateral entry. Successful processing of that entry recorded the subaccount and applied the deposit to its balance. Blockchain confirmation of the funding transaction alone did not establish that later credit.

The Python SDK 0.1.0 deposit example returned a transaction hash. Its Subaccount API separately exposed an engine summary for a specified subaccount. The hash identified the transaction; the summary described the engine’s account state. Matching the recipient and product mattered because a balance in another account did not answer whether the intended destination received collateral.

The historical interface displayed information for the account marked as active. An unexpected balance could therefore reflect the selected account rather than a failed transfer. Account identity needed to remain consistent when comparing the deposit record with the displayed balance.

A submitted transaction established submission, and a successful receipt established execution of that transaction. A corresponding credited balance established the account’s funding state.

Funding and permission to open a position

A funded account had collateral, while the ability to add trading risk depended on its weighted Initial Health. The Market API handled orders separately from the Spot API’s collateral deposits. This separation allowed account funding and the first trade to remain distinct decisions.

The portfolio calculation included eligible balances, positions and liabilities within that account. When Initial Health fell below zero, the account entered Maintenance Mode and could not take additional risk. A positive token balance alone therefore did not establish unrestricted trading capacity. Borrowing and existing positions could change what the same funded balance supported.

The shutdown ended the old onboarding path

The old exchange was wound down following the team’s July 2025 agreement to join the Ink Foundation. The announced shutdown schedule set July 16, 2025 at 14:00 UTC as the start of the phase in which deposits would be disabled. Account-creation instructions from 2024 described the earlier operating exchange.

The transition also addressed VRTX token migration and plans for a new DEX on Ink. Trading-account funding and token-holder eligibility concerned different conditions. Depositing after the holdings snapshot could not change the balances captured at that earlier time. A later application could use different funding requirements or account controls, changing the setup procedure that applied to its users.