Smart contract development for financial infrastructure

Write the economic contract before Solidity

A function signature tells an integrator how to call a contract; it does not establish what the function is allowed to do economically. Start with the assets, claims and obligations the system represents. Define the unit of account, rounding direction, fee ownership, accrual rules and conditions under which value may leave.

For each operation, document the preconditions, authorized actor, expected transfers, state changes and postconditions. A redemption callback, for example, needs more than an amount and recipient: it needs a request identity, proof of authority, permitted state transition and treatment of partial or repeated settlement.

Translate the design into invariants that remain true across sequences. Reserved collateral cannot be withdrawn. Repayment cannot erase more debt than the accounting rules allow. A cancelled authorization cannot execute. These statements guide implementation and testing, and give reviewers a concrete definition of a defect beyond whether the code compiles.

Minimize the authority of every integration

Map trust boundaries before splitting the code into modules. Identify contracts that can transfer assets, update prices, modify limits, authorize trades or change implementation code. An external dependency should receive the smallest authority needed for its task, including bounded approvals and narrowly scoped callbacks.

Token behavior deserves specific attention. Transfers can fail, return unusual values, apply fees or invoke other code. An adapter's return value is not always proof of an actual asset movement. Decide which token behaviors are supported, how received amounts are measured and how unsupported assets are excluded.

The Solidity security considerations describe reentrancy, external-call risks and gas-bounded execution. Those language-level concerns must be applied to the complete financial state machine. A local guard can protect one entry point while another module still observes or mutates the same intermediate accounting state.

Treat arithmetic choices as protocol rules

Fixed-point calculations need explicit scales. Price feeds, token balances, share indexes and fee rates may use different decimal conventions. Normalize deliberately, preserve precision in intermediate calculations and document where rounding occurs. A variable named value should reveal whether it means token units, normalized value or account shares.

Test the economic direction of every conversion. A user should not be able to repeat a deposit-withdrawal or borrow-repayment cycle to extract value from rounding. Minimum quantities and dust rules should address an identified accounting behavior, not conceal an unexplained mismatch.

Conservation checks need to account for all legitimate destinations: user balances, accrued interest, protocol fees, reserves and recognized losses. Define tolerances from the arithmetic model. A broad tolerance that makes tests pass can hide a systematic transfer. Independent reference calculations are especially useful when several products reuse the same math library.

Build evidence across examples and sequences

Unit tests establish specified examples and boundary conditions. Property tests explore many inputs. Stateful invariant tests explore sequences that an engineer may not enumerate manually. Foundry's invariant-testing documentation describes tooling for that sequence-oriented approach. Test quality still depends on meaningful properties and reachable states.

A lending-and-execution system should test joined workflows: supply, borrow, trade, accrue interest, transfer collateral, partially liquidate and settle an external receivable. Track an independent model of assets and obligations, then compare at each checkpoint. Include actors that lack permissions and dependencies that revert or return unexpected results.

Fork tests verify assumptions about actual deployed dependencies at a pinned block. They complement local models rather than replace them: the historical state may not include an outage, upgrade or malicious token behavior. Preserve failing random seeds and minimized sequences so a fix can be reviewed against the original defect.

Specify who can change the rules

Administrative code is part of the product's trust model. Define distinct roles for asset admission, risk parameters, emergency controls, treasury operations and upgrades. A role that changes an oracle can indirectly change borrowing and liquidation outcomes even if it cannot transfer tokens directly.

OpenZeppelin's access-control guidance provides implementation patterns for ownership, roles and delayed administration. The engineering specification must still decide which changes need delay, which emergency actions are immediate and how authority is recovered or revoked.

Test administration like an ordinary user flow. Include unauthorized calls, role transfers, revocation, queued changes, cancellation and the state after an emergency action. Ensure monitoring can identify the active configuration and pending changes. A delay provides time to react only if somebody can observe the proposal and has a workable response.

Make deployment reproduce the reviewed system

A review of source code does not establish that a deployment uses that source, its intended parameters or the correct administrator. Pin dependencies and compiler settings, record build artifacts and verify deployed bytecode and configuration. Deployment scripts need checks for chain identity, addresses, roles, oracle units and asset limits.

For proxy-based designs, initialization and storage compatibility are explicit review areas. OpenZeppelin's upgradeable-contract guidance explains initializer and storage-layout constraints. An upgrade plan should test existing positions and pending operations, not only a fresh deployment.

Some contract changes cannot be undone by restoring an earlier implementation because the new version has already changed state. Define whether recovery means a compatible upgrade, a controlled migration, a pause or an orderly unwind. Rehearse the chosen procedure with realistic balances and permissions before relying on it during an incident.

Deliver an operating system, not just contract addresses

The engineering handoff should include a state-machine specification, dependency inventory, role map, test evidence, deployment manifest and incident procedures. Integrators need event semantics, error behavior, decimal conventions and guidance about chain finality. Operators need to know which alerts require immediate action and who can perform that action.

Independent review can add valuable scrutiny, but it does not replace specifications, tests or operational controls. Record review scope and unresolved assumptions accurately. The appropriate first exposure limit depends on the evidence available for the actual implementation and its dependencies.

Common engineering questions