LP Earnings Research

Problem

For tax purposes, Propellyr needed the earnings of liquidity providers and stakers on each crypto platform. Those earnings never appear as a simple transfer. They sit inside each protocol’s smart contract mechanics, and every protocol computes them differently. Propellyr had no smart contracts of its own.

Solution

Researched other crypto platforms, read their smart contracts and transactions, and worked out how each one computes provider earnings. Built Node.js and Solidity proofs of concept to check the math against real deposits and withdrawals, then wrote recommendations for how the tax product could use that contract data and those transactions.

Architecture

Proofs of concept in Node.js and Solidity, not a production engine. Solidity PoCs modelled how other platforms’ contracts compute liquidity-provider earnings. Node.js scripts fetched real deposit and withdrawal transactions from those protocols, priced the tokens at both timestamps, and checked the result against what the depositor actually received. The research and PoCs were direction for the tax product team, who later built the production engine in Java and Spring Boot over ClickHouse.

Engineering decisions

• Modelled other platforms’ contracts in Solidity rather than inventing a Propellyr contract
• Verified calculated earnings against the tokens a depositor actually received on withdrawal, not just the whitepaper formula
• One protocol at a time from the contracts up, instead of assuming AMMs share one earnings model

Technology

Solidity · Node.js

Results

• PoCs verified earnings against real on-chain withdrawals
• Gave the tax product team a protocol-by-protocol model of how to compute LP earnings from other platforms’ contract data

What Daniel learned

The whitepaper version of a protocol and the deployed contract version rarely match. Reading transactions directly settled every disagreement.