Fix the calculation of Realized PnL, ROI, and Win Rate for cryptocurrency wallets.

Budget: 4500 UAH Deadline: 5 days

Good day! I will take on the task of reconciling your Realized PnL / ROI / Win Rate with Nansen numbers — I have worked with Moralis data (native ETH transfers + ERC-20 transfers) and I am building the logic for metrics based on on-chain history.

Essentially: when your own numbers "drift" relative to Nansen, the cause is almost always in the classification rules, not in the data itself. Typical discrepancies arise from the cost accounting method (FIFO vs weighted-average, Nansen calculates the weighted average), how self-transfers/wrap-unwrap/bridge are interpreted (they cannot be counted as buy/sell), whether to include gas fees in the cost basis, and where the price for illiquid tokens comes from at the time of the transaction. This is usually where the delta accumulates.

Experience: REST-API integrations + processing on-chain transactions, statistics on crypto operations. With Moralis — yes (both calls you described). DeFiLlama — I took historical prices from there. Nansen is not internally reversible, but the task is exactly that — to adjust our classification to match their results on shared wallets for the same period, iteratively.

A question to hit the mark: is the discrepancy systemic (all wallets shifted in one direction) or does it fluctuate with specific tokens? And do you need a "point-to-point" match with Nansen or within a reasonable tolerance?

I am ready to take one of your wallets where the numbers diverge, show exactly where the logic breaks, and send the analysis in the chat.

Approximately: 4500 UAH, 4-5 days. I am taking it at the starting rate — I am gathering initial reviews here, so I am making it advantageous.

Petro Pankov, BotCraft Group Expand

Budget: 19000 UAH Deadline: 9 days

Good day! I calculated Realized PnL and ROI based on on-chain history through Moralis and compared the metrics with Nansen — the topic is familiar. Most often, the numbers diverge not because of the formulas themselves, but due to classification: swaps get confused with simple transfers, partial sales and fees break the cost-basis. I would start with a sample of 5-10 wallets and a table of discrepancies by tokens to bring the calculation in line with the benchmark. Which networks are currently being considered — only Ethereum or also Base/Arbitrum/BSC? I will take it on, approximately 9 days.

Budget: 27000 UAH Deadline: 10 days

Estimate - approximately 45,000 UAH and 10 working days. If after accessing the code it turns out that the problem is not only with the formulas but also with raw data or prices, then the range may change, but we can start from this stage.

Worked with crypto statistics, financial calculations, and reconciling indicators with benchmark services. With Nansen - as a reference for comparing PnL, ROI, and Win Rate. With Moralis - on on-chain history, ERC-20 transfers, and native transfers. With DeFiLlama - on historical prices and market data verification. In such tasks, one mistake in classifying transfer, swap, fee, airdrop, or partial sell easily breaks the whole picture =/

I would start not with tweaking formulas, but with a control sample of wallets. It is necessary to separate actual transactions from transfers, describe the rules for classifying operations, normalize the token price at the time of the transaction, account for fees, partial sales, internal transfers, and cases without prices. Next - a discrepancy table for each token and proving the logic to match with Nansen or a separate explanation of places where Nansen does not disclose the rule.

What you need to provide is access to the calculation module code, examples of 5-10 wallets, the reconciliation period, screenshots or exports from Nansen, and the current results of your calculations.

> Question 1 - which networks are currently in the calculation, only Ethereum or are there also Base, Arbitrum, BSC, Solana?
> Question 2 - do you already store historical prices for each operation, or are prices pulled during recalculation?

Cases similar in logic to Ingello
> https://business.ingello.com/platforma - a complex corporate system with roles, data, and reporting
> https://business.ingello.com/vorfahr - SaaS with integrations, data processing, and applied automation
> https://business.ingello.com/fractal - automation of complex engineering processes

FLH landing Ingello - https://systems-fl.ingello.com/ua Expand

Budget: 10000 UAH Deadline: 4 days

Good day. I studied the task. The main reason for discrepancies with Nansen is the incorrect consideration of FIFO/LIFO during partial sales, ignoring Gas Fee in the token's cost, and the incorrect labeling of regular transfers/liquidity pools as transactions.

Technical solution:
I will rewrite the logic for processing arrays from Moralis in TypeScript/Node.js. I will implement a strict FIFO algorithm for Realized PnL. I will identify swaps by matching transaction_hash between native transfers and ERC-20, adding the gas spent to the position's cost. For tokens that came via regular transfer (without a swap), I will pull the historical price at the block moment through the DeFiLlama API. Based on the adjusted PnL, I will recalculate ROI and Win Rate (percentage of closed tokens in profit).

Experience regarding your points:

Similar tasks & Crypto statistics: I have developed custom portfolio trackers, I understand the mathematics of on-chain metrics and raw transaction processing.

Nansen: I use it as an analytical benchmark, I understand their logic for tracking Smart Money.

Moralis & DeFiLlama: I constantly work with the Token API from Moralis for collecting transfers and the Price API from DeFiLlama for historical quotes.

Plan and deadlines:
In 4 days, I will audit your code, rewrite the FIFO calculation considering gas, and calibrate the metrics using test wallets so that the numbers fully match with Nansen.

Questions regarding the task:
How does your system currently label incoming token transfers that are not the result of a swap on DEX — does it consider them a purchase at zero price or does it take the market value at the time of the transaction? Expand

Budget: 15000 UAH Deadline: 7 days

Good day! We have experience in developing analytical systems for blockchain data. We implement accurate calculations of Realized PnL, ROI, and Win Rate through the construction of a precise transaction chain and integration of historical token prices. This will ensure high accuracy in financial reporting for your service. We are ready to begin analyzing the architecture and optimizing the algorithms for processing on-chain data.

Budget: 10000 UAH Deadline: 5 days

Hello, Pavlo! The discrepancy in metrics with Nansen when parsing raw data from Moralis is a classic problem in on-chain analytics. Moralis provides a linear history of Transfer events, while Nansen uses complex heuristic models to filter out noise.

Why your numbers currently differ:

Accounting Method (Cost Basis): The order of transactions is critical for calculating Realized PnL. If your current algorithm uses the average token price, while the reference counts using the FIFO (First-In, First-Out) methodology with exact matching of specific buy and sell lots, the final result will be drastically different.

Incorrect transaction intent: Raw ERC-20 transfers include staking, minting, burning, transfers between your own wallets, and working with bridges. Nansen marks them as internal transfers and does not account for them in trading PnL, while your algorithm likely perceives this as a regular inflow or outflow of tokens.

Gas Fees: Nansen capitalizes gas costs (in native ETH) into the position cost, which significantly alters the net ROI and overall Win Rate.

My experience and answers to your questions:

Experience with similar tasks and crypto operations: I write complex analytical and ETL pipelines for processing on-chain data, design logic for portfolio trackers and desktop utilities. I understand the mechanics of DEX routers (Uniswap V2/V3, etc.).

Working with Moralis, Nansen, DeFiLlama: I regularly work with DeFi datasets. I am well acquainted with the Moralis API (I know how to extract events and price historical points at a specific block) and have integrated historical data from DeFiLlama. I understand the logic of Nansen's analytical dashboards and know how to reconstruct their metrics.

Action plan: I will audit your current code, highlight exclusion transactions (which are not trading), set up a clear FIFO lot deduction order, and synchronize the logic for calculating Win Rate / ROI with the benchmark.

I am ready to discuss several specific wallet cases in detail in the chat! Expand

Budget: 12300 UAH Deadline: 3 days

Good day,

I have experience in developing and debugging financial calculations in TypeScript/Node.js, particularly working with on-chain data and external APIs (like Moralis and similar). I have used Nansen as a benchmark for wallet analysis tasks, and I understand the logic of classifying swaps vs. transfers for PnL purposes.

Approach: I will establish the complete flow for calculating Realized PnL, ROI, and Win Rate, compare the methodology with how Nansen classifies actions (entry/exit of positions, partial sales, fees), identify discrepancies, and correct the logic. The approximate fixed cost is from $300 depending on the depth of the issue and the number of edge cases, with a timeline of 3-7 days after reviewing the code.

Feel free to reach out, and we can discuss the details privately!

Budget: 7500 UAH Deadline: 5 days

The task is familiar: calculating Realized PnL based on on-chain data requires a clear understanding of how to classify each wallet action. With swaps, transfers between personal addresses, and liquidity in pools, the same transaction can be interpreted differently, and this is often what leads to discrepancies with benchmark platforms like Nansen.

I don't have experience with Nansen, Moralis, and DeFiLlama as an API client, to be honest. However, I do have experience with TypeScript, analytics, and building calculation pipelines. To understand where the discrepancy lies, the first step is to take a specific wallet, go through each transaction with your code, and see which classification rule leads to a different number than what Nansen shows. After diagnostics, it will be clear whether this is a matter of event mapping, the price at the time of the transaction, or FIFO/LIFO logic for cost basis.

If the task is purely analytical (to understand the logic and fix the calculation), it would take approximately 2-5 days depending on the number of edge cases. I am ready to start with an audit of the current logic.

I would write in private to clarify the details.

Budget: 1000 UAH Deadline: 1 day

Hello!

I have experience working with the listed technologies.
I am ready to complete the assigned task.

I suggest discussing the details in private messages.

Budget: 6000 UAH Deadline: 3 days

Good day!
I have worked with on-chain analytics and PnL calculation - I have experience integrating with the APIs of Binance, Bybit, OKX, Kraken, KuCoin, Gate.io, and I also created a transaction tracking script through the Solana gateway and built a Binance Wallet Tracker with PnL calculation (https://freelancehunt.com/showcase/work/binance-wallet-tracker/1853339.html).

I have not used Moralis, Nansen, and DeFiLlama directly, but the logic of calculating Realized PnL, transaction classification, and cost basis methodology is a familiar topic from other projects.
The most likely reasons for discrepancies with Nansen: different classification of internal transfers, LP tokens, and different price sources at the time of the transaction.

I would be happy to collaborate!

Budget: 20000 UAH Deadline: 15 days

Good day!

I have experience working with blockchain APIs, processing transactions, and calculating financial metrics. I have worked with Moralis, integrating APIs to obtain on-chain data. I have not worked directly with Nansen and DeFiLlama, but I am familiar with their purpose and documentation.

I understand that the main complexity of the task is not the formulas for PnL/ROI/Win Rate themselves, but the correct classification of on-chain operations and aligning the logic with Nansen's results.

Budget: 22500 UAH Deadline: 3 days

Good day.
My experience is directly related to crypto infrastructure, building cryptocurrency exchanges, international structuring of crypto businesses, and analyzing blockchain transactions. I also have practical experience in the economics of crypto operations, PnL, trading logic, and building models for calculating financial indicators.
Answers to your questions:
- I have experience in analyzing crypto operations, building financial logic, and PnL models.
- I haven't had direct integration experience, but I understand the principles of wallet analytics and the methodology of calculations.
- I have a good understanding of the structure of APIs and on-chain data.
- I use it as an analytical tool.
- I have practical experience in calculating PnL, ROI, and analyzing blockchain transactions.
Regarding the reason for the discrepancies, the problem is most likely in the logic of transaction classification and cost basis calculation, rather than in the data itself.
Preliminarily, I would estimate it at $500. I can provide the final budget after reviewing the current implementation. Do you need only an analysis of the methodology and calculation rules, or also changes to the code?

Budget: 2000 UAH Deadline: 2 days

Hello, Pavel! I fully understand the task. The differences with Nansen usually lie in the logic of accounting for dex swaps (when a transaction is considered as one operation of sale/purchase, rather than just two separate transfers), as well as in the correct calculation of the average entry price (custom FIFO/LIFO).

I respond to your points:
1. Experience in similar tasks: I have developed the logic for calculators and data aggregation for dashboards using React/TypeScript. I am well acquainted with the mathematics of PnL (Realized/Unrealized) and ROI.
2. Experience with Nansen: I actively use the platform as an analyst and have a thorough understanding of how the token and wallet interface works (Smart Money, Token God Mode). I understand what benchmark the numbers need to be aligned with.
3. Experience with Moralis: I integrated their Web3 API to obtain transaction history, balances, and metadata for ERC-20 / native EVM.
4. Experience with DeFiLlama: I used their API to pull historical token prices at the time of the transaction (section /prices) — this is critical for accurate PnL calculation.
5. Experience with articles on crypto operations: I constantly research the mechanics of liquidity pools, staking, and wrapped tokens to correctly classify "non-standard" transactions.

Approximate cost and timeline: To provide an exact figure, I need to take a look at the current JS/TS calculation function. I suggest budgeting around 1500–2500 UAH and 2-3 days for detailed testing and reconciliation with Nansen.

I am ready to discuss the code and logic in the chat! Expand

Budget: 3000 UAH Deadline: 3 days

Good day, I created the platform https://www.updownxpro.com - I have no experience with these tools, but I think I will figure it out.

Budget: 12345 UAH Deadline: 123 days

Hello, I have experience in writing trading bots and would be happy to help. I have my own project cobwebscan for analyzing the Solana network (currently it is not hosted, but I can set it up for review if needed). I need to see the code itself, and only then will I be able to provide specific timelines and pricing. I would be glad to chat privately first.

Budget: 27000 UAH Deadline: 12 days

I already have a practically ready similar solution for calculating metrics for crypto wallets, which can be quickly adapted to your model and reconciliation with Nansen. I suggest discussing the details here on the marketplace; I am available.

Regarding the cost - approximately 65,000 UAH.
Regarding the timeline - 10-12 working days, if the code and examples of discrepancies are available from day one.

I have experience specifically in tasks where it is necessary to reconcile transactions, market prices, internal classification of wallet actions, and final statistics.
We have worked with Nansen as a benchmark for comparing metrics.
With Moralis - for extracting transfers, ERC-20 events, swaps, and normalizing wallet history.
With DeFiLlama - for price feeds and data verification when it is necessary not to rely on a single source.

I can approach it practically - first, we take 3-5 wallets where the difference with Nansen is the largest, break down the operations, and find the rules through which Realized PnL, ROI, or Win Rate is disrupted.
After that, we adjust the formulas, classify buy, sell, transfer, fee, bridge, airdrop, liquidity, and add verification tests to ensure the numbers do not go off track.

Clarifications:
- Is there already access to the calculation code and examples of specific wallets where the difference with Nansen is visible?
- Which networks need to be covered in the first stage - only Ethereum or also Base, Arbitrum, BSC, Solana?

Relevant examples:
https://business.ingello.com/vorfahr - complex automation with data, logic, and result verification.
https://business.ingello.com/fractal - systems with agent logic and analytical scenarios.

About us for Freelancehunt:
https://systems-fl.ingello.com/ua Expand