Smart Contracts and DeFi: Token Approvals, Oracles and Bridge Risk
“Connect wallet” does not always mean read-only access. The following signature may approve token spending, swap, deposit, borrow, bridge or vote, and a malicious contract or broad allowance can affect assets beyond the visible transaction. This guide treats open source, an audit and high TVL as evidence—not guarantees—and maps authority, dependencies, loss propagation and exit tests.
Who this guide is for: People connecting wallets to DEXs, lending, liquid staking, bridges, NFT markets or other applications
Key points to understand first
- Verify network, contract address, proxy implementation and deployment through official sources.
- Read wallet connection, message signature, transaction and token approval as separate authorities.
- An audit covers a version, scope and time; it cannot prove the absence of bugs or admin risk.
- Build a dependency graph including oracle, bridge, frontend, multisig, stablecoins and liquidity, then test the exit.
One transaction relies on several contracts and external systems
- Wallet signatureChain ID, function, amount and deadline
- Token approvalSpender, allowance and expiry
- CollateralPrice, liquidity and liquidation
Execute state, collateral and accounting
- OracleSource, heartbeat and fallback
- Admin keysUpgrade, pause, guardian and multisig
- Bridge/frontendMessage verification, DNS and UI
Start with contract identity and authority
A smart contract is code deployed at a blockchain address that changes state when a transaction calls it. Automatic execution does not mean the code is correct, administration is absent or the result is fair. Reconcile the official domain, docs, repository, deployment list and explorer-verified source. Record chain ID, proxy, implementation, version and creation transaction.
A counterfeit frontend can use a legitimate protocol name while requesting a malicious signature. Enter through a saved official URL and check the wallet network and contract. An upgradeable proxy separates the address users call from the logic implementation. Review upgrade delay, timelock, multisig signers and emergency pause.
| Layer | Verify | Failure example |
|---|---|---|
| Domain/frontend | Official link, TLS, DNS, app version | Clone or compromised interface |
| Network | Chain ID, RPC and explorer | Wrong chain or malicious RPC |
| Contract | Address, verified code and proxy | Fake token, old version, implementation swap |
| Function | Method, arguments, value and deadline | Blind signature or unlimited approval |
| Authority | Admin, multisig, timelock and guardian | Instant upgrade or single key |
Use addresses and chain IDs as evidence, not display names.
An approval delegates future spending rather than sending immediately
ERC-20 approve/allowance sets how much a spender can transfer for a holder. It is useful for swaps but an unlimited allowance can expose a later wallet balance if the spender is compromised, upgraded or abused. The approval transaction may move no token and can be forgotten; disconnecting a wallet from a site does not remove the on-chain allowance.
Verify spender, token, amount, expiry or permit deadline and chain; approve only what is needed. Revocation also needs a transaction and gas. Use explorer or protocol-linked tools rather than a search result. For NFTs, setApprovalForAll can authorize an operator over an entire collection.
exposed amount ≈ min(current wallet token balance, active allowance)aggregate exposure = Σ exposed amount by token and spenderrevoke priority = value exposed × spender risk × time remainingActual transfer ability depends on the token, permit and contract implementation.Put code defects and administrator powers in separate columns
Contract risks include reentrancy, access control, precision, unsafe external calls, flash-loan economic exploits, front-running, denial of service, bad upgrades and accounting errors. Open source does not mean every path has been reviewed. Compiler, library, oracle, non-standard token behavior and governance changes expand the attack surface.
For an audit, read firm, date, commit, scope, severity, unresolved findings, remediation and re-audit. Later code or parameters can be outside scope. Compare bug-bounty limit with assets at risk and inspect whether a pause is controlled by one key or a concentrated multisig. Long operation is useful evidence but not a guarantee.
Stress price source, update delay and liquidation together
Lending and derivative protocols use oracles to value collateral and debt. Review source venues, median or TWAP, heartbeat, deviation threshold, fallback and stale-price handling. A thin spot market, delayed update or venue concentration can produce manipulation or incorrect liquidation.
Health can deteriorate when collateral falls, borrowed assets rise, interest accrues or governance changes a collateral factor. Include liquidation bonus, close factor, auction, network congestion and gas competition in the scenario.
adjusted collateral = collateral market value × collateral factorhealth ratio = adjusted collateral ÷ debt market valueliquidation risk rises near the protocol thresholdUse the protocol’s exact formula, factors, oracle and rounding.A bridge adds another verification system; it does not simply move an object
A bridge can lock and mint, burn and mint, or use a liquidity network. Chains do not naturally trust each other’s state, so a light client, validator set, multisig, oracle, relayer or fraud-proof system verifies messages. Identify who can stop a false message and the delay before finality.
After an exploit, a wrapped token can remain on the destination while backing is lost. Pauses, premature finality, compromised upgrades and depleted liquidity are distinct failure paths. Apply the balance-sheet logic from stablecoin reserves and redemption to original assets, bridge liabilities, wrapped supply and exits.
- Verification: Native/light-client, optimistic or external validators?
- Finality: Source confirmation, challenge period and destination credit?
- Control: Upgrade, pause, rate limit, multisig and guardian?
- Exit: Canonical redemption, secondary pool and emergency recovery?
Use a dedicated wallet, simulation, small amount, revocation and exit test
Do not connect a long-term custody wallet to an unknown application. Limit an interaction wallet balance. Enter from an official link, verify network, contract and function, read simulation and minimum received, and test a small deposit through withdrawal or repayment. Limit approvals and inspect remaining balance and allowances afterward.
- Build the dependency graph
List contracts, proxy, oracle, bridge, administrator and frontend.
- Read assurance
Save audit commit, unresolved findings, bounty and incidents.
- Test with a dedicated wallet
Limit balance and approval; read simulation.
- Complete the exit
Withdraw, repay, bridge back and revoke.
- Preserve evidence
Record transaction, contract, amount, fee, status and review date.
Use the Financial Templates Hub to record public addresses, contracts, allowances, audits, dependencies and exits—never seeds or private keys. Free TradingView indicators can add chart context but do not determine contract safety, oracle correctness or protocol solvency.
Frequently asked questions
Does disconnecting a wallet remove token approvals?
Usually not. Disconnecting removes frontend access; an on-chain allowance remains until a revocation or change transaction.
Is an audited DeFi protocol safe?
An audit cannot guarantee safety. It covers a version and scope at a point in time and leaves code, economic, admin, oracle, bridge and later-change risk.
Where should a contract address be verified?
Cross-check official documentation and deployment pages against explorer-verified contracts, and match the chain ID. Do not rely on a social post.
Why are bridges a common risk concentration?
They add contracts and message verifiers across chains, often hold large pooled assets, and depend on upgrade keys, oracles, multisigs or liquidity.
Primary sources and verification links
- Solidity Documentation | Security ConsiderationsSecurity considerations for reentrancy, external calls, transfers and public execution
- Ethereum Improvement Proposals | ERC-20 Token StandardStandard interface and allowance mechanics for fungible tokens
- Ethereum Improvement Proposals | ERC-721 NFT StandardIdentification, ownership, transfer and metadata rules for non-fungible tokens
- ethereum.org | BridgesBridge designs and trade-offs in verification, connectivity, cost and security
- ethereum.org | Gas and feesTechnical explanation of gas used, gas price, base fee and priority fee
Edited and published by: SG Group · Editorial approach: We prioritize primary materials from central banks, regulators and international institutions. Rules, product terms and release times can change, so verify current information at the linked source and with your provider before acting.
Important notice: This article is general education about crypto assets, blockchains, wallets and related services. It is not investment, legal or tax advice; a recommendation of any token, exchange, wallet or protocol; a trading signal; a price forecast; or a guarantee of profit or principal. Crypto assets can lose some or all value through volatility, lost keys, mistaken transfers, fraud, smart-contract failure, depegging, illiquidity, provider insolvency, or regulatory and tax changes. Figures are fictional learning examples unless expressly identified otherwise. Before use, verify the network, contract address, fees, registration or regulatory status, terms and tax treatment with primary sources and qualified professionals.