Загрузка…
A trade opens from Telegram or by preset rules, and the team sees position state and the P2P market in one place
Browser tabs to a chat
Where the team works with trades
How we measured: before the project, orders were placed in the exchange's own interface, and P2P listings and positions were watched in separate tabs; afterward, a trade is opened and its state is read from Telegram
The team worked by hand through the exchange's interface. That means: see the situation, switch to a tab, place an order, check that it went through. Each step takes seconds, and on a quiet market that's insignificant. The problem is that exactly when action needs to happen fastest, those seconds cost the most.
Alongside that ran P2P monitoring. Listings, rates, price differences, all of it watched by eye, in separate tabs, refreshed by hand. A person watching a market cannot watch it continuously: they get distracted, they sleep, they're busy with another trade.
Exactly when action needs to happen fastest, switching between browser tabs is what costs the most.
The team's own open positions were tracked the same way. What's open right now, in what state, what changed since morning: the answer was assembled by switching between screens, and different people on the team could get different answers, because they looked at different times.
A separate difficulty: the team is small, up to ten people, and it has no dedicated person, nor should it, whose whole day is spent staring at charts instead of working.
A system that sits between the team and the exchange. On one side is Telegram, where people work; on the other is the Bybit API, where trades get executed.
A trade can be opened two ways. First: a person gives a command from the chat, and the system places the order on the exchange. Second: the system does it on its own once conditions set by the team are met. The second path isn't there to replace a person, it's there for moments when no one is around: the rules keep working at night and on weekends.
The rules keep working at night and on weekends: the automatic mode isn't there to replace a person, it's there for moments when no one is around.
Monitoring covers the other half of the task. The system watches the P2P market and the team's own open positions and reports changes to that same chat: what opened, what closed, what changed on the market. Watching the market no longer requires someone to actually be watching it.
One important detail of the design: both modes of opening a trade go through the same execution path. A manual command and an automatic rule both lead to the same code that talks to the exchange.
An exchange API is an external system, and it can be unavailable, respond with delay, or throttle the rate of requests. In an ordinary integration, that's an inconvenience handled by retrying a minute later. In trading, it isn't: an order resent after it had actually already gone through is a second trade instead of one.
So a retry here isn't built as 'just send it again.' Before retrying, the system checks how the previous attempt actually ended: did the order go through or not. The answer is taken from the exchange itself, not assumed from whether its response reached us. No response means we don't know the outcome, not that there was no outcome.
No response means we don't know the outcome, not that there was no outcome.
The system respects rate limits on its own, pacing its requests instead of hitting the limit and getting rejected at the exact moment it needs to act.
The system doesn't take position state on faith either. What it shows the team is checked against what the exchange itself reports: a mismatch between its own picture and reality is exactly the kind of error that costs the most.
Exchange API keys are access to the team's money, and how they'd be handled was decided before the first line of code. The keys are stored encrypted on the client's own server. The infrastructure belongs to the team, and we have no access to the keys, either during the work or after handover.
This isn't a formality or a contract clause for peace of mind. A contractor holding the keys to an exchange account is a risk that isn't closed by trust or reputation, it's closed by the contractor simply not having the keys.
A contractor holding the keys to an exchange account is a risk closed not by trust, but by the contractor simply not having the keys.
The second boundary is substantive. We built execution and monitoring: how an order reaches the exchange, what happens on failure, how state gets shown. The trading rules themselves, meaning what to buy, when to enter, when to exit, are set by the team. They change, and the client changes them, not us through a release.
This also determines what isn't in this case. We do not claim that trading became more profitable: that's a result of the team's strategy, not of the tool, and claiming credit for it would not be true.
Working with trades moved to where the team already is. Opening a position, checking its state, learning about a change, all of that happens in Telegram now, instead of switching between the exchange's tabs and the P2P section.
Monitoring stopped being anyone's personal duty. The system watches the market and the positions, and people get a message when something changes, instead of sitting in front of a chart so as not to miss it.
A team of ten now has one shared picture instead of several private ones: what's open and in what state is visible to everyone the same way, at the same moment.
And part of the workflow stopped depending on whether anyone is at a computer: the preset rules run at any hour.
The first conversation commits you to nothing: we will look at your situation and tell you whether you need a project like this at all.