Budżet: 10000 UAH Termin: 15 dni
Realizacja jest możliwa. Terminy są orientacyjne. Cena jest szacunkowa. Bardziej konkretnie tylko po doprecyzowaniu TZ (w formularzu są pytania). Jestem gotów się tym zająć.
Musisz mintować NFT za pomocą oprogramowania, używając prywatnych kluczy z portfeli i możliwości dodania proxy. UI nie jest konieczne. Należy zapisać wynik w pliku (adres portfela, prywatny klucz, czy się udało czy nie). Jednoczesne mintowanie ze wszystkich wypełnionych portfeli. Jeśli masz gotowe rozwiązanie, chętnie je rozważę. Mile widziane są propozycje z Twojej strony dotyczące sposobu, w jaki będzie określany początek możliwości mintowania. Na przykład uruchamiam oprogramowanie, trwa faza WL, a w momencie otwarcia publicznego mintowania oprogramowanie zaczyna mintować samodzielnie. Preferowane jest, aby oprogramowanie było napisane w Pythonie, ale jeśli istnieje opcja, która działa lepiej w innym języku, można również ją wykorzystać. Chcę usłyszeć Twoje propozycje dotyczące ceny, budżet ustalam w przybliżeniu na podstawie cen, które widziałem podczas wyszukiwania w Google.
Budżet: 10000 UAH Termin: 15 dni
Realizacja jest możliwa. Terminy są orientacyjne. Cena jest szacunkowa. Bardziej konkretnie tylko po doprecyzowaniu TZ (w formularzu są pytania). Jestem gotów się tym zająć.
Budżet: 10000 UAH Termin: 19 dni
Dzień dobry, byłoby interesująco spróbować opracować takie oprogramowanie, możemy na Pythonie, ale jeśli przewiduje się duże obciążenia, to lepiej na Go. Cena za projekt może się wahać w zależności od złożoności automatyzacji.
Budżet: 10000 UAH Termin: 4 dni
Cześć,
jestem gotów omówić ten projekt, mam doświadczenie w pracy z blockchainem. Pisz na priv
Минт на блокчейне солана. Нужно минтить по адресу контракта, к маркетплейсу не привязано так как может быть на сайте проекта раздача, тоесть сайт на котором раздача не должен играть роль.
1. О проекте NFT
- Какую коллекцию NFT мы будем минтить? (Название, адрес Candy Machine или смарт-контракта.)
- Есть ли какие-то уникальные особенности проекта? (Whitelist, Public Sale, редкость.)
- Какие данные уже есть:
- Метаданные NFT?
- Ссылки на IPFS или Arweave?
2. Технические требования
- Сколько кошельков предполагается использовать для минта?
- Есть ли готовый список кошельков с приватными ключами, или нужно создать новые?
- Требуется ли поддержка прокси-серверов? Если да, сколько и какой формат предоставления прокси?
- Будет ли использована асинхронная обработка? (Одновременный минт с нескольких кошельков.)
- Как часто нужно проверять доступность минта? (Интервал запросов.)
3. Финансовая часть
- Есть ли на всех кошельках достаточный баланс SOL для минта и оплаты комиссий?
- Какова минимальная и максимальная стоимость минта для данной коллекции?
- Какой план по работе с неудачными попытками минта (например, транзакции отклонены)?
4. Автоматизация процесса
- Требуется ли отслеживание начала публичного минта? (Например, мониторинг Candy Machine или веб-скрейпинг.)
- Нужно ли уведомлять о старте минта? (E-mail, Telegram, или уведомление в логах.)
- Нужно ли перезапускать скрипт автоматически в случае ошибок?
5. Результаты работы
- В каком формате сохранять результат минта? (CSV, JSON, или другой формат.)
- Какие данные записывать в результат:
- Адрес кошелька.
- Приватный ключ.
- Статус минта (успех/ошибка).
- Хэш транзакции.
- Нужно ли хранить логи работы программы? Если да, где?
6. Безопасность
- Как обеспечить безопасное хранение приватных ключей?
- Шифрование?
- Временное удаление после окончания работы?
- Как защищаться от бана или блокировки при использовании прокси?
7. Дополнительные пожелания
- Нужен ли интерфейс программы (GUI), или достаточно консольной версии?
- Есть ли ограничения по времени выполнения проекта?
- Какие дополнительные функции могут понадобиться? (Например, массовая проверка баланса кошельков.)
8. Тестирование
- Есть ли тестовая среда (Devnet) или отдельные кошельки для тестирования?
- Как будут проводиться проверки работоспособности программы?
Ответьте на эти вопросы в личные сообщения и возможно обсуждать дальнейшую реализацию Вашего проекта и соотвественно цену вопроса.
1,2,3 - Представим что есть некий минт нфт (для примера возьмём сегодняшний https://www.launchmynft.io/collections/4wR37muvWtz1bd4Phuce1ZeJuyJAC9DkE5Yr6nKRtW2g/LRN2rV9JrUYfgdDGQAMC) у меня есть адрес контракта этой нфт и после конца WL минта мне надо начинать минтить на свои кошельки. Как вы понимаете никаких ссылок у меня дополнительно нет.
4,5,6,7,8 - Кошельки уже есть, сейчас есть 3 готовых и планирую добавить ещё 2шт. От софта не требуется создавать новые. Поддержа прокси нужна в произвольном удобном для вас формате. Асинхронность нужна, для минта одновременно со всех кошельков которые будут загружены. Прокси нужно поддерживать на каждый кошелек отдельно.
9,10,11 - на всех кошельках достаточно соланы для минта, я прослежу за этим так как стоимость минта я знаю. При неудачной транзакции нужна возможность включить или выключить повышение газа за транзакцию для повышения шансов успешного прохождения. Стоимость минта может быть абсолютно разной, я же так понимаю что я сам выставляю перед минтом какая будет стоимость минта конкретно данной нфт (возможность минта нескольких нфт на 1 кошелек тоже нужна). При неудачном минте просто продолжать работу пока я сам не выключууу скрипт
12,13,14 - отслеживать публичный минт необходимо для того чтобы скрипт самостоятельно начал минтить, как это будет происходить выбор за вами. Например сегодня кнопка минт стала активной когда начался публичный минт. Уведомлять о старте минта не надо, перезапускать при ошибке не надо, я сам выключу если будет необходимость
15,16,17 -
логи можно хранить просто рядом с исполняемым файлом. записывать результаты можно в таблицу csv, xlsx например, данные записывать просто адрес, успех, хэш
18,19 - безопасностью не нужно заниматься, просто пусть лежат в открытом виде у меня в файле. по поводу бана тоже не беспокойтесь
20,21,22 - интерфейс не нужен, по времени назовите самостоятельно сколько вам нужно для этого. Дополнительные функции могут понадобиться по ходу работы программы, если в будущем что-то будет нужно то можно будет дописать.
23,24 - тестовые кошельки я могу предоставить, работоспособность может проводиться на тестовой коллекции нфт.
для более деталного обсуждения можно прейти в дискорд и там всё обсудить если вам так удобно
Переходить на сторонние сервисы для общения не стоит, получим бан, у меня уже есть одно предупреждение. Откройте личную переписку в профиле, и я задам еще несколько вопросов. В целом мне понятен путь и я набросал первичный план дейтсивй по реализации, хотел вам показать
Rozwój Telegram Mini App (Bot + WebApp) do sprzedaży dóbr cyfrowych i walut w grach (Python / aiogram) Opis projektu: Wymagana jest разработка Telegram-bota z pełnoprawnym interfejsem WebApp do zautomatyzowanej sprzedaży dóbr cyfrowych (Telegram Stars, Telegram Premium, waluty w grach/donaty do PUBG Mobile, Steam i inne). Projekt nosi nazwę Aspect App. Główny nacisk kładzie się na szybkość działania, płynny UI/UX w stylu Web3/minimalizmu oraz pełną automatyzację wydawania towarów po dokonaniu płatności. Stos technologii: Backend: Python 3.10+, aiogram 3.x (FastAPI dla Webhook/API mile widziane). Baza danych: PostgreSQL / Redis (do sesji i cache'owania). Frontend (WebApp): React.js / Vue.js / Next.js (według uznania dewelopera, ważna jest szybkość i płynność animacji). Integracje: Telegram WebApp API. Główna funkcjonalność (MVP): 1. Część kliencka (Telegram Mini App): Główny ekran: Kategorie towarów (Aktywa Telegram, Donaty w grach). Siatka banerowa dla promocji. Katalog towarów: Karty towarów z wyborem objętości (na przykład: 50, 100, 500 Telegram Stars lub UC). Pola do wprowadzania danych gracza (Player ID do PUBG). Koszyk i Zamówienie: Szybki zakup w 2 kliknięcia. Moduł płatności: Integracja metod płatności (CryptoBot API / TON Connect / inne bramki fiatowe do uzgodnienia). Panel użytkownika: Historia zamówień, status realizacji, system poleceń (saldo wewnątrz aplikacji). 2. Panel administracyjny (wbudowany w WebApp lub oddzielny bot): Zarządzanie katalogiem (dodawanie/usuwanie towarów, zmiana cen). Monitorowanie zamówień i statystyki sprzedaży. System wysyłek do bazy użytkowników. 3. Logika automatyzacji (będzie plusem): Gotowość architektury do integracji z API dostawców (API do automatycznego zakupu Stars/UC). Na etapie MVP część towarów może być wydawana kodami z bazy danych. Co jest wymagane od wykonawcy: 1. Rozwój architektury bazy danych i backendu w Pythonie. 2. Wykonanie i integracja WebApp (projekt graficzny omówimy, ważny jest czysty styl Web3, Glassmorphism). 3. Ustawienie bezpiecznych transakcji i webhooków płatności. 4. Wdrożenie na serwer (Docker, Ubuntu, konfiguracja SSL). Wymagania dla kandydata: Doświadczenie w komercyjnej разработке Telegram WebApps od 1 roku. Posiadanie portfolio z uruchomionymi i działającymi Mini Apps (przesyłaj linki w odpowiedzi). Czysty, udokumentowany kod. Warunki pracy: Praca tylko przez Bezpieczną Transakcję (Sejf / Escrow) platformy. Płatność etapowa (dzielimy projekt na Sprint 1: Backend + Baza danych, Sprint 2: Frontend WebApp, Sprint 3: Integracja płatności i testy). Budżet: Do uzgodnienia z wybranym kandydatem (podaj swoją widełkę cenową i terminy w odpowiedzi)
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ąć?