A parser needs to be created to collect competitor prices, with a catalog of over 40,000 products. Access to the prices is only available under authorization.
Proposals concealed
Proposals are currently absent
Proposals concealed
Proposals concealed
-
Vladimir B 20 JuneСтратегий торговых много, идеальная точка входа всегда одна. И она не рассчитывается, хоть с бубном танцуйте. Сливаются не из-за того что вошли не удачно, сливаются потому что в один ордер сразу большой объем льют, и потому что стопы используете. Это я к тому, что не сходите с ума в поисках идеального алгоритма поиска точки входа их нет. Просто если рынок идёт против вас, докупайте, усредняйте и выходите в 0. Стоп лосс не окупается, смиритесь с этим .
-
Vladimir B 21 JuneБред. Это выпрашивать алгоритм, который снизить потери. Да сейчас на бегут и на сыпят. Секта "дай точку входа и озолочу", ещё в прошлом веке закрыли
-
Ivan Vinnik 21 JuneВы описываете мартингейл, а не торговую стратегию.
Он “работает” до первого тренда, который не вернулся. Потом счет умирает. Стоп лосс это не проигрыш, а цена выживания. Без стопа или другого жесткого risk-limit вы не управляете риском, а просто копите его в позиции
“Докупайте и выходите в 0” без лимита позиции, лимита убытка и тестов это не опыт, а рецепт слива, замаскированный под уверенность -
Vladimir B 21 JuneДа ёлки палки. Ну вот опять! Не видел ни одного бота со стопами который способен заработать. Стопы это для тех кто торгует руками, долго и нудно выбирает монету, шарится по телеграмм каналам, где он покупает сигнал мечты, а потом либо везёт, либо не везёт в следующий раз и сливается как всегда. А торговый бот, это программа у которой шансов со стопами нет ни каких. Сейчас заработать можно, только в долго срок без иллюзий и фантазий. Большой депозит, чтобы пережить просадку и адекватный Профит. Вся это бредятена на про расчетный стоп, тейк это для тех кто хочет чтобы их обманули.
-
Ivan Vinnik 21 JuneВы опять сводите все к “стопы работают / стопы не работают”, хотя вопрос вообще не в этом.
Стоп это не источник прибыли. Это один из способов ограничить хвостовой риск. Если у стратегии нет edge, ее не спасет ни стоп, ни отсутствие стопа. Но отсутствие стопа без другого жесткого risk-limit превращает систему в пересиживание убытка.
“Большой депозит и пережить просадку” - это не доказательство стратегии. Это ставка на то, что рынок вернется раньше, чем закончится капитал. Иногда вернется. Иногда нет.
Нормальная система описывается не словами “я не видел ботов, которые зарабатывают”, а тестами: edge, комиссии, спред, slippage, drawdown, position sizing, лимит риска, устойчивость на истории и forward-проверка. Без этого разговор превращается в рыночный фольклор -
Vladimir B 21 JuneНу что тут можно сказать в ответ, видно что много читаете, но мало торгуете. Но это придет с опытом, часто с отрицательным. Когда речь идёт о торговом боте и о стопах, ну типо чтобы минимизировать риски, а потом после 3,4 минимизаций сказать клиентам ну так бывает, и да именно так и бывает, вы отключите стопы и окажется что стратегии то и нет. А про тест на истории! Ну этим занимаются новички, а те что поумнее за это деньги не платят
-
Ivan Vinnik 22 Juneпожалуйста, поделитесь своей мудростью с комюнити этого сабредита r/algotrading
я думаю ваш подход - подход настоящего кванта -
Serhii Moshliak 22 JuneДобрый день. То что вы хотите в среде трейдеров со смехом называют КНОПКОЙ БАБЛО . Я с 14 года торгую и понял что лучшая стратегия это игра в долгую с фиксированным выкупом монет во время медвежки в крипте. И скальпинг в форексе. Без стопов! И в целом для получения 1,6 миллиона со 100$ всего 14 успешных удвоений баланса. Дальше 7 я не заходил. Не смотря на мой опыт и винрейт по сделкам в 86% я всё равно сливаю.
Я вам больше скажу что даже созданный мной первый в мире общий искусственный интелект AGI не сможет сделать это 😁
Но он может создать бота на основе моего опыта и он будет прибыльно и стабильно зарабатывать. Но это не значит что сливов не будет, этого фактически не возможно избежать. Если хотите зарабатывать в торговле а не сливать я сделаю но на основе своего опыта и понимания рынка и по своим стратегия. Ваш утопический сливатор делать бессмысленно разве что только совесть офнуть и заработать на вашем непонимании сути и ошибочности вашего подхода и используемых стратегий.
-
Yurii Koshliak 4 JulyАВТОНОМНА ТОРГОВА СИСТЕМА МУЛЬТИАКТИВНОГО МОНІТОРИНГУ ТА АВТОУПРАВЛІННЯ (24/7)
ПРИНЦИП РОБОТИ ПРОГРАМИ:
Скрипт є повністю автономним торговим роботом, який працює у безперервному
циклі (while True) з інтервалом перевірки 60 секунд. Алгоритм інтегрується з
терміналом MetaTrader 5 через API, паралельно аналізуючи 5 різнопланових ринків:
валюту (EURUSD), дорогоцінні метали (XAUUSD, XAGUSD), криптоактиви (BTCUSD) та
фондові індекси (.US500Cash).
Процес обробки кожного активу складається з 4 послідовних етапів:
1. Структурний аудит брокера (перевірка ліквідності та доступності сесії).
2. Завантаження історичних даних (масив із 300 свічок таймфрейму H1).
3. Математичний аналіз ринку через комплекс технічних індикаторів (бібл. 'ta').
4. Автоматична генерація сигналів, вирахування ризиків та відправка ордерів
брокеру із миттєвим звітуванням у Telegram.
БАГАТОFAКТОРНА СИСТЕМА МІНІМІЗАЦІЇ РИЗИКІВ (ПРОТОКОЛИ БЕЗПЕКИ КАПІТАЛУ):
Для виключення людського фактора та захисту депозиту від агресивного ринкового
середовища в код інтегровано три рівні броні:
1. МАТЕМАТИЧНА ФІЛЬТРАЦІЯ ХИБНИХ СИГНАЛІВ (Фільтри ціни та об'єму):
- Фільтр глобального тренду (EMA 200): Робот ніколи не торгує проти ринку.
Угоди BUY дозволені лише тоді, коли ціна вища за EMA 200 (купівля на відкатах).
Угоди SELL — лише коли ціна нижча за EMA 200 (продаж на корекціях).
- Фільтр ринкової сили (ADX 14): Захищає від "флету" (боковика). Якщо ADX < 20,
це означає, що на ринку немає чіткого руху і панує хаос. Бот повністю
ігнорує будь-які сигнали осцилятора RSI до появи сильного імпульсу.
- Фільтр реальних грошей (Volume Surge): Поточний тиковий об'єм порівнюється
із середнім значенням за останні 20 годин (Vol_SMA_20). Угода відкриється
ТІЛЬКИ якщо імпульс ціни підтверджений вливанням об'ємів великих гравців,
що нівелює пастку "хибних пробоїв" (Fakeouts).
2. СТРУКТУРНИЙ ЗАХИСТ ВІД БРОКЕРСЬКИХ ПАСТОК (Фільтри механіки ринку):
- Динамічний спред-фільтр (Max Spread Cap): Перед відправкою ордера бот
перевіряє поточну різницю між Ask та Bid. Якщо спред штучно розширено
(під час новин або нічного клірингу) понад нормативні 30 піпсів, сигнал
блокується, запобігаючи миттєвому збитку при вході.
- Специфічні часові зони (Asset-Specific Time Filter): Робот адаптований під
пульс світових сесій. Індекси США аналізуються лише під час Волл-стріт
(16:00-23:00), Forex та метали — в активні періоди Лондона та Нью-Йорка
(10:00-23:00), а крипта (BTCUSD) моніториться цілодобово 24/7. Нічний хаос
та періоди нульової ліквідності відсікаються автоматично.
3. АВТОМАТИЧНИЙ РИЗИК-МЕНЕДЖМЕНТ ТА СУПРОВІД (Управління позицією):
- Динамічний Stop-Loss / Take-Profit за ATR: Захисні рівні не є фіксованими.
Вони розраховуються на базі середнього застиглого діапазону волатильності
ринку за останні 14 годин. Ризик завжди пропорційний поточному стану активу.
- Інтелектуальний трал (Trailing Stop): Як тільки позиція виходить у чистий
плюс на задану дистанцію (200 пунктів), бот починає автоматично підтягувати
Stop-Loss слідом за ціною з мінімальним кроком у 50 пунктів. При розвороті
ринку прибуток фіксується системно, навіть якщо ціна не досягла Take-Profit.
- Сепарація ордерів (Magic Number): Кожна угода маркується унікальним ID
(777777). Це ізолює роботу бота від ручних операцій трейдера на рахунку або
інших паралельних алгоритмів.
-
Yurii Koshliak 4 JulyАле це не гарантує повністю що всі угоди будуть в плюс і не зробить вас мільйонером за день а стабільно робити угоди так захист на 70% ризиків на 100 бути не може бо таких ідеальних моментів просто не буває а якщо буває то раз на 10 років
-
Yurii Koshliak 4 JulyЯкщо цікаво пока веду тести сьгодні почалися вихідні тому пока тестується лише біткоїн з понеділка відкриються ринки буде тестування всього іншого тому пока чекаю що з цього вийде
Current freelance projects in the category Bot Development
Good day, I need help with creating the logic and implementing an idea. A chat-bot for tracking the status of document production for an educational center.
Telegram Bot
Hello. Below is a conditional technical specification for the bot for our synagogue. We need not just a Telegram bot, but a convenient mini-application for the synagogue and community, through which a person can navigate the life of the synagogue, quickly get the necessary information, view the schedule, learn about events, register, and interact with us. In terms of style and logic, we can base it on the reference bot we showed, but we need a better version: more convenient, modern, useful, and with a clearer structure. If you have strong opinions on design, UX, and structure, and you see how to improve it, we are open to suggestions. The main idea: for a person to quickly navigate the life of the synagogue through the bot. What should be in the bot. 1. Main screen with specific buttons The main screen should have clear large buttons: Today Schedule Events Shabbat Jewish calendar My dates A-Yom Yom for today Synagogue services Contacts Donate Settings 2. "Today" section This is one of the main sections. A person enters and immediately sees what is happening today. What should be displayed: what is today's Jewish date what prayers are today what time they take place what events we have in the synagogue today important dates and events in the Jewish world if relevant — time for lighting candles and the end of Shabbat Buttons inside: Prayers today Events today Jewish date Shabbat / candles More details 3. "Schedule" section Through it, a person should conveniently view the schedule. Buttons: For today For tomorrow For the week For Shabbat For holidays What inside: Shacharit Mincha Maariv lessons meals holiday services other activities with time and, if necessary, location It is important that the administration can easily update this schedule. 4. "Events" section A full section on events is needed. What should be included: upcoming events all events card for each event registration In the event card: title date time location short description register button more details button Examples of events: Shabbat lesson youth meeting lecture charity lunch women's / men's meeting holiday outing 5. "Shabbat" section This should be a separate section, not just part of the schedule. What inside: time for lighting candles time for prayers time for meals time for the end of Shabbat weekly Torah portion brief information about the upcoming Shabbat registration for Shabbat Buttons: Upcoming Shabbat Shabbat schedule Weekly portion Register for Shabbat What you need to know 6. "Jewish calendar" section What should be included: today's Jewish date upcoming holidays Rosh Chodesh fasts memorial dates brief explanation of the day / holiday Buttons: Today Upcoming dates Holidays Rosh Chodesh Memorial dates 7. "My dates" section We take this idea from the reference, but want to make it useful. The user should be able to save: birthday Jewish birthday yahrzeit other important dates What the bot should do: store these dates remind about them allow setting notifications Buttons: Add date My dates Reminders Delete date 8. "A-Yom Yom for today" section What should be included: text for today convenient beautiful display ability to view the previous / next day share button Buttons: Today Yesterday Tomorrow Share 9. "Synagogue services" section This needs practical navigation. What can be included: registration for a lesson registration for Shabbat registration for an event ask a question volunteering charity programs other services / directions of the synagogue 10. "Contacts" section Should include: address phone Telegram Instagram YouTube email ways to contact us if necessary, geolocation Buttons: Call Write Open address Instagram Telegram YouTube 11. "Donate" section It needs to be done neatly and clearly. What should be included: donate button payment methods details / link brief explanation of what the funds are for contact for donation questions 12. "Settings" section The user should be able to configure: language daily notifications notification time Shabbat reminders holiday reminders reminders for personal dates Buttons: Language Notifications Shabbat Holidays My dates Enable / disable mailing 13. Daily mailing We need the bot to send people relevant information every day: what prayers are today what time they take place what events we have in the synagogue today what important dates and events are in the Jewish world today if relevant — time for candles / end of Shabbat That is, a person opens the bot in the morning or receives a message and immediately understands the picture of the day. 14. Registrations and sign-ups Through the bot, there should be an option to register for: Shabbat lessons events meetings other activities Logic: a person presses a button leaves their name phone / username if necessary, additional data the application goes to the administrator / to a table / to CRM 15. Admin section It is important for us that the bot is easy to manage. The admin should be able to: update the prayer schedule add and edit events change texts launch mailings see registrations and applications change contacts and links It is important that this is really convenient for maintenance, not too complicated. 16. Support and development At the first stage, it is not necessary to do everything at once; a strong first version can be launched, and then supplemented in the process. But it is important to immediately foresee: the possibility of expansion support and maintenance of the bot after launch bug fixes improvements during use 17. What is important in the end We need a bot that will become a mini-application for our synagogue and help a person navigate conveniently: what is today what prayers what events what will happen on Shabbat how to register how to contact where to view the Jewish schedule what is happening in our synagogue and in the Jewish world If you see how to make the structure, buttons, design, and logic better than in the reference bot, that is a plus. We need not a clone, but a stronger, more convenient, and modern version. https://www.hebcal.com/home/developer-apis Chabad.org
Development of a Telegram bot: a closed platform-marketplace for experts I am looking for a developer (or a small team) to create a Telegram bot — a closed platform that connects verified experts and clients for solving professional tasks. The model is similar to a service marketplace with a supervising administrator, rather than a fully automated service. What is ready: A detailed technical specification (30+ pages) — user roles, step-by-step UX flows with button texts, status models for Requests/Cases, data model, payment status model, admin panel. Key functionality: - Two user roles (client / expert) with the possibility of combination - Verification of experts through the administrator (without automatic decision approval) - Selection and moderation of requests by the curator - Internal communication space within the bot (without disclosing contacts between parties) - Payment status model: escrow, confirmation of funds receipt, payments - Referral system with bonuses - Administrative panel with extended access rights Expected stack: at the discretion of the developer (Python/Node.js), the main thing is — experience with Telegram Bot API, working with states (FSM), databases, and payment integrations. Collaboration format: work based on the ready technical specification, discussion of deadlines and budget after reviewing the document. What to send: examples of implemented Telegram bots (preferably — with complex state logic or payments), an estimated timeline and cost.
Technical assignment for the client search automation system in Telegram Development 1. General task It is required to create an MVP system for automatic client search in Telegram chats with the provision of found users to sales department operators. The system should consist of: user bots based on Telethon; Telegram bot for operators; Telegram bot (or a separate administrative section within the bot) for the administrator; PostgreSQL database; Docker configuration for deployment in configuration. A web panel is not required at this stage. 2. Working with multiple Telegram accounts The system must not be limited to one Telegram account. It is necessary to ensure support for multiple accounts (for example, 5 or more) with the ability to increase their number without changing the configuration. For each account, there should be the ability to: authorize via Telethon; maintain its own session; connect a new account; disconnect an account; replace an account without losing the database. The administrator should be able to independently connect new Telegram accounts. 3. Distribution of chats among accounts The system will use a large number of Telegram chats (approximately 800 or more). All chats are included in a single system. The system should automatically: manage chats among connected accounts; observe Telegram restrictions; Handle the need to transfer a chat to another account; Prevent duplication of one chat by multiple accounts (unless specifically included). It is desirable to ensure load balancing among accounts. 4. Managing the chat list The administrator should be able to do this without the developer's involvement: connect a chat; delete a chat; import a list of chats from a file; bulk upload chat costs; enable or disable monitoring of individual chats; restart history collection for a selected chat. After adding a new chat, the system automatically includes it in one of the key accounts. 5. Data collection For each connected account, it is necessary to implement: Initial parsing After adding a chat: loading message history for the specified period; saving all available information. Monitoring After the initial loading is completed: constant tracking of new messages; saving new users; saving new activity of existing users. 6. Handling Telegram blocking requires proper handling: FloodWait; PeerFlood; temporary Telegram restrictions; erroneous connections; connection breaks; possible reconnections; temporary unavailability of the account. If one account is temporarily blocked by a restriction, the rest of the work continues. 7. User data storage. For each user, the following should be saved: Telegram ID; first name; last name (if available); username; profile link; list of all chats; message text; date and time of the message; link to the message (if obtainable from Telegram). User merging is performed exclusively by Telegram ID. If a user has written in 20 chats — they display one card. 8. User card The operator should see: first name; username; Telegram ID; profile link; list of all chats; messages; activity date. Example: User: Ivan Ivanov ID user : 123456789 Chat "Business": Message: "Good day, interested in advertising" Date: 01.03.2026 12:15 Chat "Marketing": Message: "Who is handling promotion?" Date: 05.03.2026 18:42 9. Operator work The system should automatically form a queue of clients. After receiving a client: the user is assigned to an operator; the second operator cannot receive the same client; maintain a history of actions. Statuses: Took the client; Unavailable; Could not reach; Refusal; In progress; Call back; Delete. After selecting a parameter, the next client will automatically open. 10. Reissuing users There should be an option to configure user reissuance. For example: never; after 30 days; after 60 days; after 90 days; arbitrary period. 11. Administrative section The administrator should be able to: Account management add an account; delete an account; view account status; view account restrictions; replace an account. Chat management add; delete; import; export; disable monitoring; disable monitoring. Operator management add; delete; block; change rights. Parser management start collection; stop collection; rebuild history; view current status. Statistics View: number of users; number of messages; number of processed clients; number of active operators; number of connected accounts; number of active chats. 12. Database Use PostgreSQL. It is necessary to store: users; messages; chats; activity; Telegram accounts; operators; processing statuses; processing history; distribution of chats among accounts. 13. Scalability The architecture should provide the ability to: connect 10, 20 or more Telegram accounts; connect thousands of Telegram chats; handle load; export data; work with CRM; connect new features without a complete project overhaul. 14. Docker The executor should set up: docker-compose.yml; Dockerfile; launch instructions; update instructions; database backup instructions. The system should manage the command as one.