Richard Jamieson

Work

Opty.fi

Solidity Developer

December 2021 – October 2022

Opty.fi was a DeFi yield-aggregation protocol on Ethereum and Polygon. I came in through the front door in 2021 — they posted a bounty for a smart-contract adapter, I built it, and that turned into a place on the core team.

The Beefy adapter

The bounty was an adapter letting Opty's vaults deposit into, withdraw from and account for positions in Beefy Finance on Polygon. The work was in two halves: understanding a codebase and an adapter interface I had not written, then fitting it to the specific way Beefy behaved.

The interesting constraint was coverage. Beefy was vaulting more than 170 pools at the time, and an adapter that works against three of them proves nothing. I restructured the TypeScript tests so they could run efficiently across the full set, which is what surfaced the edge cases worth handling.

The finished adapter is public, as is the development repository with the tests.

The optimisation engine

From December 2021 I joined the optimisation-engine team, which was mostly Python. The goal was to pull data from protocols and pools across Ethereum, assess them on risk-adjusted return, and emit signals telling each vault when to switch strategy or compound its rewards.

My part was the economics of those decisions: estimating the fixed and proportional cost of a strategy switch, combining that with expected APR into a yes/no signal, doing the same for compounding, and building the dashboard controls to execute either.

Two problems worth describing, because I solved both by abandoning my first approach.

The first was cost estimation in the Curve and Convex ecosystem, which is idiosyncratic — some contracts in Vyper, several generations of contract standard, and no single interface to rely on. I started by trying to understand and replicate Curve's own proportional-cost mathematics in Python. That went badly: every edge case added complexity and the code became unwieldy. I abandoned it and switched to simulation instead — run the candidate transaction against a forked node, read the gas cost from the receipt and the proportional cost from the vault balance before and after. Measuring turned out to be far more robust than modelling.

The second was a language boundary. The engine was Python and needed to stay Python, but everything that talked to contracts was JavaScript, where the tooling was more mature — particularly for batched calls and multisig transactions. I first tried to rebuild that layer in Python, and hit both missing capability and, worse, duplicated logic that would inevitably drift from its JavaScript counterpart. The eventual solution was to stop duplicating: invoke the existing, tested JavaScript from Python as a subprocess, return the encoded transaction, and simulate from there. One implementation, reused rather than reimplemented.

Most of this work lives in private repositories.

← All work