Troubleshooting.
Ordered by how often they happen. If your problem is not here, check the transaction on the explorer first — the revert reason is usually the answer.
“HTTP request failed” while browsing#
The public RPC is rate limited and a read-heavy page can lose a call. Reload. If it recurs, the explorer or a different network moment is usually the cause rather than your wallet.
This affects reading, not signing. Your transactions go through your wallet's own RPC.
A transaction was submitted but never confirmed#
Check before retrying. Open My locks or the explorer and look for the record. A lock that was created but whose receipt was lost looks identical to one that failed, and sending again creates a second lock and charges a second fee.
If the widget reported unconfirmed: true, that means exactly this: broadcast succeeded,
receipt unknown, most likely landed.
The approval went through but the lock did not#
These are two separate transactions and the approval is not wasted. It sits unused until you use it. Start the lock again; you should not be asked to approve the same amount twice.
If you are asked to approve again, the amount you are now locking is larger than what you approved.
My wallet does not appear#
| Situation | Fix |
|---|---|
| Desktop, extension installed | Unlock the extension, then reload. A locked wallet does not announce itself. |
| Mobile browser | Mobile wallets cannot inject into Safari or Chrome. Use WalletConnect or the wallet's in-app browser. |
| Several wallets installed | One can claim the injection slot. Pick yours explicitly from the list, or disable the others temporarily. |
More detail in connecting a wallet.
The network will not switch#
Some wallets refuse to add an unfamiliar chain automatically. Add Robinhood Chain by hand with the parameters on the network page, then reconnect.
If the network is already in your wallet but transactions fail to send, the saved RPC endpoint may be wrong. Remove the network and let the app add it again.
A vesting schedule reverted#
The contract enforces rules the form usually catches first. If you are building transactions yourself, these are the ones that bite:
| Rule | Requirement |
|---|---|
| Minimum duration | end > block.timestamp + 24 hours |
| Ordering | start ≤ cliff ≤ end |
| Fee | msg.value == fee exactly — overpayment is not refunded and reverts |
| Token | Must be a contract address, not an EOA |
The most common cause: the API validates end - start ≥ 86400 while the contract
validates against block.timestamp. A back-dated start passes the first and fails the
second. Validate against block.timestamp. See the API page.
My lock is not in the explorer#
- Give it a moment — the explorer reads from an indexer that can lag a block or two behind your wallet.
- Confirm the transaction actually succeeded on the explorer, not just that it was sent.
- Check you are looking at the right token address. Searching by symbol is not possible precisely because symbols repeat.
The token amount looks wrong#
Two usual causes. Decimals: if you are building transactions yourself, amounts are in the token's smallest unit, so a token with 18 decimals needs 18 zeros. Fee-on-transfer: the locker records what it actually received, so a token that taxes transfers will show slightly less locked than you sent. That is the honest number, not an error.
I sent tokens directly to a contract address#
Tokens transferred straight to the locker or burner address, rather than through the app, are not recoverable. There is no rescue function — that absence is the same property that stops anyone taking locked tokens. Always go through the app or the API.
Still stuck#
Open the transaction on the explorer and read the revert reason. It names the failing check directly, and the contract reference explains what each one enforces.