Verify contract source, deployment address, ownership controls, transfer restrictions and real sellability before approving a new swap contract. Use a tiny test, but remember a contract can treat addresses or amounts differently and may change if upgradeable.
Step-by-step process#
- Match address through official documentation. Keep the original timestamp, identifier and unedited record so another person can reproduce the conclusion.
- Check verified source and proxy implementation. Compare the live venue details with the written plan; do not rely on a chart label or a remembered setting.
- Review owner, blacklist, fee and pause functions. Compare the live venue details with the written plan; do not rely on a chart label or a remembered setting.
- Inspect recent successful buys and sells. Compare the live venue details with the written plan; do not rely on a chart label or a remembered setting.
- Limit approval and test with disposable funds. Keep the first exposure small enough that a wrong assumption can be corrected without a material loss.
The key idea#
Malicious routers and tokens can request unlimited approvals, route outputs to an attacker or allow buys while blocking sells. A polished interface does not reveal these controls.
For spot bad swap contract, separate what can be verified before acting from what can only be monitored afterward. Put hard limits around the second category.
When to stop or change course#
If you cannot identify the router or understand its authority, use an established DEX path or do not trade.
Failure modes to watch#
- Trusting an audit logo without scope. This removes a required input from the spot bad swap contract decision and makes the apparent result unreliable.
- Assuming renounced ownership removes proxy control. This removes a required input from the spot bad swap contract decision and makes the apparent result unreliable.
- Using token scanners as a guarantee. A label can look correct while the underlying destination differs, and a confirmed onchain action may be irreversible.
- Approving a router distributed by the token promoter. A label can look correct while the underlying destination differs, and a confirmed onchain action may be irreversible.
Evidence to keep#
Do not judge the outcome of spot bad swap contract only by whether the interface shows a success message. Use evidence that can still be checked after the page is closed.
| Checkpoint | Evidence | Stop condition |
|---|---|---|
| Match address through official documentation | Account history entry and a journal note showing the planned value | Trusting an audit logo without scope |
| Check verified source and proxy implementation | Account history entry and a journal note showing the planned value | Assuming renounced ownership removes proxy control |
| Review owner, blacklist, fee and pause functions | Account history entry and a journal note showing the planned value | Using token scanners as a guarantee |
Record actual fills, fees and remaining exposure for spot bad swap contract. The order ticket is an estimate; account history is the durable record.
Frequently asked questions#
Can a small successful sell prove safety?
No. Rules may depend on amount, address, block or later owner changes.
What is a honeypot token?
A token designed to allow entry while preventing or heavily taxing exit.
Does verified source mean safe?
No. It means published code matches deployment; the code can still be malicious.
Related guides#
Sources#
- Uniswap Support: Swaps and Troubleshooting
- Ethereum.org: Gas and Fees
- MetaMask: Transactions and Gas
Risk notice: Crypto trading can produce rapid losses. Examples are educational, not personalized financial advice; verify venue rules, fees and legal or tax obligations before acting.
Editorial standard
This guide is educational and source-led. Security controls, exchange rules and legal requirements can change; verify critical steps through the relevant official service before acting.
