Atualização das bibliotecas de desenvolvimento do XMR｜Melhoria na confiabilidade da carteira, mas não é uma atualização de protocolo｜Por volta de US$ 554; primeiro, confirmar
Minha postura é observar com cautela, sem correr para comprar só porque saiu um conjunto de números de versão. Em 24 de setembro, o desenvolvedor woodser publicou no GitHub o monero-cpp v0.9.5, monero-java v0.8.57 e monero-ts v0.11.16. As três notas de lançamento podem ser verificadas; elas se aplicam a bibliotecas de integração de carteiras voltadas para desenvolvedores, não são uma hard fork da rede Monero e, portanto, não dá para afirmar com isso que o protocolo de privacidade tenha mudado.
O que vale a pena observar aqui são os detalhes, não os slogans. No C++, correções para: fechar corretamente quando a carteira está ocupada; exibir incorretamente o valor ao transferir quando o histórico está incompleto; remover sobras de atualizações antigas após alternar de carteira; e falhas em enviar alertas de saldo disponível. Java e TypeScript absorvem correções relacionadas em sincronia. Para aplicativos que integram recebimento e pagamento em XMR, reduzir saldos com erro, defasagem de estado e encerramentos anormais ajuda a diminuir o atrito operacional. Mas, do código publicado até a conclusão da integração no aplicativo, testes, lançamento e depois uso por usuários reais, ainda há um caminho a percorrer. O que melhora é a credibilidade da infraestrutura, não gera, diretamente, uma demanda spot de compra.
A reação do mercado também não trouxe evidências de “realização de vantagem positiva”. Quando consultei o Kraken XMR/USD, a negociação mais recente estava por volta de US$ 554,70; o pregão das últimas 24 horas começou em US$ 565,78; a máxima foi US$ 575,00 e a mínima US$ 545,52. Em relação ao preço de abertura, ainda está fraco. A cotação de uma única plataforma é apenas uma janela de observação, não representa todo o mercado, e ainda menos dá para atribuir essa oscilação a essa atualização das bibliotecas. No momento, trato 545,5 como zona de defesa para observação e 575 como zona de validação acima; não vou forçar uma direção no meio do intervalo.
Se fosse eu negociando, não participaria agora. A direção fica neutra, com plano de posição em 0%. Só consideraria usar no máximo 2% do capital total para testar um long spot se o preço voltasse a sustentar acima de US$ 575, com reteste sem rompimento e melhora simultânea da atividade de negociação. Primeiro objetivo: 590. Ao se aproximar da meta, reduziria pela metade; a posição restante observaria 605. Se, após entrar, cair de volta abaixo de 565, ou se houver falha na integração da carteira e a liquidez da exchange piorar claramente, eu stoparia e encerraria a operação, sem recomprar para baixar custo. Se primeiro romper e cair abaixo de 545,5, a ideia original de long é descartada; continuo zerado, sem usar a “atualização técnica” como justificativa para pegar a queda.
Fonte: páginas de lançamento no GitHub dos três projetos do woodser; quadro público do XMR/USD no Kraken. #XMR
O acima é apenas minha observação pessoal do mercado e não constitui recomendação de investimento.
Minha postura é observar com cautela, sem correr para comprar só porque saiu um conjunto de números de versão. Em 24 de setembro, o desenvolvedor woodser publicou no GitHub o monero-cpp v0.9.5, monero-java v0.8.57 e monero-ts v0.11.16. As três notas de lançamento podem ser verificadas; elas se aplicam a bibliotecas de integração de carteiras voltadas para desenvolvedores, não são uma hard fork da rede Monero e, portanto, não dá para afirmar com isso que o protocolo de privacidade tenha mudado.
O que vale a pena observar aqui são os detalhes, não os slogans. No C++, correções para: fechar corretamente quando a carteira está ocupada; exibir incorretamente o valor ao transferir quando o histórico está incompleto; remover sobras de atualizações antigas após alternar de carteira; e falhas em enviar alertas de saldo disponível. Java e TypeScript absorvem correções relacionadas em sincronia. Para aplicativos que integram recebimento e pagamento em XMR, reduzir saldos com erro, defasagem de estado e encerramentos anormais ajuda a diminuir o atrito operacional. Mas, do código publicado até a conclusão da integração no aplicativo, testes, lançamento e depois uso por usuários reais, ainda há um caminho a percorrer. O que melhora é a credibilidade da infraestrutura, não gera, diretamente, uma demanda spot de compra.
A reação do mercado também não trouxe evidências de “realização de vantagem positiva”. Quando consultei o Kraken XMR/USD, a negociação mais recente estava por volta de US$ 554,70; o pregão das últimas 24 horas começou em US$ 565,78; a máxima foi US$ 575,00 e a mínima US$ 545,52. Em relação ao preço de abertura, ainda está fraco. A cotação de uma única plataforma é apenas uma janela de observação, não representa todo o mercado, e ainda menos dá para atribuir essa oscilação a essa atualização das bibliotecas. No momento, trato 545,5 como zona de defesa para observação e 575 como zona de validação acima; não vou forçar uma direção no meio do intervalo.
Se fosse eu negociando, não participaria agora. A direção fica neutra, com plano de posição em 0%. Só consideraria usar no máximo 2% do capital total para testar um long spot se o preço voltasse a sustentar acima de US$ 575, com reteste sem rompimento e melhora simultânea da atividade de negociação. Primeiro objetivo: 590. Ao se aproximar da meta, reduziria pela metade; a posição restante observaria 605. Se, após entrar, cair de volta abaixo de 565, ou se houver falha na integração da carteira e a liquidez da exchange piorar claramente, eu stoparia e encerraria a operação, sem recomprar para baixar custo. Se primeiro romper e cair abaixo de 545,5, a ideia original de long é descartada; continuo zerado, sem usar a “atualização técnica” como justificativa para pegar a queda.
Fonte: páginas de lançamento no GitHub dos três projetos do woodser; quadro público do XMR/USD no Kraken. #XMR
O acima é apenas minha observação pessoal do mercado e não constitui recomendação de investimento.
