TORQ
TORQ explains governed credit operations for digital and tokenized assets.
- 03 OCT 2026
- 5 min read
Vault standards and withdrawals
The share interface, asynchronous request lifecycle, and a vault's actual cash policy are separate integration questions. Compare the methods before promising a withdrawal journey.
A tokenized vault can expose ERC-4626 shares while its exit experience depends on available cash, limits, and possibly a separate asynchronous mechanism.
An integrator should inspect the actual contract interface before mapping a user-facing Withdraw button to a method.
ERC-7540 extends ERC-4626 with standardized request and claim stages. TORQ's documented V2 vault instead uses a native FIFO redemption path.
These paths have different method signatures and claim semantics.
Three questions, three interface layers.
- What do shares represent?
- Standard or interface: ERC-4626 standardizes a tokenized vault share and deposit, mint, withdraw, and redeem interface.
- Integrator implication: Read the asset, conversions, previews, limits, and vault-specific terms.
- How is a delayed request represented?
- Standard or interface: ERC-7540 adds request, pending, claimable, and claimed behavior to ERC-4626.
- Integrator implication: Implement its controller/operator and request lifecycle when the vault actually supports it.
- How does TORQ settle an exit?
- Standard or interface: TORQ V2 can pay liquid assets and queue the remainder as a fixed claim through its native request and fulfilment methods.
- Integrator implication: Track direct payment, request ID, queue state, fixed claim, and later fulfilment. Do not assume ERC-7540 views or claim calls exist.
A simplified TORQ native request.
Assume a valid redemption converts to a USD 100 asset claim, only USD 40 is immediately usable, and no other queue or policy condition applies.
In the documented native flow, the liquid USD 40 can be paid and the remaining USD 60 becomes a fixed queued claim. A later permitted fulfilment applies cash against that claim in FIFO order.
For this illustration, later NAV changes do not reprice the USD 60 claim. Recognized losses and the deployed terms still matter.
An ERC-7540 vault can define a different exchange-rate treatment between request and claim. The standard permits that variation.
The TORQ method signatures and claim lifecycle must be integrated as they are deployed. The native queue is not ERC-7540 compliance, and an adapter would require separate implementation and proof.
Checks before shipping a vault integration.
- Resolve the exact chain, vault address, ABI, asset, decimals, and share restrictions.
- Read current max and preview behavior without treating a preview as a payment guarantee.
- Identify whether an exit is atomic, request-based under ERC-7540, or governed by another native method.
- Represent pending requests, partial cash, fixed claims, eligibility checks, and final settlement distinctly.
- Verify a completed request through the vault's canonical application state and a reload, not solely a submitted wallet action.
