Quatro defeitos distintos do Kraken entraram na versão 2026.9, e nenhum deles é do tipo que se detecta lendo o código uma única vez. Cada um só aparece sob uma condição específica: o endpoint errado no momento da conexão, um corpo de requisição que nunca sai da máquina, uma reconexão que acontece algumas centenas de milissegundos cedo demais. Os quatro estão corrigidos, e vale a pena entender todos eles, porque em cada caso o modo de falha parece ser outra coisa completamente diferente.
O cliente spot falava v1 com um endpoint v2
TsgcWSAPI_Kraken constrói e interpreta o schema v1: event, pair, subscription, subscriptionStatus, systemStatus. Esse schema existe por um motivo: é contra ele que toda chamada de subscribe e todo event handler deste componente são escritos. O endpoint ao qual ele se conectava, porém, apontava por padrão para o WebSocket v2 do Kraken, que fala um schema completamente diferente: method, params, channel, type. A conexão era aberta sem erro. Só que nunca produzia uma única confirmação de assinatura ou evento de status, porque o servidor respondia em um formato que o cliente nunca interpreta.
Kraken.Version agora tem como padrão 1, e o componente escolhe o endpoint v1 correspondente:
uses
sgcWebSocket, sgcWebSocket_APIs;
var
oKraken: TsgcWSAPI_Kraken;
begin
oKraken := TsgcWSAPI_Kraken.Create(nil);
oKraken.Client := oClient;
// Version defaults to 1, matching the event/pair/subscription
// schema this component already builds and parses.
oKraken.Kraken.Version := 1;
oClient.Active := True;
oKraken.SubscribeTicker('XBT/USD');
end;Se, de alguma forma, sua aplicação dependia do antigo padrão, silenciosamente errado, isso significa que ela também nunca chegou a receber eventos v1, portanto não há nada funcionando hoje que precise ser preservado. Definir Kraken.Version := 2 explicitamente ainda conecta ao endpoint v2, com RawMessages habilitado e o payload tratado em OnKrakenData ou OnMessage, para quem constrói deliberadamente contra esse schema.
Ordens Futures enviadas como GET, corpo descartado
Este é mais silencioso e mais sério. Toda requisição privada no cliente Kraken Futures REST, enviar uma ordem, editá-la, cancelá-la, uma transferência, um saque, saía como um HTTP GET. O corpo da requisição assinada era construído corretamente, calculado, formatado, pronto para envio, e então descartado, porque uma requisição GET não tem corpo onde colocá-lo. O Kraken recebia um GET sem parâmetros e o rejeitava ou ignorava. Nenhuma dessas chamadas funcionava.
uses
sgcHTTP_API_Kraken;
var
oKraken: TsgcHTTP_API_Kraken_Futures_Rest;
oOrder: TsgcHTTPKrakenFuturesOrder;
begin
oKraken := TsgcHTTP_API_Kraken_Futures_Rest.Create(nil);
oKraken.KrakenOptions.ApiKey := 'your_api_key';
oKraken.KrakenOptions.ApiSecret := 'your_api_secret';
oOrder := TsgcHTTPKrakenFuturesOrder.Create;
try
oOrder.OrderType := kotfLMT;
oOrder.Symbol := 'PF_XBTUSD';
oOrder.Side := kosfBuy;
oOrder.Size := 1;
oOrder.LimitPrice := 30000;
// SendOrder now posts through DoHTTP_POST_PRIVATE, body included.
ShowMessage(oKraken.SendOrder(oOrder));
finally
oOrder.Free;
end;
end;SendOrder, EditOrderByOrderId, EditOrderByCliOrderId, CancelOrderByOrderId, CancelOrderByCliOrderId, Transfer e WithdrawalToSpotWallet agora passam todos pelo caminho POST privado, com o corpo assinado efetivamente anexado à requisição.
Assinaturas privadas perdidas na reconexão
O WatchDog reconecta, o log mostra uma reconexão limpa, e a partir desse ponto os canais orders, balance e fills simplesmente desaparecem. Nada gera erro. Nada é registrado no log. A reconexão parecia totalmente bem-sucedida, porque a conexão em si realmente teve sucesso, apenas as assinaturas privadas emitidas antes da desconexão nunca eram reenviadas depois. Isso afetava tanto o Kraken spot quanto o Kraken Futures, junto com vários outros clientes de exchanges corrigidos na mesma leva. Agora isso faz parte do replay padrão de resubscribe, o mesmo caminho que já restaura suas assinaturas de dados públicos de mercado após uma reconexão.
Futures refazendo as assinaturas antes de a sessão estar autenticada
Um defeito intimamente relacionado, específico do Kraken Futures: após uma reconexão, o replay das assinaturas ativas podia rodar antes que o handshake de autenticação tivesse realmente terminado. As requisições de subscribe saíam em uma sessão que o Kraken ainda não havia autenticado, então as privadas eram rejeitadas, mais uma vez sem nada no cliente indicando o motivo. O replay agora espera a autenticação terminar antes de refazer as assinaturas.
Atualizando
As quatro correções são diretas (drop-in), não há API para migrar. A única mudança de comportamento a observar é a troca do valor padrão de Kraken.Version, do valor anterior, efetivamente não funcional, para 1; se seu código já define Version := 2 explicitamente, nada muda para você.
Dúvidas, feedback ou ajuda com a migração? Entre em contato — você receberá uma resposta de quem escreveu o código.