Budżet: 7022 UAH Termin: 2 dni
Добрый день за 10-12 часов справлюсь. Обращайтесь.
Переписка в ЛС...
у нас есть 2 Смарт Контракта, и есть список исправлений по ним, нужно все исправления сделать за сегодня, их немного. все данные предоставлю в лс.
Сами ошибки
Critical Severity
• Line 251 – There is no checking if the referrer is same as referral. This allows users to make self referred deposits
• Line 187,192,197,202 – Owner has high privilages to change tokenomics and passive contracts anytime
Medium Severity
• Line 207 – Fallback function is commented out
• Line 930 – setPassive function is accessible to public. Better restrict it to onlyOwner
• Line 259,1036 – Functions defined, but not used even once in the contract
Low Severity
• Line 584,595,606,617,628,639,650,661,672,683,694,705 – Use a common function which can call these functions by a given parameter. It will reduce the code length greatly
• Line 80,85,168,187,192,202,266,502,577 – Usage of external instead of
public is more promoted
• Line 906,907,1054 – Visibility is not defined
Other Findings
• Line 226 – Storing loop control variable in another variable will reduce gas fee
• Line 266 – Using pre computed values will help reducing gas fee (ex:10*6 can be directly written as 60)
• Line 266 – Use loop to fold the if conditions and reduce size of code
• Safemath is used excessively. Only use safemath when there is a chance of arithmetic overflow occurs
Potrzebny streamer, najlepiej mający subskrybentów na Twitchu, im więcej subskrybentów, tym lepiej. Należy zareklamować stronę, aby jak najwięcej ludzi się o niej dowiedziało.
Szukamy specjalisty ds. bezpieczeństwa aplikacji Solana do przeprowadzenia audytu smart kontraktu przed wdrożeniem na mainnet. Stos technologiczny kontraktu: Rust + framework Anchor Token SPL (przelew/przechowywanie tokenów w PDA) Mekaniki: rundy z czasem, escrow zakładów, resolver ceny końcowej, obliczanie i dystrybucja wypłat, instrukcje roszczeń, awaryjne wstrzymanie + zwrot, ustawienie prowizji przez admin authority Sprawdzenie pod kątem typowych luk w Solana/Anchor: brak kontroli właściciela/podpisu, walidacja konta, przepełnienie całkowite, kolizje nasion PDA, wzorce reentrancy, przywileje kluczy authority Analiza logiki dystrybucji wypłat (zaokrąglanie, edge cases z wieloma uczestnikami) Sprawdzenie mechanizmów awaryjnych (wstrzymanie, zwrot) — czy nie można ich obejść lub nadużyć Raport z klasyfikacją ustaleń według krytyczności (Critical/High/Medium/Low) oraz rekomendacjami Powtórna weryfikacja po poprawkach (re-audit fixes) Wymagania dla wykonawcy: Potwierdzone doświadczenie w audycie lub rozwoju aplikacji Solana (Rust/Anchor) — prosimy o linki do GitHub, wcześniejsze audyty lub przykłady znalezionych luk Znajomość specyfiki Token SPL oraz wzorców escrow PDA Doświadczenie z narzędziami analizy statycznej (Soteria, Sec3, cargo-audit) będzie plusem W odpowiedzi prosimy o podanie: Doświadczenia z Solana (nie EVM) — konkretne projekty Orientacyjną cenę i czas realizacji dla kontraktu o takim zakresie Format raportu (przykład, jeśli jest)
Co liczymy w projekcie: Zrealizowany PnL, ROI i Wskaźnik Wygranych dla portfeli kryptowalutowych - jak rentowny był portfel w handlu danym tokenem w wybranym okresie. Na jakich danych: historia transakcji on-chain portfela (swapy, przelewy tokenów) + cena rynkowa tokena w momencie każdej transakcji. Główne źródło danych - Moralis: dwa wywołania podczas początkowego załadowania portfela - natywne przelewy ETH i wszystkie przelewy tokenów ERC-20. Z czym porównujemy: Nansen.io - bierzemy jako wzorzec, porównujemy nasze obliczone metryki z tym, co pokazuje Nansen dla tych samych portfeli w tym samym okresie. Problem: nasze liczby znacznie różnią się od Nansen, i nie do końca rozumiemy, według jakich zasad część działań portfela powinna być klasyfikowana dla celów PnL. Należy poprawić obliczenia Zrealizowanego PnL, ROI i Wskaźnika Wygranych, aby zgadzały się z Nansenem. W zgłoszeniu proszę napisać: - doświadczenie w podobnych zadaniach - doświadczenie z Nansen - doświadczenie z Moralis - doświadczenie z DeFiLlama - doświadczenie z artykułami na temat operacji kryptowalutowych - przybliżony koszt i terminy poprawek
Rozpoczęcie jest ważne - DZISIAJ Potrzebuję osoby, która ma doświadczenie w pisaniu botów handlowych na DEX-ach (potrzebne w sieci BSC) zrozumienie kosztów transakcji, gazu itd. Chcę przetestować kilka strategii handlowych na rzeczywistym agencie handlowym Muszę szybko opracować autonomicznego agenta handlowego, który wykorzystuje API Trust Wallet i CoinMarketCap do realizacji transakcji w sieci BNB Chain (BSC) na podstawie 3–5 wbudowanych strategii. Stos technologiczny (obowiązkowy) - Trust Wallet Agent Kit (TWAK) — do samokastodialnego podpisywania i realizacji transakcji (https://portal.trustwallet.com) - CoinMarketCap AI Agent Hub — do uzyskiwania danych rynkowych i sygnałów (https://coinmarketcap.com/api/agent) - BNB AI Agent SDK — do szybkiej integracji (https://github.com/bnb-chain/bnbagent-sdk) Wymagania funkcjonalne Dane (CMC AI Agent Hub) - Uzyskiwanie danych przez MCP lub x402 (https://coinmarketcap.com/api/agent) - Wykorzystanie gotowych Skills dla RSI, MACD, Fear & Greed, wolumenów Wykonanie (Trust Wallet Agent Kit) - Lokalne podpisywanie transakcji — klucze pozostają u użytkownika (https://portal.trustwallet.com) - Tryb autonomiczny: agent sam podpisuje i wysyła transakcje - Ograniczenia: spadek (drawdown), dzienny limit, stop-loss, biała lista tokenów - Wykorzystanie x402 do płatności za dane/obliczenia Strategie - Zrealizować 3–5 opisanych strategii z możliwością przełączania między nimi - Przykłady: kombinacja funding rates + Fear & Greed, DCA na podstawie nastrojów z filtrami Wymagania techniczne - Język: Python (preferowany) lub TypeScript/JavaScript - Narzędzia: TWAK CLI, CMC CLI, BNB AI Agent SDK Kto może się tym zająć?