Poprawić obliczenia Realized PnL, ROI i Win Rate dla portfeli kryptowalutowych

Budżet: 4500 UAH Termin: 5 dni

Dzień dobry! Zajmę się zebraniem waszych Realized PnL / ROI / Win Rate do cyfr Nansen — z danymi Moralis (natywne przelewy ETH + przelewy ERC-20) pracowałem, logikę budowy metryk na podstawie historii on-chain robię.

W zasadzie: kiedy własne liczby „pływają” w stosunku do Nansen, prawie zawsze przyczyna leży w zasadach klasyfikacji, a nie w samych danych. Typowe rozbieżności — metoda obliczania kosztów (FIFO vs weighted-average, Nansen liczy średnią ważoną), jak traktowane są samoprzewody/wrap-unwrap/bridge (nie można ich liczyć jako buy/sell), czy uwzględniać opłaty gazowe w podstawie kosztów, i skąd bierze się cena dla nielikwidnych tokenów w momencie transakcji. To właśnie tutaj zazwyczaj gromadzi się delta.

Doświadczenie: integracje REST-API + przetwarzanie transakcji on-chain, statystyka dotycząca operacji kryptowalutowych. Z Moralis — tak (oba wywołania, które opisaliście). DeFiLlama — brałem stamtąd historyczne ceny. Nansen wewnętrznie nie jest rewersyjny, ale zadanie jest właśnie takie — dopasować naszą klasyfikację do ich wyniku na wspólnych portfelach za ten sam okres, iteracyjnie.

Pytanie, aby dokładnie trafić: rozbieżność jest systemowa (wszystkie portfele przesunięte w jednym kierunku) czy zmienia się w zależności od konkretnych tokenów? I potrzebujecie zgodności „punkt-w-punkt” z Nansen czy w ramach rozsądnego tolerancji?

Jestem gotów wziąć jeden wasz portfel, gdzie liczby się rozchodzą, pokazać gdzie dokładnie łamie się logika i przesłać analizę na czacie.

Orientacyjnie: 4500 zł, 4-5 dni. Biorę na start — zbieram pierwsze opinie tutaj, dlatego robię to korzystnie.

Piotr Pankow, BotCraft Group Rozwiń

Budżet: 27000 UAH Termin: 10 dni

Ocena - orientacyjnie 45 000 UAH i 10 dni roboczych. Jeśli po uzyskaniu dostępu do kodu okaże się, że problem nie dotyczy tylko formuł, ale także surowych danych lub cen, wtedy zakres może się zmienić, ale można zacząć od tego etapu.

Pracowaliśmy z kryptostatystyką, obliczeniami finansowymi i weryfikacją wskaźników z wzorcowymi usługami. Z Nansen - jako odniesienie do porównania PnL, ROI i Win Rate. Z Moralis - w zakresie historii on-chain, transferów ERC-20 i transferów natywnych. Z DeFiLlama - w zakresie historycznych cen i weryfikacji danych rynkowych. W takich zadaniach jedna pomyłka w klasyfikacji transferu, swapu, opłaty, airdropu lub częściowej sprzedaży łatwo psuje cały obraz =/

Zacząłbym nie od poprawiania formuł, a od kontrolnej próby portfeli. Należy oddzielić faktyczne transakcje od przelewów, opisać zasady klasyfikacji operacji, znormalizować cenę tokena w momencie transakcji, uwzględnić prowizje, częściowe sprzedaże, wewnętrzne przelewy i przypadki bez ceny. Następnie - tabela rozbieżności dla każdego tokena i udowodnienie logiki do zgodności z Nansen lub osobne wyjaśnienie miejsc, gdzie Nansen nie ujawnia zasady.

Od Ciebie potrzebny jest dostęp do kodu modułu obliczeniowego, przykłady 5-10 portfeli, okres weryfikacji, zrzuty ekranu lub eksport z Nansen oraz aktualny wynik Twoich obliczeń.

> Pytanie 1 - jakie sieci są obecnie w obliczeniach, tylko Ethereum czy są jeszcze Base, Arbitrum, BSC, Solana?
> Pytanie 2 - czy już przechowujecie historyczne ceny dla każdej transakcji, czy ceny są pobierane podczas przeliczenia?

Podobne logicznie przypadki Ingello
> https://business.ingello.com/platforma - skomplikowany system korporacyjny z rolami, danymi i raportowaniem
> https://business.ingello.com/vorfahr - SaaS z integracjami, przetwarzaniem danych i automatyzacją aplikacyjną
> https://business.ingello.com/fractal - automatyzacja skomplikowanych procesów inżynieryjnych

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

Budżet: 10000 UAH Termin: 4 dni

Dzień dobry. Zbadałem zadanie. Główną przyczyną rozbieżności z Nansen jest nieprawidłowe uwzględnienie FIFO/LIFO przy częściowych sprzedażach, ignorowanie opłaty za gaz w kosztach tokena oraz błędne oznaczanie zwykłych transferów/puli płynności jako transakcji.

Rozwiązanie techniczne:
W TypeScript/Node.js przepiszę logikę przetwarzania tablic z Moralis. Wprowadzę surowy algorytm FIFO dla Realized PnL. Swap'y będę identyfikować na podstawie zgodności transaction_hash między natywnymi przelewami a ERC-20, dodając wydany gaz do wartości pozycji. Dla tokenów, które przyszły zwykłym transferem (bez swapu), pobiorę historyczną cenę w momencie bloku przez API DeFiLlama. Na podstawie wyrównanego PnL przeliczę ROI oraz Win Rate (procent zamkniętych na plus tokenów).

Doświadczenie według waszych punktów:

Podobne zadania & Krypto-statystyka: Opracowywałem niestandardowe narzędzia do śledzenia portfeli, znam matematykę metryk on-chain oraz przetwarzanie surowych transakcji.

Nansen: Używam jako analitycznego wzorca, rozumiem ich logikę śledzenia Smart Money.

Moralis & DeFiLlama: Stale pracuję z Token API od Moralis do zbierania transferów oraz Price API od DeFiLlama do historycznych notowań.

Plan i terminy:
W ciągu 4 dni przeprowadzę audyt waszego kodu, przepiszę kalkulację według FIFO z uwzględnieniem gazu oraz skalibruję metryki według testowych portfeli, aby liczby całkowicie zgadzały się z Nansen.

Pytanie dotyczące zadania:
Jak obecnie wasz system oznacza przychodzące transfery tokenów, które nie są wynikiem swapu na DEX — traktuje je jako zakup po cenie zerowej czy bierze rynkową wartość w momencie transakcji? Rozwiń

Budżet: 15000 UAH Termin: 7 dni

Dzień dobry! Mamy doświadczenie w opracowywaniu systemów analitycznych dla danych blockchain. Realizujemy poprawne obliczenia Realized PnL, ROI oraz Win Rate poprzez budowę dokładnego łańcucha transakcji i integrację historycznych cen tokenów. To zapewni wysoką dokładność raportowania finansowego dla Twojej usługi. Jesteśmy gotowi przystąpić do analizy architektury i optymalizacji algorytmów przetwarzania danych on-chain.

Budżet: 10000 UAH Termin: 5 dni

Cześć, Pawle! Rozbieżność metryk z Nansen przy parsowaniu surowych danych z Moralis to klasyczny problem analityki on-chain. Moralis dostarcza liniową historię zdarzeń Transfer, podczas gdy Nansen wykorzystuje złożone modele heurystyczne do filtrowania szumów.

Dlaczego twoje liczby różnią się teraz:

Metoda księgowania (Cost Basis): Dla obliczenia Realized PnL kluczowa jest kolejność. Jeśli twój obecny algorytm używa średniej ceny tokena, a referencja liczy metodą FIFO (First-In, First-Out) z dokładnym dopasowaniem konkretnych partii zakupu i sprzedaży, ostateczny wynik będzie diametralnie inny.

Błędny zamiar transakcji: Surowe transfery ERC-20 obejmują staking, minting, spalanie, przelewy między własnymi portfelami oraz pracę z mostami. Nansen oznacza je jako wewnętrzne przemieszczenia i nie uwzględnia w handlowym PnL, podczas gdy twój algorytm prawdopodobnie traktuje to jako zwykły napływ lub odpływ tokenów.

Opłaty za gaz: Nansen kapitalizuje koszty gazu (w natywnym ETH) w koszt pozycji, co znacząco zmienia netto ROI oraz końcowy wskaźnik wygranych.

Moje doświadczenie i odpowiedzi na twoje pytania:

Doświadczenie w podobnych zadaniach i operacjach kryptograficznych: Piszę złożone analityczne i ETL-pipeline'y do przetwarzania danych on-chain, projektuję logikę dla trackerów portfeli i desktopowych narzędzi. Rozumiem mechanikę działania routerów DEX (Uniswap V2/V3 itp.).

Praca z Moralis, Nansen, DeFiLlama: Regularnie pracuję z danymi DeFi. Dobrze znam API Moralis (wiem, jak wyciągać zdarzenia i historyczne punkty cenowe w momencie konkretnego bloku) oraz zintegrowałem dane historyczne z DeFiLlama. Rozumiem logikę analitycznych dashboardów Nansen, wiem, jak rekonstruować ich metryki.

Plan działania: Przeprowadzę audyt twojego obecnego kodu, wyodrębnię transakcje-wykluczenia (które nie są handlem), ustawię jasną kolejność rozliczania partii według FIFO oraz zsynchronizuję logikę obliczania wskaźnika wygranych / ROI z etalonem.

Jestem gotów szczegółowo omówić kilka konkretnych przypadków portfeli na czacie! Rozwiń

Budżet: 12300 UAH Termin: 3 dni

Dzień dobry,

mam doświadczenie w opracowywaniu i debugowaniu obliczeń finansowych w TypeScript/Node.js, w szczególności w pracy z danymi on-chain oraz zewnętrznymi API (Moralis i podobne). Z Nansen jako wzorcem musiałem porównywać się w zadaniach analizy portfeli, rozumiem logikę klasyfikacji swapów vs. transferów dla celów PnL.

Podejście: podniosę pełny flow obliczenia Realized PnL, ROI i Win Rate, porównam metodologię z tym, jak Nansen klasyfikuje działania (wejście/wyjście pozycji, częściowe sprzedaże, opłaty), znajdę rozbieżności i poprawię logikę. Przybliżony koszt fixu - od 300$ w zależności od głębokości problemu i liczby edge-case'ów, termin - 3-7 dni po zapoznaniu się z kodem.

Zgłaszajcie się, omówimy szczegóły osobiście!

Budżet: 10000 UAH Termin: 5 dni

Dzień dobry. Zrozumiałem istotę: obliczacie Realized PnL, ROI i Win Rate dla portfeli na podstawie historii on-chain z Moralis (przelewy natywne plus transfery ERC-20) oraz ceny rynkowej w momencie transakcji, a liczby nie zgadzają się z Nansen, który bierzecie za wzór.

Z doświadczenia takie rozbieżności prawie zawsze wynikają z zasad klasyfikacji zdarzeń, a nie z samej formuły. Typowe miejsca, gdzie liczby się rozjeżdżają: uwzględnienie gazu i prowizji, swapy przez kilka hopów (gdy jedna transakcja wygląda jak kilka transferów), wewnętrzne przelewy między własnymi portfelami, które nie powinny być traktowane jako transakcje, wybór ceny (cena swapu z samej transakcji w porównaniu do zewnętrznego źródła cenowego dla tego samego bloku) oraz metoda obliczania wartości pozycji (FIFO w porównaniu do średniej ważonej). Nansen zazwyczaj normalizuje to wszystko w tle, dlatego aby się z nim zgodzić, trzeba odtworzyć jego logikę dopasowywania zakupów i sprzedaży.

Ściśle współpracuję z API kryptowalutowymi i przetwarzaniem danych transakcyjnych w Pythonie, więc podejście byłoby takie: biorę kilka konkretnych portfeli, gdzie macie największą rozbieżność z Nansen, rozkładam ich transakcje krok po kroku i pokazuję, na której zasadzie powstaje delta, a następnie dostosowuję obliczenia do tych zasad.

Z doświadczenia: Moralis i praca z historią on-chain, swapami i transferami tokenów oraz obliczanie metryk na ich podstawie. Z Nansen i DeFiLlama pracowałem jako źródłami danych do weryfikacji. Aby ocenić terminy i koszty, proszę o przesłanie 2-3 portfeli z okresem, w którym rozbieżność jest najbardziej widoczna, wtedy odpowiem konkretnie.

Budżet: 7500 UAH Termin: 5 dni

Zadanie jest znane: obliczenie Realized PnL na podstawie danych on-chain wymaga jasnego zrozumienia, jak klasyfikować każdą akcję portfela. W przypadku swapów, przelewów między własnymi adresami i płynności w pulach ta sama transakcja może być interpretowana na różne sposoby, co najczęściej prowadzi do rozbieżności z platformami referencyjnymi takimi jak Nansen.

Nie mam doświadczenia z Nansen, Moralis i DeFiLlama jako klient API, szczerze mówiąc. Ale mam doświadczenie z TypeScript, analityką i budowaniem pipeline'ów obliczeniowych. Aby zrozumieć, gdzie jest rozbieżność, pierwszym krokiem należy wziąć konkretny portfel, przejść przez każdą transakcję razem z twoim kodem i zobaczyć, która zasada klasyfikacji prowadzi do innej liczby niż ta, którą pokazuje Nansen. Po diagnozie będzie jasne, czy to kwestia mapowania zdarzeń, ceny w momencie transakcji, czy logiki FIFO/LIFO dla kosztów podstawowych.

Jeśli zadanie jest wyłącznie analityczne (zrozumieć logikę i poprawić obliczenia), to około 2-5 dni w zależności od liczby edge cases. Jestem gotów zacząć od audytu obecnej logiki.

Napisałbym na prywatne, aby wyjaśnić szczegóły.

Budżet: 19000 UAH Termin: 9 dni

Dzień dobry! Liczyłem Realized PnL i ROI na podstawie historii on-chain przez Moralis i porównywałem wskaźniki z Nansen — temat jest mi znany. Najczęściej liczby się rozchodzą nie przez same formuły, a przez klasyfikację: swap myli się z prostym transferem, częściowe sprzedaże i prowizje łamią cost-basis. Zacząłbym od próby 5-10 portfeli i tabeli rozbieżności po tokenach, aby doprowadzić obliczenia do zgodności z etalonem. Jakie sieci są teraz brane pod uwagę — tylko Ethereum czy jeszcze Base/Arbitrum/BSC? Zajmę się tym, orientacyjnie 9 dni.

Budżet: 1000 UAH Termin: 1 dzień

Cześć!

Mam doświadczenie w pracy z wymienionymi technologiami.
Jestem gotów wykonać postawione zadanie.

Proponuję omówić szczegóły w wiadomościach prywatnych.

Budżet: 6000 UAH Termin: 3 dni

Dzień dobry!
Pracowałem z analizą on-chain oraz obliczaniem PnL - mam doświadczenie w integracji z API Binance, Bybit, OKX, Kraken, KuCoin, Gate.io, a także stworzyłem skrypt do śledzenia transakcji przez bramkę Solana i zbudowałem Binance Wallet Tracker z obliczaniem PnL (https://freelancehunt.com/showcase/work/binance-wallet-tracker/1853339.html).

Moralis, Nansen i DeFiLlama nie używałem bezpośrednio, ale logika obliczania Realized PnL, klasyfikacja transakcji i metodologia cost basis - to znane tematy z innych projektów.
Najprawdopodobniejsze przyczyny rozbieżności z Nansen: różna klasyfikacja wewnętrznych transferów, tokeny LP i różne źródła cen w momencie transakcji.

Będę zadowolony ze współpracy!

Budżet: 20000 UAH Termin: 15 dni

Dzień dobry!

Mam doświadczenie w pracy z blockchain API, przetwarzaniu transakcji oraz obliczaniu metryk finansowych. Pracowałem z Moralis, integrowałem API do pozyskiwania danych on-chain. Z Nansen i DeFiLlama nie pracowałem bezpośrednio, ale jestem zaznajomiony z ich przeznaczeniem i dokumentacją.

Rozumiem, że główną trudnością zadania nie są same wzory PnL/ROI/Wskaźnik Zysków, ale prawidłowa klasyfikacja operacji on-chain i dostosowanie logiki do wyników Nansen.

Budżet: 22500 UAH Termin: 3 dni

Dzień dobry.
Moje doświadczenie jest bezpośrednio związane z infrastrukturą kryptowalutową, budową giełdy kryptowalut, międzynarodowym strukturyzowaniem biznesu kryptowalutowego oraz analizą transakcji blockchain. Mam również praktyczne doświadczenie w zakresie ekonomii operacji kryptowalutowych, PnL, logiki handlowej oraz budowy modeli obliczeń wskaźników finansowych.
Odpowiedzi na Państwa pytania:
- mam doświadczenie w analizie operacji kryptowalutowych, budowie logiki finansowej oraz modeli PnL.
- nie miałem bezpośredniej integracji, ale rozumiem zasady analityki portfeli oraz metodologię obliczeń.
- dobrze rozumiem strukturę API oraz danych on-chain.
- używam jako narzędzie analityczne.
- mam praktyczne doświadczenie w obliczaniu PnL, ROI oraz analizie transakcji blockchain.
Jeśli chodzi o przyczynę rozbieżności, najprawdopodobniej problem leży w logice klasyfikacji transakcji i obliczaniu cost basis, a nie w samych danych.
Wstępnie oceniłbym to na 500 dolarów. Ostateczny budżet mogę podać po zapoznaniu się z aktualną realizacją. Czy potrzebują Państwo tylko analizy metodologii i zasad obliczeń, czy także wprowadzenia zmian w kodzie?

Budżet: 2000 UAH Termin: 2 dni

Cześć, Pawle! Doskonale rozumiem zadanie. Różnice z Nansen zazwyczaj tkwią w logice uwzględniania swapów deksowych (gdy transakcja jest traktowana jako jedna operacja sprzedaży/zakupu, a nie po prostu dwa oddzielne transfery), a także w poprawnym obliczaniu średniej ceny wejścia (niestandardowy FIFO/LIFO).

Odpowiadam na Twoje punkty:
1. Doświadczenie w podobnych zadaniach: Opracowywałem logikę kalkulatorów i agregacji danych dla dashboardów w React/TypeScript. Dobrze znam matematykę PnL (zrealizowany/niezrealizowany) i ROI.
2. Doświadczenie z Nansen: Aktywnie korzystam z platformy jako analityk, dokładnie znam, jak działa interfejs tokenów i portfeli (Smart Money, Token God Mode). Rozumiem, do jakiego wzorca należy doprowadzić liczby.
3. Doświadczenie z Moralis: Zintegrowałem ich Web3 API do uzyskiwania historii transakcji, sald i metadanych ERC-20 / natywnego EVM.
4. Doświadczenie z DeFiLlama: Używałem ich API do pobierania historycznych cen tokenów w momencie dokonania transakcji (sekcja /prices) — to krytyczne dla dokładnego obliczania PnL.
5. Doświadczenie z artykułami o operacjach kryptograficznych: Regularnie badam mechanikę działania pul płynności, stakingu i tokenów wrapped, aby poprawnie klasyfikować „niestandardowe” transakcje.

Przybliżony koszt i czas: Aby podać dokładną kwotę, trzeba spojrzeć na aktualną funkcję JS/TS do obliczeń. Proponuję założyć około 1500–2500 UAH i 2-3 dni na szczegółowe testy i weryfikację z Nansen.

Jestem gotów omówić kod i logikę na czacie! Rozwiń

Budżet: 3000 UAH Termin: 3 dni

Dzień dobry, robiłem platformę https://www.updownxpro.com - nie mam doświadczenia z tymi narzędziami, ale myślę, że sobie poradzę.

Budżet: 12345 UAH Termin: 123 dni

Cześć, mam doświadczenie w pisaniu botów handlowych, chętnie pomogę. Mam swój projekt cobwebscan, do analizy sieci Solana (obecnie nie jest hostowany, ale w razie potrzeby mogę go uruchomić do przeglądu). Muszę zobaczyć sam kod, a dopiero potem będę mógł podać konkretne terminy i cenę, chętnie najpierw porozmawiam osobiście.

Budżet: 27000 UAH Termin: 12 dni

Mam już praktycznie gotowe podobne rozwiązanie do obliczania metryk dla portfeli kryptowalutowych, które można szybko dostosować do waszego modelu i porównania z Nansen, proponuję omówić szczegóły tutaj na giełdzie, jestem w kontakcie ))

Co do kosztów - około 65000 UAH.
Co do terminów - 10-12 dni roboczych, jeśli kod i przykłady rozbieżności będą dostępne od pierwszego dnia.

Mam doświadczenie w zadaniach, gdzie trzeba zredukować transakcje, ceny rynkowe, wewnętrzną klasyfikację działań portfela i końcową statystykę.
Z Nansen pracowaliśmy jako z etalonem do porównania metryk.
Z Moralis - przy wydobywaniu przelewów, wydarzeń ERC-20, swapów i normalizacji historii portfela.
Z DeFiLlama - przy szeregach cenowych i weryfikacji danych, gdy trzeba nie polegać na jednym źródle.

Mogę podejść praktycznie - najpierw bierzemy 3-5 portfeli, gdzie różnica z Nansen jest największa, rozkładamy po operacjach i znajdujemy zasady, przez które łamie się Realized PnL, ROI lub Win Rate.
Po tym poprawiamy formuły, klasyfikację buy, sell, transfer, fee, bridge, airdrop, liquidity, i dodajemy testy weryfikacyjne, aby liczby nie poszły dalej.

Uściślenie.
- Czy jest już dostęp do kodu obliczeń i przykłady konkretnych portfeli, gdzie widać różnicę z Nansen.
- Jakie sieci trzeba pokryć na pierwszym etapie - tylko Ethereum czy także Base, Arbitrum, BSC, Solana.

Relewantne przykłady.
https://business.ingello.com/vorfahr - skomplikowana automatyzacja z danymi, logiką i weryfikacją wyników.
https://business.ingello.com/fractal - systemy z logiką agenta i scenariuszami analitycznymi.

O nas dla Freelancehunt.
https://systems-fl.ingello.com/ua Rozwiń