Smart Contract Engineer (Solidity)

01About the role

We are building a non-custodial cross-chain swap aggregator. The routing and the backend are built and a swap runs end to end; the launch is ahead of us. A token comes after it: a multi-season airdrop for the people who use the product, and a buy-and-burn funded by swap fees. We route through an aggregator rather than running our own pools, so there is no AMM here: the on-chain surface is small and deliberately boring, which is how we think money-critical code should look. Roughly a third of this role is not Solidity at all, and that third is yours too.

02What you will do

• Merkle airdrop and claim, multi-season. This is the bulk of the work. A new root per season, no double claim, a vested payout above a threshold, an eligibility gate and pausable claims.
• Buy-and-burn: it spends treasury USDC on the open market and burns. Multisig-triggered first, a keeper later. It is a market order, so slippage and MEV protection have to be real.
• The token: an ERC-20 from the OpenZeppelin Wizard with permit. Not pausable, no custom transfer logic.
• The Foundry suite (unit, fuzz, stateful invariant and mainnet-fork tests, above 95% coverage), plus formal verification on the maths and static analysis coming back clean.
• The contract repository, its CI and the path to testnet: a local Arbitrum fork, then Arbitrum Sepolia, then deploy scripts and Arbiscan verification.
• Safe and timelock wiring: two Safes for admin and treasury, thresholds, hardware wallets, a timelock in front of admin, and a separate low-threshold pause key that bypasses it in an incident.
• A guarded launch: caps raised gradually, pause hooks, and every setter bounded at deploy. A `setMaxSlippage` without a ceiling is a back door, not a dial.
• The audit cycle end to end: an independent pre-audit review, a firm, a public contest, remediation, and deploying exactly what was audited.
• Season operations and handover: the Merkle tooling, a new root pushed through the multisig, the claim window, the unclaimed remainder. All of it is built, then rehearsed on testnet until two non-specialists can run it without you.

02Two contracts that may not happen

Fee-share staking (locks, reward accounting, boost, deposit cap) and a randomised reward-chest mechanic (key accounting, prize tiers, and a randomness source that does not cost more than the prize) are waiting on a legal opinion. Our default is that neither gets built, but price both, because the answer has to land before the pre-audit freeze and you cannot freeze audit scope around an undecided contract. Chainlink CCT comes after launch: at launch the token only has to be CCT-ready, and whether it can ever mint is settled before the token deploys and is irreversible.

03What is ours, not yours

Everything off-chain. The routing backend, the swap frontend and the environments are built; the points engine, the anti-sybil work, the Merkle snapshot, the claim interface and the monitoring are ours to build alongside you. Team and investor vesting is Sablier configuration, not a contract you write. Swap fees arrive off-chain in many tokens on many chains and sweeping them is our routine. What reaches you is USDC in a treasury Safe, and how the buy-and-burn draws from it is a design question we want your recommendation on, under one constraint: a bug there must never reach more than the amount allocated to it. We seed the liquidity pool ourselves; we would want your view on the venue before the token is written, not your time running it.

04Good fit if you have

• Solidity you shipped to mainnet that held real money.
• Contracts of yours that went through a formal audit, and that you can talk through the findings of.
• Stateful invariant testing in Foundry, not just unit tests.
• You can name a real exploit class and say what stops it in code.
• You flag an open decision instead of assuming one.

05Nice to have

• Merkle distribution, vesting or staking contracts you have shipped.
• A Code4rena, Sherlock or Cantina profile.
• Safe and timelock operations.
• Chainlink CCT or CCIP.

06What we offer

• B2B, in PLN or the USDC equivalent. Monthly invoice, paid within seven days.
• Fully remote, from anywhere. Async by default, no standing meetings, CET.
• Your hours: bill what you work. No weekly floor and no ceiling.
• A company laptop and hardware security keys, provided and configured.
• A written spec, a threat model and an exploit-class catalogue, so you are not guessing at requirements.
• Two to three audits budgeted (a firm plus a public contest), an independent reviewer before them, and a bug bounty live before mainnet.
• A few months to launch, ending with the handover, and an optional retainer afterwards.

07How to apply

1. 1.Two or three contracts you wrote that went to mainnet, and what they held.
2. 2.The audit reports on them.
3. 3.One paragraph: given the scope above, what would worry you most about this build?
4. 4.Your availability, and which end of the rate you are after.

The third point is the one we actually read.