XTRD FIX API를 사용하여 Huobi에서 거래하는 방법

Huobi Global은 2013 년에 설립 된 싱가포르 기반 암호 화폐 거래소입니다. 일일 거래량이 약 20 억 달러에 달하는 Huobi Global은 BTC, ETH, LTC, XRP 등을 포함한 여러 암호 화폐 거래 쌍을위한 매우 유동적 인 거래소입니다. 2020 년 1 월 현재 약 400 개의 검증 된 시장과 약 25 개의 검증되지 않은 시장이 있습니다. Huobi Global은 다른 거래소와 달리 해킹 된 적이 없으며 전 세계에 수백만 명의 고객이 있습니다.

이 기사에서는 후 오비에 연결되는 XTRD FIX API를 기반으로 비교적 간단하지만 완전한 기능을 갖춘 거래 애플리케이션을 구축하는 방법을 보여 드리고자 합니다. 자신의 프로젝트에서 소스 코드로 자유롭게 재사용 할 수 있습니다.

이 응용 프로그램은 XTRD FIX 게이트웨이에 두 개의 나가는 FIX 연결을 설정하는 방법을 보여줍니다. 세션 중 하나는 단일 쌍 ( ETH / USDT )에 대한 정규화 된 실시간 시장 데이터를 수신하는 데 사용됩니다. 두 번째 세션에서는 미결제 주문 및 포지션과 같은 특정 계정의 재무 정보와 함께 거래 기능에 대한 액세스를 제공합니다.

따라서 첫 번째 단계로 시장 데이터 세션에 연결하고 ETH / USDT 업데이트를 구독 할 것입니다.

동시에 애플리케이션은 거래 세션에 대한 연결을 설정하고 전체주기 복구 작업을 수행합니다. 미결 주문 목록과 사용 가능한 잔액을 가져옵니다.

핸드 셰이크 단계를 마치면 애플리케이션에서 ETH를 구매하기 위해 제한 주문을 보내기 시작합니다. 주문 가격은 주문이 책에 남아 있고 실행되지 않도록하기 위해 항상 시장 밖에서 20 %입니다. 주문이 몇 초 동안 책에 남아 있도록 허용 한 다음 취소합니다. 그런 다음주기가 다시 시작됩니다. 먹다. 자다. 반복합니다.

Huobi는 고급적이고 풍부한 API를 제공합니다. 그러나 크고 복잡한 모든 것과 마찬가지로 자체 단점이 있습니다. 예를 들어 WebSocket을 사용하여 주문을 보낼 수 없으며 REST API를 사용해야합니다. 그래서 무엇이 문제입니까? 많은 디지털 자산 거래소에서 동일한 작업을 수행합니다.

문제는 WebSocket에서 제공되는 확인에 클라이언트의 할당 된 ID가없고 Huobi에서 생성 한 주문 ID 만 있다는 것입니다. 그러나이 외부 주문 ID는 REST API 요청에 대한 응답을 수신하고 파싱 한 후에 만 ​​알 수 있습니다. 때때로 WebSocket의 메시지는 주문 ID를받는 것보다 더 빨리 전달되어이 보고서가 무엇인지 짐작할 수 있습니다.

XTRD Orders 라우터는이 문제를 성공적으로 해결하여 고객이 적절한 방식으로 간소화 된 ExecutionReport 주문을 즐길 수 있도록합니다.

이 애플리케이션이 그렇게 간단하지 않다는 점을 고려하여 Google 팀에서 개발 한 여러 지원 클래스를 사용합니다. 최적화가 부족하기 때문에 부하가 높은 애플리케이션에서는 이러한 클래스를 사용하지 않는 것이 좋지만이 과정의 목적에는 충분합니다.

간단한 거래 애플리케이션을 구축하기 위해 Java 및 OnixS FIX Engine을 사용합니다. 물론 항상 Java를 C ++, Python 또는 JavaScript로, OnixS를 QuickFIX 또는 Fix8로 대체 할 수 있습니다. 이것이 FIX API의 장점입니다. 언어와 엔진에 구애받지 않습니다. 예, 장점 때문에 OnixS 라이브러리를 사용하는 것을 선호하지만 이는 내부 팀 결정일뿐입니다.

다른 언어 / FIX 라이브러리로 이식하는 데 도움이 필요하면 언제든지 문의 해주세요. 기꺼이 도와 드리겠습니다.

우리가 빌드 할 애플리케이션은 이전 조건에 따라 한 단계에서 다른 단계로 이동하는 상태 머신입니다. 다음은 가능한 (가독성을 높이기 위해 단순화 된) 상태의 다이어그램입니다.

보시다시피 애플리케이션은 MD_READY와 ORD_READY의 조합 인 APP_ENTER_MARKET 단계에있는 경우에만 주문을 보내기 시작합니다. 예상치 못한 일이 발생한 경우, 예 : 세션 중 하나가 연결이 끊어지면 모든 거래 활동이 중지됩니다.

가장 쉬운 부분부터 시작하겠습니다. 시장 데이터 세션에 연결하고 ETH / USDT에 대한 업데이트를 구독하는 것입니다.

XTRD MD Feeder는 사용자 이름 및 비밀번호 필드가 포함 된 로그온이라는 특수 메시지를 보내 핸드 셰이크를 시작할 것으로 예상합니다.

합리적인 질문을 할 수 있습니다. 암호화되지 않은 자격 증명을 보내는 것이 안전한가요? XTRD 클라이언트는 다음 옵션 중 하나를 사용하여 서버에 연결됩니다.

따라서 귀하와 Google 간의 모든 트래픽은 다른 사람과 완전히 격리됩니다. 그리고 우리는 이미 귀하의 암호를 알고 있기 때문에 우리에게 숨길 의미가 없습니다 🙂

승인에 성공하면 서버가 로그온 메시지로 응답하여 시장 데이터 스트림을 구독하기위한 메시지를 보내는 단계로 이동합니다.

FIX에서는 MarketDataRequest 를 사용하여 수신하려는 상품 및 교환에 대한 업데이트를 나타냅니다.

진정한 정규화 레이어 역할을하기 위해 우리는 고유 한 기호를 유지하기로 결정했습니다. 따라서 ethusdt (Huobi에서), usdteth (Bittrex에서) 또는 4 (BlockTrade에서)를 거래하는 대신 귀하가 가진 유일한 이름 사용하는 것은 ETH / USDT입니다.

다음은 MarketDataRequest 구조의 샘플과 해당 메시지를 생성하는 Java 코드의 일부입니다.

서버에 수신되면 MarketDataRequest 메시지가 일련의 이벤트를 트리거합니다.

Google의 장부 관리 규칙은 NEW (0), UPDATE (1) 및 DELETE (2) 이벤트의 조합 인 전통적인 금융에서 널리 사용되는 원칙을 기반으로합니다. 이것은 안정적이고 예측 가능한 소프트웨어를 쉽게 구축하는 데 도움이되는 매우 간단한 접근 방식입니다.

이 개념을 설명하기 위해 우리는 매우 간단한 책을 만들고 저장소에 공유했습니다. 이 코드는 상당한 성능 저하가 있으므로 프로덕션 환경에서는 사용하지 않는 것이 좋습니다. 하지만이 기사의 목적에는 여전히 충분합니다.

따라서 모든 시장 데이터 이벤트를 간단한 책에 “공급”합니다. 이렇게하면 시장에서 어떤 일이 벌어지고 있는지에 대한 정확한 그림을 얻을 수 있습니다 (하나의 특정 도구 사용).

완벽합니다. 데이터가 있습니다! 그러나 우리는 그것으로 무엇을 할 것입니까? 거래 커넥터 구축에 대해 자세히 알아 보겠습니다!

이 부분은 포지션과 주문 동기화가 필요하기 때문에 시장 데이터에 비해 훨씬 더 복잡합니다. 이 기사를 적절한 크기로 유지하기 위해 실제 동기화 및 복구 기술을 생략하고 메시지를 보내는 방법 만 보여 드리겠습니다. 어쨌든 각 거래 애플리케이션에는 자체 백엔드와 자체 규칙이 있습니다…

첫 번째 단계는 시장 데이터 세션 인 로그온 과 완전히 동일합니다. 승인을 통과하면 관리중인 자산 목록을 요청할 때입니다. FIX에는 이에 대한 특별한 메시지 인 RequestForPositions 가 있습니다. 사용 상황에 따라 서버는 현재 포지션 스냅 샷을 반환하고 / 또는 거래, 인출 또는 입금의 경우 포지션 크기가 변경되면 실시간으로 계속 알려줍니다.

워크 플로는 다음과 같습니다. 귀하가 RequestForPositions 메시지를 보냈고 서버는 다음에 무엇을 예상해야하는지 나타내는 하나의 RequestForPositionAck 메시지를 보내드립니다. 위치가있는 경우 정보는 PositionReport 메시지 형식으로 도착합니다.

마지막 PositionReport 메시지에는 다른 단계 (주문 동기화)로 전환하는 데 사용할 특수 마커가 있습니다.

때때로 거래 세션에서 책 어딘가에 실시간 작업 주문이있을 수 있습니다. XTRD FIX API에는 이러한 작동중인 말을 호출하는 특수 메시지 인 OrderMassStatusRequest 가 있습니다. FIX 세계에서 주문에 대한 대부분의 정보는 ExecutionReport 메시지를 사용하여 전송됩니다. 이 메시지에는 FIX 언어의 다른 메시지와 비교하여 가장 많은 필드가 포함되어 있습니다. 하지만 주문과 각 상태를 정확하게 식별하는 데 도움이됩니다.

XTRD가 DMA 제공 업체의 역할을하는 한 모든 작업이 100 % 투명하게 이루어 지길 원합니다. 따라서 클라이언트의 할당 된 ID (ClOrdID (Tag 11) 필드에서 전송 됨) 및 XTRD 할당 ID (OrderID (Tag 37), 항상 정수 번호)와 함께 교환 할당 된 ID (SecondaryOrderID (Tag 198) 필드에서)가 표시됩니다.

주문 동기화 전략은 다음과 같이 작동합니다. OderMassStatusRequest 를 보내고 서버 응답을 기다립니다. 두 가지 가능한 시나리오가 있습니다 (유효한 초기 메시지의 경우) :

이 시점에서 우리의 위치와 명령이 동기화되어 있으므로 재미있는 촬영 명령을합시다!

애플리케이션은 장부 가격의 상단을 선택한 다음 최적의 입찰가 또는 제안에서 X 핍 떨어진 가격으로 지정가 주문을 보냅니다 (선택한 측면에 따라 다름). 우리의 목표는 algo가 취소하기 전에 일정 시간 동안 책에 남아있는 주문을 만드는 것입니다.

주문하기 위해 NewOrderSingle 이라는 메시지를 사용합니다. 필드는 매우 간단하고 자명합니다. Side (Tag 54) (구매 또는 판매), Type (Tag 40) (이 경우 제한)을 지정하고 제한 가격 및 주문 크기를 제공하고 Symbol (Tag 55) 및 라우팅 대상 (태그 11) (이 경우 HUOBI). NewOrderSingle 메시지에 대한 전체 필드 설명은 여기에서 찾을 수 있습니다.

주문이 발송되면 서버는 수명주기 변경을 나타내는 특정 수의 ExecutionReport로 응답합니다. XTRD 플랫폼은 다음과 같은 상태를 사용하여 주문과 관련된 사항을 나타냅니다.

물론 우리 모두는 완벽한 PENDING_NEW / NEW-& gt; FILLED 사이클과 엔지니어들은 가장 빠른 기술을 제공하기 위해 최선을 다하고 있습니다. 또한 Huobi Global과 같은 LP 파트너에 의존합니다.

완벽합니다. 주문이 책에 포함되어 있으므로 주문이 실행되기 전에 서둘러 취소하겠습니다.

주문을 취소하려면 OrderCancelRequest 메시지를 보내야합니다. 다음은 까다로운 부분입니다. 3 개의 ID를 제공해야합니다.

인간 언어로 번역 된이 레코드는 다음과 같이 읽어야합니다. “주문 ClOrdID 를 사용하여 이전에 주문한 OrigClOrdID / OrderID 를 취소합니다. ”

주문을 취소하면 서버는 거래 / 작업 주문이 취소되었음을 확인하는 해당 ExecutionReport로 알려드립니다.

데모 애플리케이션의 워크 플로에 따라 algo는 2 초 동안 휴면 한 다음 다른 제한 주문을 보냅니다. 다시. 그리고 다시.

보시다시피 XTRD FIX API를 사용하여 Huobi 용 간단한 거래 애플리케이션을 구축하는 것은 비교적 쉽습니다. 제대로 설계되면 수면이나 휴식을 위해 멈추지 않고 시계 방향으로 작동합니다. 물론 시장 진입 및 진출을 위해 일부 로직을 통합해야하지만 활용할 수있는 신호 제공자, 사례 연구, 기술 분석 라이브러리 및 AI 플랫폼도 많이 있습니다.

실제 애플리케이션의 “두뇌”로 무엇을 사용하든 Huobi와 같은 암호 화폐 거래소에서 거래하기위한 XTRD FIX API는 신뢰할 수 있고 신뢰할 수있는 파트너가 될 것입니다!