Пофіксити розрахунок Realized PnL, ROI і Win Rate для криптогаманців

Бюджет: 10000 UAH Термін: 4 дні

Добрий день. Вивчив задачу. Головна причина розбіжностей із Nansen — некоректне врахування FIFO/LIFO при часткових продажах, ігнорування Gas Fee в собівартості токена та неправильне маркування звичайних трансферів/пулів ліквідності як угод.

Технічне рішення:
На TypeScript/Node.js перепишу логіку обробки масивів з Moralis. Впроваджу суворий алгоритм FIFO для Realized PnL. Свопи ідентифікуватиму за збігом transaction_hash між нативними переказами та ERC-20, додаючи витрачений газ до вартості позиції. Для токенів, які прийшли звичайним трансфером (без свопу), підтягуватиму історичну ціну на момент блоку через DeFiLlama API. На основі вирівняного PnL перерахую ROI та Win Rate (відсоток закритих у плюс токенів).

Досвід за вашими пунктами:

Схожі задачі & Криптостатистика: Розробляв кастомні портфельні трекери, знаю математику on-chain метрик та обробку сирих транзакцій.

Nansen: Використовую як аналітичний еталон, розумію їхню логіку відстеження Smart Money.

Moralis & DeFiLlama: Постійно працюю з Token API від Moralis для збору трансферів та Price API від DeFiLlama для історичних котирувань.

План та терміни:
За 4 дні проведу аудит вашого коду, перепишу калькуляцію за FIFO з урахуванням газу та відкалібрую метрики за тестовими гаманцями, щоб цифри повністю збіглися з Nansen.

Запитання щодо задачі:
Як зараз ваша система маркує вхідні трансфери токенів, які не є результатом свопу на DEX — вважає їх покупкою за нульовою ціною чи бере ринкову вартість на момент транзакції? Розгорнути

Бюджет: 4500 UAH Термін: 5 днів

Доброго дня! Візьмуся звести ваші Realized PnL / ROI / Win Rate до цифр Nansen — з даними Moralis (нативні ETH-перекази + ERC-20 transfers) працював, логіку побудови метрик по on-chain історії роблю.

По суті: коли власні цифри «пливуть» відносно Nansen, майже завжди причина в правилах класифікації, а не в самих даних. Типові розбіжності — метод обліку собівартості (FIFO vs weighted-average, Nansen рахує середньозважену), як трактуються самоперекази/wrap-unwrap/bridge (їх не можна рахувати як buy/sell), чи включати комісії газу в cost basis, і звідки береться ціна для неліквідних токенів на момент угоди. Саме тут зазвичай і накопичується дельта.

Досвід: інтеграції REST-API + обробка on-chain транзакцій, статистика по крипто-операціях. З Moralis — так (обидва виклики, що ви описали). DeFiLlama — брав звідти історичні ціни. Nansen внутрішньо не реверсив, але задача саме така — підігнати нашу класифікацію під їхній результат на спільних гаманцях за той самий період, ітеративно.

Питання, щоб точно влучити: розбіжність системна (всі гаманці зміщені в один бік) чи плаває по конкретних токенах? І вам треба збіг «пункт-у-пункт» з Nansen чи в межах розумного допуску?

Готовий узяти один ваш гаманець, де цифри розходяться, показати де саме ламається логіка й скинути розбір у чат.

Орієнтовно: 4500 грн, 4-5 днів. Беру за стартовою — набираю перші відгуки тут, тому роблю вигідно.

Петро Панков, BotCraft Group Розгорнути

Бюджет: 19000 UAH Термін: 9 днів

Доброго дня! Рахував Realized PnL і ROI по on-chain історії через Moralis і звіряв показники з Nansen — тема знайома. Найчастіше цифри розходяться не через самі формули, а через класифікацію: swap плутається з простим transfer, часткові продажі й комісії ламають cost-basis. Почав би з вибірки 5-10 гаманців і таблиці розбіжностей по токенах, щоб довести розрахунок до збігу з еталоном. Які мережі зараз рахуються — тільки Ethereum чи ще Base/Arbitrum/BSC? Візьмуся, орієнтовно 9 днів.

Бюджет: 2000 UAH Термін: 2 дні

Привіт, Павле! Чудово розумію задачу. Відмінності з Nansen зазвичай полягають у логіці обліку декса-свопів (коли транзакція вважається за одну операцію продажу/купівлю, а не просто за два окремі трансфери), а також у коректному розрахунку середньої ціни входу (кастомний FIFO/LIFO).

Відповідаю по ваших пунктах:
1. Досвід у схожих завданнях: Розробляв логіку калькуляторів і агрегації даних для дашбордів на React/TypeScript. Добре знайомий з математикою PnL (Realized/Unrealized) і ROI.
2. Досвід з Nansen: Активно використовую платформу як аналітик, досконало знаю, як там влаштований інтерфейс токенів і гаманців (Smart Money, Token God Mode). Розумію, до якого еталону потрібно привести цифри.
3. Досвід з Moralis: Інтегрував їх Web3 API для отримання історії транзакцій, балансів і метаданих ERC-20 / нативного евма.
4. Досвід з DeFiLlama: Використовував їх API для підтягання історичних цін токенів на момент здійснення транзакції (розділ /prices) — це критично для точного розрахунку PnL.
5. Досвід зі статтями по криптоопераціях: Постійно досліджую механіку роботи пулів ліквідності, стейкінгу і обгорнених токенів, щоб правильно класифікувати «нестандартні» транзакції.

Приблизна вартість і терміни: Щоб назвати точну цифру, потрібно глянути на поточну JS/TS функцію розрахунку. Пропоную закласти близько 1500–2500 UAH і 2-3 дні на детальні тести і звірку з Nansen.

Готовий обговорити код і логіку в чаті! Розгорнути

Бюджет: 27000 UAH Термін: 10 днів

Оцінка - орієнтовно 45 000 грн і 10 робочих днів. Якщо після доступу до коду виявиться, що проблема не тільки у формулах, а ще й у сирих даних або цінах, тоді діапазон може змінитись, але почати можна з цього етапу.

ПРацювали з криптостатистикою, фінансовими розрахунками і звіркою показників з еталонними сервісами. З Nansen - як з референсом для порівняння PnL, ROI і Win Rate. З Moralis - по on-chain історії, ERC-20 transfers і native transfers. З DeFiLlama - по історичних цінах і перевірці ринкових даних. У таких задачах одна помлка в класифікації transfer, swap, fee, airdrop або partial sell легко ламає всю картину =/

Я б почав не з підкручування формул, а з контрольної вибірки гаманців. Потрібно відділити фактичні угоди від переказів, описати правила класифікації операцій, нормалізувати ціну токена на момент угоди, врахувати комісії, часткові продажі, внутрішні перекази і випадки без ціни. Далі - таблиця розбіжностей по кожному токену і доведення логіки до збігу з Nansen або окреме пояснення місць, де Nansen не розкриває правило.

Від вас потрібні доступ до коду модуля розрахунку, приклади 5-10 гаманців, період звірки, скриншоти або експорт з Nansen і поточний результат ваших розрахунків.

> Питання 1 - які мережі зараз у розрахунку, тільки Ethereum чи є ще Base, Arbitrum, BSC, Solana
> Питання 2 - у вас вже зберігаються історичні ціни по кожній операції, чи ціни підтягуються під час перерахунку

Близькі за логікою кейси Ingello
> https://business.ingello.com/platforma - складна корпоративна система з ролями, даними і звітністю
> https://business.ingello.com/vorfahr - SaaS з інтеграціями, обробкою даних і прикладною автоматизацією
> https://business.ingello.com/fractal - автоматизація складних інженерних процесів

FLH-лендинг Ingello - https://systems-fl.ingello.com/ua Розгорнути

Бюджет: 15000 UAH Термін: 7 днів

Добрий день! Ми маємо досвід у розробці аналітичних систем для блокчейн-даних. Реалізуємо коректний розрахунок Realized PnL, ROI та Win Rate через побудову точного ланцюжка транзакцій та інтеграцію історичних цін токенів. Це забезпечить високу точність фінансової звітності для Вашого сервісу. Готові приступити до аналізу архітектури та оптимізації алгоритмів обробки on-chain даних.

Бюджет: 10000 UAH Термін: 5 днів

Вітаю, Павле! Розбіжність метрик із Nansen при парсингу сирих даних з Moralis — це класична проблема ончейн-аналітики. Moralis віддає лінійну історію Transfer подій, тоді як Nansen використовує складні евристичні моделі для фільтрації шуму.

Чому ваші цифри зараз різняться:

Метод обліку (Cost Basis): Для розрахунку Realized PnL критично важлива черговість. Якщо ваш поточний алгоритм використовує середню ціну токена, а референс рахує за методологією FIFO (First-In, First-Out) із точним матчингом конкретних лотів купівлі та продажу, фінальний результат буде кардинально іншим.

Невірний інтент транзакцій: Сирі ERC-20 трансфери включають стейкінг, мінти, спалювання, перекази між своїми ж гаманцями та роботу з мостами. Nansen маркує їх як внутрішні переміщення і не враховує в торговий PnL, тоді як ваш алгоритм, скоріш за все, сприймає це як звичайний приток або відток токенів.

Gas Fees: Nansen капіталізує витрати на газ (у нативному ETH) у вартість позиції, що суттєво змінює чистий ROI та підсумковий Win Rate.

Мій досвід та відповіді на ваші питання:

Досвід у схожих задачах та криптоопераціях: Пишу складні аналітичні та ETL-пайплайни для обробки ончейн-даних, проектую логіку для трекерів портфелів та десктопних утиліт. Розумію механіку роботи DEX-маршрутизаторів (Uniswap V2/V3 тощо).

Робота з Moralis, Nansen, DeFiLlama: Регулярно працюю з дефі-датасетами. Добре знайомий з API Moralis (знаю, як витягувати події та цінові історичні точки на момент конкретного блоку) та інтегрував історичні дані з DeFiLlama. Розумію логіку аналітичних дашбордів Nansen, знаю, як реконструювати їхні метрики.

План дій: Проведу аудит вашого поточного коду, виділю транзакції-виключення (які не є трейдингом), налаштую чітку черговість списання лотів за FIFO та синхронізую логіку обчислення Win Rate / ROI з еталоном.

Готовий детально розібрати кілька конкретних кейсів гаманців у чаті! Розгорнути

Бюджет: 7500 UAH Термін: 5 днів

Завдання знайоме: розрахунок Realized PnL по on-chain даних потребує чіткого розуміння того, як класифікувати кожну дію гаманця. Зі свопами, перекладами між власними адресами і ліквідністю в пулах одна і та сама транзакція може трактуватись по-різному, і саме це найчастіше дає розбіжність з еталонними платформами на кшталт Nansen.

Досвіду з Nansen, Moralis і DeFiLlama як API-клієнт немає, чесно скажу. Але досвід є з TypeScript, аналітикою і побудовою розрахункових пайплайнів. Щоб зрозуміти де розбіжність, першим кроком потрібно взяти конкретний гаманець, пройтись по кожній транзакції разом з вашим кодом і подивитись, яке правило класифікації призводить до іншого числа ніж те, що показує Nansen. Після діагностики буде зрозуміло, чи це питання маппінгу подій, ціни на момент угоди, чи логіки FIFO/LIFO для cost basis.

Якщо завдання виключно аналітичне (розібратись у логіці і пофіксити розрахунок), орієнтовно 2-5 днів залежно від кількості edge cases. Готовий почати з аудиту поточної логіки.

Написав би в особисті щоб уточнити деталі.

Бюджет: 1000 UAH Термін: 1 день

Вітаю!

Маю досвід роботи з перерахованими технологіями.
Готовий виконати поставлене завдання.

Пропоную обговорити деталі в особистих повідомленнях.

Бюджет: 6000 UAH Термін: 3 дні

Добрий день!
Працював з on-chain аналітикою та розрахунком PnL - є досвід інтеграції з API Binance, Bybit, OKX, Kraken, KuCoin, Gate.io, також робив скрипт відслідковування транзакцій через Solana gateway і будував Binance Wallet Tracker з розрахунком PnL(https://freelancehunt.com/showcase/work/binance-wallet-tracker/1853339.html).

Moralis, Nansen і DeFiLlama не використовував напряму, але логіка розрахунку Realized PnL, класифікація транзакцій і cost basis методологія - знайома тема з інших проєктів.
Найімовірніші причини розходження з Nansen: різна класифікація внутрішніх трансферів, LP токени і різні джерела ціни на момент угоди.

Буду радий співпраці!

Бюджет: 20000 UAH Термін: 15 днів

Доброго дня!

Маю досвід роботи з blockchain API, обробкою транзакцій та розрахунком фінансових метрик. З Moralis працював, інтегрував API для отримання ончейн-даних. З Nansen та DeFiLlama не працював напряму, але знайомий з їх призначенням та документацією.

Розумію, що основна складність задачі - не самі формули PnL/ROI/Win Rate, а правильна класифікація ончейн-операцій і приведення логіки до результатів Nansen.

Бюджет: 22500 UAH Термін: 3 дні

Доброго дня.
Мій досвід безпосередньо пов’язаний з криптоінфраструктурою, побудовою криптовалютної біржі, міжнародним структуруванням криптобізнесу та аналізом blockchain-транзакцій. Також маю практичний досвід роботи з економікою криптооперацій, PnL, торговою логікою та побудовою моделей розрахунку фінансових показників.
відповіді на ваші питання:
- є досвід аналізу криптооперацій, побудови фінансової логіки та PnL-моделей.
- прямої інтеграції не мав, але розумію принципи wallet analytics та методологію розрахунків.
- добре розумію структуру API та on-chain даних.
- використовую як аналітичний інструмент.
- маю практичний досвід розрахунку PnL, ROI та аналізу blockchain-транзакцій.
щодо самої причини розбіжностей, то найімовірніше проблема у логіці класифікації транзакцій і розрахунку cost basis, а не в самих даних.
Попередньо я б оцінив у $500. фінальний бюджет зможу дати після ознайомлення з поточною реалізацією. Вам потрібен лише аналіз методології та правил розрахунку, чи також внесення змін у код?

Бюджет: 3000 UAH Термін: 3 дні

Доброго дня, я робив платформу https://www.updownxpro.com - досвіду з цими інструментами немає, але думаю що розберусь.

Бюджет: 12345 UAH Термін: 123 дні

Привіт, маю досвід у написанні торгових ботів, буду радий допомогти. Є свій проєкт cobwebscan, для ананлізу мережі солана(зараз він не стоїть на хостингу, але за потреби для огляду можу поставити). Я маю бачити сам код, і лише потім зможу сказати конкретні терміни та ціну, буду радий спочатку поспілкуватись в особистих.

Бюджет: 27000 UAH Термін: 12 днів

у мене вже є практично готове схоже рішення для розрахунку метрик по криптогаманцях, його можна швидко адаптувати під вашу модель і звірку з Nansen, пропоную обговорити деталі тут на біржі, я на зв'язку ))

по вартості - прибизно 65000 грн.
по строках - 10-12 робочих днів, якщо код і приклади розбіжностей доступні з першого дня.

досвід є саме в задачах, де треба звести транзакції, ринкові ціни, внутрішню класифікацію дій гаманця і фінальну статистику.
з Nansen працювали як з еталоном для порівняння метрик.
з Moralis - по витягуванню переказів, ERC-20 подій, свопів і нормалізації історії гаманця.
з DeFiLlama - по цінових рядах і перевірці даних, коли треба не покладатися на одне джерело.

МОжу піти практично - спершу беремо 3-5 гаманців, де різниця з Nansen найбільша, розкладаємо по операціях і знаходимо правила, через які ламається Realized PnL, ROI або Win Rate.
після цього правимо формули, класифікацію buy, sell, transfer, fee, bridge, airdrop, liquidity, і додаємо перевірочні тести, щоб цифри не поїхали далі.

уточнення.
- чи є вже доступ до коду розрахунку і приклади конкретних гаманців, де видно різницю з Nansen.
- які мережі треба покрити на першому етапі - тільки Ethereum чи також Base, Arbitrum, BSC, Solana.

релевантні приклади.
https://business.ingello.com/vorfahr - складна автоматизація з даними, логікою і перевіркою результатів.
https://business.ingello.com/fractal - системи з агентною логікою та аналітичними сценаріями.

про нас для Freelancehunt.
https://systems-fl.ingello.com/ua Розгорнути