• Проекты -
  • Оценка -
  • Рейтинг 1 130

Бюджет: 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 или в пределах разумного допуска?

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

  • Проекты 29
  • Оценка 4.4
  • Рейтинг 5 148

Бюджет: 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 - у вас уже хранятся исторические цены по каждой операции, или цены подтягиваются во время перерасчета

Похожий проект: Доработка CRM системы для управления проектами 3 этап
  • Проекты 11
  • Оценка 5.0
  • Рейтинг 1 773

Бюджет: 15000 UAH Срок: 7 дней

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

  • Проекты -
  • Оценка -
  • Рейтинг 483

Бюджет: 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.

  • Проекты 38
  • Оценка -
  • Рейтинг 2 008

Бюджет: 12300 UAH Срок: 3 дня

Добрый день,

имею опыт разработки и отладки финансовых расчетов на TypeScript/Node.js, в частности работа с on-chain данными и внешними API (Moralis и подобные). С Nansen как эталоном приходилось сверяться в задачах анализа кошельков, понимаю логику классификации свопов vs. трансферов для целей PnL.

Подход: подниму полный flow расчета Realized PnL, ROI и Win Rate, сравню методологию с тем, как Nansen классифицирует действия (вход/выход позиции, частичные продажи, fee), найду расхождения и исправлю логику. Приблизительная стоимость фиксированная - от 300$ в зависимости от глубины проблемы и количества edge-кейсов, срок - 3-7 дней после ознакомления с кодом.

Обращайтесь, обсудим детали в личных!

  • Проекты 20
  • Оценка -
  • Рейтинг 2 116

Бюджет: 10000 UAH Срок: 5 дней

Добрый день. Понял суть: вы рассчитываете Realized PnL, ROI и Win Rate по кошелькам на основе on-chain истории из Moralis (нативные переводы плюс ERC-20 transfers) и рыночной цены на момент сделки, а цифры не сходятся с Nansen, который вы берете за эталон.

По опыту такое расхождение почти всегда связано с правилами классификации событий, а не с самой формулой. Типичные места, где числа расходятся: учет газа и комиссий, свопы через несколько хопов (когда одна сделка выглядит как несколько transfer-ов), внутренние переводы между собственными кошельками, которые не должны быть сделкой, выбор цены (цена свопа из самой транзакции против внешнего прайс-фида на тот же блок), и метод учета стоимости позиции (FIFO против средневзвешенной). Nansen обычно нормализует все это под капотом, поэтому чтобы совпасть с ним, нужно воспроизвести именно его логику матчинга покупок и продаж.

Я плотно работаю с крипто-API и с обработкой транзакционных данных на Python, так что подход был бы такой: беру несколько конкретных кошельков, где у вас наибольшее расхождение с Nansen, раскладываю их сделки по шагам и показываю, на каком именно правиле возникает дельта, а дальше корректирую расчет под эти правила.

По опыту: Moralis и работа с on-chain историей, свопами и токен-трансферами, и расчет метрик поверх этого. С Nansen и DeFiLlama работал как с источниками данных для сверки. Чтобы оценить сроки и стоимость, скиньте, пожалуйста, 2-3 кошелька с периодом, где расхождение видно наиболее ярко, тогда отвечу предметно.

  • Проекты 9
  • Оценка -
  • Рейтинг 536

Бюджет: 7500 UAH Срок: 5 дней

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

Опыт с Nansen, Moralis и DeFiLlama как API-клиентом отсутствует, честно скажу. Но опыт есть с TypeScript, аналитикой и построением расчетных пайплайнов. Чтобы понять, где расхождение, первым шагом нужно взять конкретный кошелек, пройтись по каждой транзакции вместе с вашим кодом и посмотреть, какое правило классификации приводит к другому числу, чем то, что показывает Nansen. После диагностики будет понятно, является ли это вопросом маппинга событий, цены на момент сделки или логики FIFO/LIFO для cost basis.

Если задача исключительно аналитическая (разобраться в логике и пофиксить расчет), ориентировочно 2-5 дней в зависимости от количества edge cases. Готов начать с аудита текущей логики.

Написал бы в личные, чтобы уточнить детали.

  • Проекты -
  • Оценка -
  • Рейтинг 278

Бюджет: 19000 UAH Срок: 9 дней

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

  • Проекты 4
  • Оценка 5.0
  • Рейтинг 2 025

Бюджет: 1000 UAH Срок: 1 день

Здравствуйте!

У меня есть опыт работы с перечисленными технологиями.
Готов выполнить поставленную задачу.

Предлагаю обсудить детали в личных сообщениях.

  • Проекты 48
  • Оценка 5.0
  • Рейтинг 3 481

Бюджет: 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 токены и разные источники цены на момент сделки.

Буду рад сотрудничеству!

  • Проекты -
  • Оценка -
  • Рейтинг 117

Бюджет: 20000 UAH Срок: 15 дней

Доброго дня!

У меня есть опыт работы с blockchain API, обработкой транзакций и расчетом финансовых метрик. С Moralis работал, интегрировал API для получения ончейн-данных. С Nansen и DeFiLlama не работал напрямую, но знаком с их назначением и документацией.

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

  • Проекты 6
  • Оценка 5.0
  • Рейтинг 1 053

Бюджет: 22500 UAH Срок: 3 дня

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

  • Проекты -
  • Оценка -
  • Рейтинг 429

Бюджет: 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.

  • Проекты 37
  • Оценка 5.0
  • Рейтинг 2 335

Бюджет: 3000 UAH Срок: 3 дня

Доброго дня, я делал платформу https://www.updownxpro.com - опыта с этими инструментами нет, но думаю, что разберусь.

  • Проекты -
  • Оценка -
  • Рейтинг 274

Бюджет: 12345 UAH Срок: 123 дня

Привет, у меня есть опыт в написании торговых ботов, буду рад помочь. Есть свой проект cobwebscan для анализа сети солана (сейчас он не стоит на хостинге, но при необходимости для обзора могу поставить). Я должен увидеть сам код, и только потом смогу сказать конкретные сроки и цену, буду рад сначала пообщаться в личных сообщениях.

  • Проекты -
  • Оценка -
  • Рейтинг 196

Бюджет: 27000 UAH Срок: 12 дней

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

По стоимости - примерно 65000 грн.
По срокам - 10-12 рабочих дней, если код и примеры расхождений доступны с первого дня.

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

Ставки скрыты

В списке не показаны ставки, скрытые заказчиком или фрилансером c профилем Plus, а также ставки, нарушающие правила