Solidity / DeFi Protocol Engineer
Focused on DeFi protocol design, smart contract architecture, protocol accounting, security, and adversarial testing with Foundry.
I build protocol-level systems where correctness depends on the interaction between math, state, permissions, and time.
A Solidity protocol for financing tokenized receivables through senior / junior liquidity tranches.
Built as an end-to-end protocol engineering project covering architecture, implementation, economic accounting, adversarial testing, security review, deployment, and live execution.
Engineering highlights
- explicit invoice lifecycle:
CREATED → VERIFIED → FUNDED → SETTLED / DEFAULTED - senior / junior tranche funding and accounting
- risk-based advance rates and Buyer exposure controls
- oracle-driven settlement and default lifecycle with a real dispute window
- Junior-first loss absorption
- reserved default impairment through
pendingLoss - no second NAV haircut when a reserved default loss is realized
- role-separated origination, verification, risk, oracle, and execution permissions
- stored-term settlement rather than recomputing historical financing economics
- fuzz testing and stateful invariant testing
- independent ghost accounting for invariant verification
- external review remediation and protocol-accounting hardening
Validation
- 229 / 229 tests passing
- 12 stateful invariants passing
- deployed and verified on Ethereum Sepolia
- completed live end-to-end settlement and default scenarios
- public transaction evidence and final accounting inspection
Repository · Live Demo · Deployment
A minimal Solidity lending protocol focused on the core mechanics and accounting of collateralized DeFi lending.
Engineering focus
- collateral deposits and withdrawals
- collateralized borrowing and repayment
- oracle-based collateral valuation
- health-factor and solvency checks
- interest and debt accounting
- liquidation mechanics
- failure-path and edge-case testing
- fuzz and invariant-based verification
The project explores the primitives underlying larger lending systems while keeping the architecture small enough to reason about protocol behavior and accounting explicitly.
Solidity · Foundry · EVM · DeFi · Protocol Accounting · Lending · ERC-4626 · Oracle Systems · Liquidations · Access Control · Fuzz Testing · Stateful Invariants · Smart Contract Security
My approach is to treat smart contracts as more than isolated functions.
They are simultaneously:
- state machines — transitions must remain valid across the full lifecycle
- accounting systems — assets, debt, liquidity, losses, and exposure must reconcile
- permission systems — authority and trust boundaries must be explicit
- adversarial environments — correctness must survive unexpected execution sequences
The goal is not only to prove that individual transactions succeed, but that protocol state and accounting remain correct across valid and adversarial execution paths.
math + state + time