Пофиксить расчет 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 дней. Беру за стартовой — набираю первые отзывы здесь, поэтому делаю выгодно.

Петр Панкoв, 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 Развернуть