Smart Contract Development

A smart contract is code deployed to a blockchain that executes automatically when its conditions are met, and once live it is often difficult or impossible to change. LimeChain writes, tests and hardens contracts against explicit invariants, using fuzzing, static analysis and rehearsed deployment, and prepares the specifications and evidence an external auditor needs. Work spans Solidity on EVM chains, Rust on Solana and Daml on Canton Network.

How it works

Every engagement runs the same sequence, with the assurance level set by the value at risk rather than by a standard package.

  1. 1

    Pin down the rules and the risk

    Business logic, actors, assets at risk, chain, integrations, admin powers and measurable acceptance criteria.

  2. 2

    Size the assurance to the risk

    The testing and audit plan is set by novelty, immutability, privileged powers and value at risk, not by a standard package.

  3. 3

    Write the spec and the threat model

    State transitions, invariants, access control, external calls, upgrade and pause mechanics and failure cases, all testable.

  4. 4

    Prove novel logic early

    For high-risk logic we build a narrow reference path and its tests first, so behaviour and gas cost are inspectable.

  5. 5

    Implement with senior review on every value path

    Micro-sprints with weekly technical reviews, and manual review of all value-bearing and permissioned logic.

  6. 6

    Rehearse the deployment

    Configuration, signers, verification, upgrade, monitoring and pause procedures are rehearsed before production and ownership transfer.

Frequently asked questions

What languages and chains does LimeChain write contracts in?
Solidity for EVM chains including Ethereum, Polygon, Base and Scroll; Rust for Solana; Daml for Canton Network; and the native language of the target chain where it differs, including work on Hedera, NEAR, Polkadot, EOSIO and Hyperledger Fabric. Tooling includes Foundry, ethers.js, viem and wagmi. Chain and language are selected from the product's privacy, cost, settlement and ecosystem requirements during architecture.
What is an invariant and why does LimeChain start there?
An invariant is a statement that must always be true of the contract, such as total supply always equalling the sum of balances, or a vault never releasing more collateral than it holds. LimeChain defines invariants before implementation because they become the specification that fuzzing and property testing check automatically. Contracts written without stated invariants can only be tested against the behaviour their author already imagined.
How do you test smart contracts?
Unit and integration tests, branch and invariant coverage, property-based testing, fuzzing against the stated invariants, static analysis, gas review, fork testing against real chain state where integrations matter, and adversarial cases derived from the threat model. Results are kept as traceable evidence mapped to the specification, so an auditor or your own team can see what was checked and what was not.
Do you get contracts audited by a third party?
LimeChain performs internal security review and prepares the specifications, invariants and traceable evidence an external auditor needs, then coordinates independent audit where the value and risk profile require it, and remediates and retests the findings. Independent audit is a separate engagement with a specialist firm. LimeChain does not present its own review as equivalent on value-bearing contracts.
Should our contracts be upgradeable?
Upgradeability trades one risk for another: an immutable contract cannot be fixed, and an upgradeable contract gives someone the power to change the rules under existing users. LimeChain decides this per contract with you, and where upgradeability is used it specifies who holds the power, what timelock applies, what is announced to users, and which parts are deliberately made immutable so the guarantees stay credible.
Can you review or fix contracts we already have?
Yes. Common work includes reviewing a codebase before an audit, remediating audit findings, adding test and invariant coverage where there is little, upgrading to a newer standard or framework, and gas optimization. LimeChain will state clearly where a rewrite is safer than a patch, particularly where the original design lacks the access control or upgrade structure to be fixed cleanly.
Purple glow half

Have a project in mind?
Drop us a line.

Or just shoot us a message on Telegram

Open Office Hours: Web3 Founders Edition