Safety

Verify the application and network#

Use a verified application location and the configured Robinhood Chain environment. Do not follow unsolicited messages asking you to “verify” a wallet by entering secrets. A design reference, demo screen, or brand asset is not evidence that a live deployment is official or secure.

Review token spending permissions#

For a token approval, inspect the token, spender, requested allowance, and relevant expiry. ERC-20 allowances permit another contract to spend up to the approved amount.^[1] A connection request, an approval, a permit signature, and a swap can have different consequences.

The intended interface should request only the permission needed for the selected action unless the user explicitly chooses and understands a broader allowance. Disconnecting a wallet from a website does not by itself revoke on-chain allowances. Review and remove unnecessary approvals using a verified process.

Review the trade#

Check the token identities, recipient, input amount, expected net output, price impact, minimum received, fees, and quote expiry. Refresh changed or expired quotes. Do not solve every execution error by increasing slippage.

A simulation can identify some failures but is not a security audit or a guarantee of future execution. A multi-pool diagram does not eliminate token or contract risks.

Understand transaction status#

Submitted, confirmed by a receipt, and fully finalized are distinct milestones. Robinhood Chain documents different finality stages.^[2] If a transaction is already submitted, closing a panel does not cancel it. A timeout in the application's RPC provider is not proof that the network transaction failed.

A reverted on-chain transaction may still incur network costs.^[3] Check the receipt before retrying and avoid sending duplicate transactions when the status is unknown.

Common risks#

Smart-contract defects, malicious token behavior, low liquidity, volatile pricing, misleading metadata, harmful spending approvals, infrastructure outages, and phishing can cause loss or prevent execution. Token-specific transfer restrictions can also affect whether a quoted path can complete.

Do not interpret recognized, route available, or listed as a promise of value or safety. Check the actual contract identity and any relevant restrictions.

Security disclosures#

No QuiverDex audit report, deployed contract addresses, or security-review evidence was provided with this UI package. A public security page must identify the actual deployed contracts and any published reviews accurately. If an audit is later published, include its scope, date, code version, findings, and limitations.

Frontend safeguards and the tests in the UI handoff do not replace contract review. Do not show an “Audited” badge without the corresponding evidence.

Getting help#

Use only support channels verified by the project. A support request can include the transaction hash, selected network, timestamp, and non-sensitive error message. It must not include private keys, recovery phrases, or unrestricted signing requests. Read FAQ before repeating a failed action.