Contracts and protocols,
read line by line.

What a smart contract is

A smart contract is a program stored on a blockchain. Anyone can call it; every node runs it and agrees on the result; and once deployed, its code cannot be quietly changed. That combination is the point: rules that hold without trusting whoever operates the system.

It is also the risk. The code is public, it often holds money, and a mistake cannot be patched the way a web server can. Contracts are best written as though the first person to read them closely will be an attacker, because often it is.

Testing that matches the stakes

Unit tests check the cases you thought of. Contracts need tests for the cases you didn't.

• Fuzz tests call a function with thousands of generated inputs and check that a property holds for all of them.
• Invariant tests go further: they call the contract's functions in random sequences, from random callers, and check after every call that something that must always be true still is.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

import {Test} from "forge-std/Test.sol";
import {Vault} from "../src/Vault.sol";

contract VaultInvariants is Test {
    Vault vault;

    function setUp() public {
        vault = new Vault();
        targetContract(address(vault));
    }

    /// Whatever anyone does, the vault can pay everyone back.
    function invariant_solvent() public view {
        assertGe(address(vault).balance, vault.totalDeposits());
    }
}

An invariant like this states what the contract promises in a form that runs on every change. We write contracts in Solidity and test them with Foundry.

Gas

Every operation on-chain has a cost, paid by whoever calls the contract. Storage writes dominate; reading storage, looping over arrays and making external calls follow. Gas profiling finds the hot paths, the functions users call most, and makes them cheaper without making them harder to read. Changes are measured before and after, not assumed.

Rollups

Rollups execute transactions off the main chain and post the results back to it, inheriting its security while costing far less per transaction. They differ in how the main chain is convinced the results are correct.

• Optimistic rollups assume results are valid and allow a challenge window during which anyone can submit a fraud proof. Withdrawals wait for the window to close.
• ZK rollups post a validity proof with every batch. The main chain verifies the proof, and the results are final as soon as it does.

Both depend on data availability: the transaction data must be published somewhere users can retrieve it, or they cannot reconstruct their balances or exit if the operator disappears.

Bridges

A bridge moves assets or messages between chains. The hard question is always the same: how does chain B know that something really happened on chain A?

• A committee or multisig attests to it. Simple, fast, and only as secure as those keys.
• A light client on chain B verifies chain A's consensus directly. Stronger, and more expensive.
• A zero-knowledge proof of chain A's state, verified on chain B, aims for the light client's security at lower cost.

Bridges have been behind several of the largest losses in the industry, usually through the trust model rather than an exotic bug. Reading a bridge starts with writing that trust model down.

Audits, and what comes before them

A formal audit is an independent review before mainnet, and serious projects should have one. A pre-audit teardown comes earlier: a line-by-line read that finds the obvious and not-so-obvious problems while they are cheap to fix, so the audit can spend its time on the subtle ones. It is not an audit, and it should say so. What a pre-audit teardown is (and isn't) goes into the detail.

How Rump Labs works in blockchain

We write Solidity with Foundry, fuzz and invariant tests, profile gas on hot paths, work through rollup and bridge mechanics, and run pre-audit teardowns that tell you what an attacker can do before mainnet does.

The Contract Sprint has two tracks. The build track delivers one Solidity contract to spec, with full tests and a testnet deployment. The teardown track is a line-by-line review of up to 500 lines, graded by severity, with a written report on assumptions, trust model and what an attacker can do. Both are pre-audit work, and we say so in writing; build output goes on to a formal audit, and teardown output usually becomes a fix sprint.

We teach it too: an invited talk on zero-knowledge proofs and blockchain at Blockchain Summit 2.0, IIT Kharagpur, followed by two days mentoring the hackathon teams.

Where it shows up

Wherever a record has to be shared, and no single party should be able to edit it.

Where to start

Further reading