Smart Contract Development

We design, build and harden smart contracts across EVM, Solana, Canton and other major blockchain ecosystems. Our work covers new contracts and existing code, with a focus on security, testing, performance and gas efficiency. We define contract invariants upfront and use them to drive fuzzing and property-based testing. A senior engineer reads every value-bearing contract line by line.

How it works

  1. 1

    Define the invariants

    We identify the conditions the contract must always satisfy and turn them into automated tests.

  2. 2

    Size assurance to risk

    We scope testing and audit against the value at risk, the novelty and the admin powers.

  3. 3

    Document permissions and upgrade paths

    We write down admin powers, pause switches and upgrade mechanics while you can still change them.

  4. 4

    Prototype novel logic first

    For mechanisms without precedent, we build a narrow version so you see behavior and gas cost early.

  5. 5

    Review every value path

    We hold weekly technical reviews and read all value-bearing and permissioned logic by hand.

  6. 6

    Produce the evidence

    We run fuzzing, static analysis and fork tests, package the results for your auditor, then fix and retest.

  7. 7

    Rehearse deployment

    We practice signers, configuration, verification and pause procedures on a testnet, then transfer ownership.

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