DeFi systems rely on two foundations: contracts that behave as intended and keys that authorise actions safely. Exploits have shown that both layers are attractive targets. A robust security program does not treat contracts and wallets as separate topics. It looks at how they interact and how an attacker would move between them.
Understanding the wallet threat model
Hot, warm, and cold layers
Wallets are not all the same. The tradeoff is always between availability and exposure.
- Hot wallets sit on internet connected machines and sign frequently. They are ideal for operations that need speed, but they sit near a lot of untrusted code.
- Warm setups use hardware modules or partially isolated systems with more friction but more control.
- Cold setups hold keys offline and are suited for reserve or treasury holdings.
For a DeFi protocol:
- Treasury reserves and long term holdings belong in high threshold, low frequency setups
- Protocol operations such as paying incentives or rebalancing positions can use more active wallets with tighter limits and monitoring
Failure patterns in multisignature wallets
Multisignatures reduce reliance on a single key, but they can still fail:
- Signers use the same laptop and browser they use for everything else
- The threshold is too low and a compromise of one or two machines is enough
- Role definitions are blurred, so a signer has both engineering and treasury responsibilities
- No process exists for rapid rotation of compromised signers
Good multisignature practice requires:
- Independent devices and networks for signers
- Clear thresholds per action type and per wallet tier
- Documented rotation procedures triggered by staff changes or suspected compromise
MPC systems and policy engines
Multi party computation based wallets split key material and compute signatures jointly. The blockchain sees a single signature, but behind that sit:
- Policy engines that decide which transactions are allowed
- Logging subsystems that record approvals and policy decisions
- Integrations with identity providers and ticketing systems
If those components are not well designed and controlled, the abstraction of “many independent signers” becomes weaker than it appears.
Smart contract risk patterns
Certain contract failures recur across DeFi.
- Access control that is too permissive or poorly structured
- Accounting errors around share issuance, fee accrual, or collateralisation
- Unanticipated interactions with other protocols, such as lending loops or reentrancy across calls
- Overreliance on oracles without considering liquidity, latency, or manipulation cost
- Upgrade paths that allow logic replacement without sufficient oversight
Example of a fragile pattern:
contract Vault {
address public owner;
mapping(address => uint256) public balances;
function withdraw(uint256 amount) external {
require(balances[msg.sender] >= amount, "insufficient balance");
balances[msg.sender] -= amount;
(bool ok, ) = msg.sender.call{value: amount}("");
require(ok, "transfer failed");
}
function setOwner(address newOwner) external {
require(msg.sender == owner, "not owner");
owner = newOwner;
}
}
This simple contract fails to track total supply, has no emergency controls, and uses a generic call for withdrawals that can interact poorly with other contracts. In a production DeFi system, patterns are more complex but similar risks appear.
Designing stronger wallet architecture
A more robust wallet design for a DeFi protocol has a few elements.
Tiered wallets
- Reserve wallets with high thresholds, slow change paths, and strong separation from operations
- Operational wallets with constrained limits, thresholds tuned to daily tasks, and fine grained monitoring
- Development and testing wallets with no direct link to production assets
Policy based approvals
Rather than relying on human intuition when signing:
- Encode rules based on destination, function selector, and amount
- Enforce additional approvals or time delays for unusual transactions or new counterparties
- Use dedicated policy engines for MPC environments and carefully review their configuration
Approval hygiene
Token approvals are a persistent vector for loss.
- Limit allowances by amount and purpose
- Regularly scan allowances for operational and treasury wallets and revoke unused permissions
- Design user facing contracts to encourage bounded approvals by default
Designing stronger contract systems
Explicit invariants
Before writing code, define what must always be true:
- Conservation of value across pools or vaults
- Limits on leverage, utilisation, or exposure
- Bounds on price impacts and rate changes
These invariants should be encoded into the contract and enforced where possible, then tested under varied conditions.
Access and governance
Contracts should make it clear which roles can:
- Change parameters
- Move funds
- Upgrade logic
- Pause or resume operations
These roles should be mapped to governance processes and monitored addresses, not to anonymous externally owned accounts.
Stress and composability testing
DeFi contracts rarely operate alone.
- Simulate interactions with other lending protocols, AMMs, and aggregators
- Test behaviour when collateral values change rapidly or liquidity is thin
- Evaluate how contracts respond when dependent systems are degraded or paused
Action plan for contract and wallet security
- Build an inventory of wallets and contracts by function and exposure.
- Move high value balances into structured multisignature or MPC setups with clear policy and thresholds.
- Introduce transaction policies and require approvals that reflect risk, not just convenience.
- Clean up token approvals and integrate allowance management into regular operations.
- For key contracts, commission audits that cover design, invariants, access control, and composability, and complement them with fuzzing and simulation.
- Document and test procedures for key rotation, signer replacement, and emergency contract actions.
How Spearbit audits smart contracts and wallets
Smart contract and wallet audits at Spearbit integrate both layers.
- On the contract side, we analyse architecture, economic and logical invariants, upgrade mechanisms, and cross protocol interactions
- On the wallet side, we evaluate multisignature and MPC design, transaction policies, approval patterns, and key management workflows
- We map plausible attacker paths that move between offchain and onchain components
- We provide concrete changes to contract code, governance design, wallet tiering, and operational procedures
For DeFi protocols that anchor value and interact with many other systems, this integrated view is essential. Contact us for a full assessment.