[Uber testou retirar fundos da blockchain mesmo nos fins de semana; a Primus também apresentou uma proposta de desenvolvimento] @primus_labs @CantonNetwork Uber testou se é possível retirar fundos depositados em contas durante fins de semana, fora do horário comercial. Em um teste divulgado em 30 de outubro, a Uber comprou fundos do mercado monetário da Franklin Templeton usando depósitos tokenizados do HSBC e confirmou que conseguiu converter parte desses fundos em dinheiro mesmo durante o fim de semana. A blockchain utilizada nessa transação foi a Canton Network. Primus e HashCloak apresentaram uma proposta para integrar a tecnologia de verificação de dados zkTLS ao mesmo fundo de desenvolvimento da Canton. O valor solicitado é de 1.303.500 Canton Coins (CC), equivalente a aproximadamente 150 mil dólares na época da submissão. O prazo estimado para o desenvolvimento é de 14 semanas. O experimento da Uber focou no processo de investimento e resgate de fundos por empresas quando necessário. A proposta da Primus visa adicionar à aplicação Canton a capacidade de verificar condições financeiras externas necessárias para transações, sem expor os dados originais. Por exemplo, imagine que uma empresa precise confirmar se a outra parte possui fundos suficientes antes de realizar uma transação. Em vez de obter e armazenar todo o extrato bancário, o sistema validaria uma prova baseada em dados verificados por fontes autorizadas. A Primus planeja criar provas para dados da web, enquanto a HashCloak desenvolverá ferramentas para permitir que a aplicação Canton verifique essas provas diretamente. Na proposta pública, são listados como resultados exemplos de como a aplicação Canton pode verificar diretamente provas matemáticas sem receber os dados originais, além de ferramentas públicas reutilizáveis por outros desenvolvedores. Ao implementar isso, aplicações que verificam informações financeiras poderão validar as provas diretamente, sem depender apenas da assinatura da Primus. O experimento da Uber já foi concluído, enquanto a proposta da Primus e da HashCloak está atualmente em avaliação. Ambas abordam problemas distintos dentro do mesmo ecossistema Canton. O próximo passo será verificar se é possível integrar à infraestrutura de execução de transações a capacidade de validar com segurança informações financeiras externas. O que será verificado posteriormente não será o valor do financiamento, mas sim se a funcionalidade de verificação realmente funciona. Um critério decisivo para avaliar o progresso dessa ideia será a disponibilização de um teste público em que a aplicação Canton consiga verificar diretamente as provas da Primus sem receber as informações financeiras originais. #Primus #CantonNetwork

[Por que a chegada da avaliação da IA no Solana não significa que o pagamento já foi concluído] @GenLayer Suponha que o mercado de agentes de IA do Solana confie a avaliação da qualidade das tarefas à GenLayer. Mesmo que os verificadores cheguem a um consenso sobre os resultados, ainda é uma questão separada determinar em qual conta do Solana o reembolso será registrado. O código de ponte publicado pela GenLayer Foundation contém uma estrutura que transmite mensagens entre a GenLayer e o Solana por meio do LayerZero V2 e do hub EVM. Nesse contexto, o local onde a avaliação da IA é realizada e o local onde o estado do aplicativo é alterado com base nesse resultado são separados. A forma como o Solana recebe mensagens varia conforme a configuração da conta. Se a conta receptora for pré-definida, o estado registrado no caminho DirectCpiReceiver pode ser atualizado imediatamente. Chamadas reais a programas externos precisam ser implementadas adicionalmente, conforme exigido pelo programa receptor. Por outro lado, se a conta variar por pedido ou por usuário, a mensagem deve ser primeiro armazenada por meio de StoreAndClaim, e então, ao chamar claim_message, as contas necessárias são especificadas. O Solana exige que, antes de executar uma transação, seja especificada uma lista de contas a serem utilizadas. Portanto, apenas o fato de receber uma mensagem pela ponte não significa que o pagamento ao usuário já foi concluído. A origem da mensagem também é verificada separadamente da avaliação. A implementação pública foi projetada para validar pares confiáveis e evitar processamentos duplicados de solicitações idênticas por meio de um message_id exclusivo. No entanto, evitar duplicatas e garantir a entrega correta da mensagem não constituem evidência de que o conteúdo da avaliação da IA está correto. O que abordei ao criar o PolicyGuard no Studio foi a questão de determinar se as regras do documento realmente mudaram. Este código de ponte demonstra que, ao conectar os resultados a serviços em outras cadeias, é necessário projetar não apenas os critérios de avaliação, mas também a entrega, o recebimento e o estado de pagamento. Atualmente, o repositório público contém registros de testes bidirecionais entre Base Sepolia e Solana Devnet, mas esses não devem ser considerados como resultados operacionais válidos para serviços comerciais do Solana que utilizem avaliações da IA da GenLayer. A evidência de sucesso necessária em aplicativos de IA cross-chain divide-se em três elementos: a confirmação final da avaliação da GenLayer, a mensagem proveniente de uma fonte confiável e a alteração real do estado da conta de destino. Código público: https://t.co/N4zVSxjYG7 #GenLayer #GenLayerDOKDOPioneer

[ENSv2, um único nome para milhares de contas] @ensdomains @ethereum Com o lançamento do ENSv2 em 27 de outubro, é possível que https://t.co/NvxB4rnXZr.eth e https://t.co/xwZsp1UT6i.eth sejam gerenciados por diferentes responsáveis. Isso permite que uma empresa atribua apenas as permissões necessárias a cada equipe, sem precisar transferir a propriedade de company.eth. Essa estrutura traz consigo uma condição: um único domínio pequeno pode se tornar um ponto frágil para todo o serviço. Se o nome pai expirar, todos os nomes filhos abaixo dele deixam de ser consultáveis. O ENS é conhecido como um serviço que permite usar nomes legíveis, como alice.eth, em vez de longos endereços de carteira. O ENS divulgou em outubro que possui cerca de 905 mil nomes .eth e cerca de 34 milhões de nomes filhos. Esse total de mais de 36 milhões de nomes inclui tanto nomes registrados diretamente por indivíduos quanto nomes filhos emitidos por organizações. A estrutura de gerenciar múltiplas pessoas e serviços por meio de um único nome já está sendo amplamente utilizada. O ENSv2 reformulou a base para gerenciar esses nomes filhos. Cada nome pode ter seu próprio registro de nomes filhos, e o proprietário pode dividir permissões — como registro, edição de perfil e gerenciamento de nomes filhos — por papéis específicos. Por exemplo, uma organização pode emitir nomes individuais para cada funcionário ou atribuir permissões de edição por equipe responsável por serviços. Anteriormente, era possível criar nomes filhos, mas o ENSv2 integrou essas funções de gerenciamento diretamente na estrutura do contrato principal. Do outro lado, surge a concentração de responsabilidade. Ao consultar um nome, o ENSv2 percorre sequencialmente os registros pais. Se company.eth expirar ou a conexão com seu registro filho for interrompida, mesmo possuindo https://t.co/xwZsp1UT6i.eth, não será possível encontrar o endereço de pagamento associado a esse nome. A capacidade de gerenciamento da pessoa que recebeu o nome está diretamente ligada à renovação e ao controle de permissões do proprietário do nome pai. As regras de expiração também intensificam essa responsabilidade. O ENSv1 mantinha a consultabilidade do nome por 90 dias após a expiração. O ENSv2 reduziu esse período para 28 dias e interrompe imediatamente a consultabilidade ao expirar. Se renovado dentro desse período, o nome volta a funcionar; mas durante o tempo em que não for renovado, os serviços vinculados podem ser afetados. Ao migrar um nome existente para v2, a data de expiração é adiada em 62 dias para compensar essa diferença. Por exemplo, se um nome v1 tiver 100 dias restantes até a expiração, após a migração para v2 terá cerca de 162 dias restantes, e o momento em que outro poderá registrá-lo será em cerca de 190 dias em ambos os casos. Embora o momento em que o nome se torne disponível para regristro seja o mesmo, no v2 ele não será consultável nos últimos 28 dias. O risco de perda para outra pessoa e o risco de interrupção temporária dos serviços seguem cronogramas diferentes. Para um único apelido pessoal, isso pode ser apenas um problema de lembrete de renovação. Mas se uma organização emitiu milhares de nomes filhos para clientes, funcionários ou agentes, uma falha na renovação de um único nome pai pode causar problemas de acesso em múltiplos serviços. É por isso que, assim como o design detalhado dos papéis, a responsabilidade pela renovação do nome pai e os procedimentos de recuperação de emergência tornam-se cruciais. As mudanças nos preços de registro também estão alinhadas a esse design. O preço básico anual para nomes .eth com cinco ou mais caracteres subiu de US$ 5 para US$ 8 — um aumento de 60% — mas se registrado por seis anos ou mais, cai para cerca de US$ 4,50 por ano. Essa estrutura de preços incentiva a manutenção prolongada em vez da posse temporária. No entanto, quanto mais contas estiverem vinculadas a um nome, maior será o custo potencial de uma falha na renovação — muito acima do preço inicial de registro. O crescimento do ENSv2 não será explicado apenas pela quantidade de novos nomes emitidos. Sinais mais convincentes serão o aumento real dos nomes filhos operados por organizações, a adoção da delegação de permissões por papéis e a expansão dos aplicativos capazes de consultar esses nomes com estabilidade. O ENS já afirma suportar consultas de nome em mais de 600 aplicativos. A partir de agora, quem assumirá a responsabilidade por operar esses nomes determinará a confiança no protocolo. #ENS #Ethereum

Perguntas que o laboratório de IA receberá antes de comprar 12.480 registros de dados @datafdn @SuiNetwork [As três etapas da compra de dados que o Trace da DATA pretende conectar com Sui e Walrus] Suponha que um laboratório de IA esteja procurando dados para treinamento de voz. Se um vendedor apresentar um conjunto de dados com 12.480 registros, não é possível saber a quantidade real do material desejado apenas pelo número total de arquivos ou pelo contrato. Na verdade, o exemplo de auditoria de 1,42 TB mostrado pelo Trace da DATA Foundation inclui 6.140 vídeos, 3.770 imagens, 1.710 documentos e 860 áudios. Um laboratório buscando dados de voz começaria analisando os 860 arquivos de áudio, que correspondem a cerca de 6,9% do total. Esses números não são resultados reais de transações, mas dados de demonstração do Trace. Eles servem como um exemplo útil para entender quais informações o comprador deve revisar. Após selecionar o tipo de arquivo, é necessário verificar a autenticação do provedor, os registros de consentimento e termos de uso, e a integridade dos arquivos recebidos. A taxa de autenticação KYC de 96,4% exibida na mesma tela de demonstração refere-se aos contribuidores, enquanto a taxa de aplicação mais recente dos termos de uso de 91,8% indica a abrangência das versões de consentimento aplicadas. Como são métricas baseadas em critérios diferentes, na revisão da compra também é necessário examinar separadamente o status de autenticação do provedor e os registros de termos por arquivo. A parceria entre DATA Network e Sui, anunciada em 12 de outubro de 2026, tem como objetivo conectar esse processo de revisão diretamente aos arquivos originais e aos direitos de uso. Na época, o Trace já registrava mais de 250 milhões de contribuições de dados para IA e processava mais de 3 milhões de recibos por dia em média. A Sui Foundation investiu 30 milhões de dólares na DATA Network, e a DATA planeja migrar gradualmente de sua blockchain independente para um protocolo baseado em Sui. [Cinco etapas registradas em um recibo de 19,1 KB] Um único recibo Kled publicado no Trace contém o hash (SHA-256) de uma imagem HEIC de 19,1 KB, resolução 196 × 348, status KYC do provedor como Verified, histórico de upload/assinatura/registro e ligação à transação on-chain. A hora do upload foi em 6 de outubro de 2026; a assinatura do provedor e o registro no Trace ocorreram em 7 de outubro. Esta página exibe o histórico de registro e os itens comprovatórios, e não a imagem original. O ciclo de vida desse recibo possui cinco etapas. Na etapa Captured — correspondente à captura — aparece “Not recorded yet”. Os dados detalhados incluem o horário da ocorrência (occurred_at) e o horário do upload (uploaded_at), mas apenas esses campos não permitem determinar com precisão o momento exato da captura pela câmera. Os termos de uso também aparecem como “Not recorded” na seção Origin e “Current” no campo da versão em Identity & consent. Essas diferenças ajudam a dividir claramente os itens da revisão do comprador. O hash serve como identificador para comparar quais informações foram registradas; a assinatura e os registros on-chain fornecem evidências sobre quem e quando registrou essas informações. O status de autenticação do provedor e a versão dos termos são outros itens distintos. O direito do laboratório usar os dados para treinamento deve ser avaliado com base no conteúdo real do consentimento e no contrato de licença. [Função que transforma um recibo em 10 mil revisões] Na tela Verify do Trace, é possível colar até 10 mil IDs de dados ou submeter listas maiores em formato CSV. O sistema agrupa os recibos pertencentes a um conjunto de dados para consolidar o status de autenticação do provedor, a versão dos termos de uso, o tipo de mídia e o histórico de modificações, permitindo acessar cada registro individualmente. No exemplo anterior com 12.480 registros, vídeos e imagens somam 9.910 — cerca de 79,4% do total. Um laboratório buscando dados de voz e outro buscando dados visuais receberiam a mesma lista de venda, mas começariam a revisar diferentes conjuntos. A razão para exibir simultaneamente a taxa de autenticação do provedor e a abrangência dos termos é permitir que o comprador selecione os arquivos adequados ao seu objetivo e depois encontre as evidências necessárias para esses registros específicos. Além do Kled, o Trace também recebe registros da Numo — que lida com áudio e vídeo — e da oto — que lida com áudio interativo. Os recibos registrados por cada aplicativo provedor são agrupados em raízes Merkle e fixados on-chain. Portanto, um volume diário superior a 3 milhões de recibos não significa 3 milhões de transações on-chain distintas. Essa estrutura permite registrar grandes volumes de contribuições enquanto fornece caminhos auditáveis para cada conjunto de dados individual. [Quando os registros se conectam aos arquivos originais, a revisão muda] Atualmente, o Trace armazena recibos e metadados relacionados, mas não hospeda os arquivos originais. No anúncio da parceria entre DATA e Sui, foi proposto integrar o Walrus como camada padrão de armazenamento da aplicação da DATA Foundation, conectando referências criptografadas aos arquivos originais com os registros do Trace.Por exemplo, se o laboratório receber um arquivo adquirido, pode-se projetar um procedimento para obter permissão e acessar o arquivo de referência do Walrus, comparando os hashes. Isso fornece evidências para determinar se o conteúdo foi alterado durante a transmissão e como o arquivo processado posteriormente difere do arquivo de referência registrado. Como o arquivo de referência também é originalmente submetido pelo fornecedor, essa comparação serve como prova de identidade do arquivo, mas não garante automaticamente a autenticidade das condições reais de gravação ou do consentimento original. Os dados armazenados no Walrus são, por padrão, acessíveis publicamente; portanto, os arquivos originais confidenciais devem ser criptografados antes do armazenamento. O Seal da ecossistema Sui combina criptografia no lado do cliente, políticas Move e um servidor de chaves para implementar condições sob as quais a chave de descriptografia pode ser obtida. É possível projetar um serviço que forneça chaves apenas a titulares de licença, mas esse serviço não possui funcionalidade para revogar retroativamente chaves já emitidas. O escopo legal de uso deve ser registrado separadamente na licença e nos registros de consentimento. O Trace pode atuar como a camada para pesquisar histórico de registro e consentimento, o Walrus como a camada para armazenar originais criptografados de referência, e o Sui com o Seal como ferramentas para tratar conjuntos de dados como ativos programáveis e aplicar condições de acesso. As funcionalidades de registro e auditoria do Trace já estão em operação; a integração do armazenamento de originais no Walrus e do controle de acesso baseado no Seal a este serviço é um objetivo futuro. [Decisão de migrar a cadeia própria para o Sui] O DATA Network explicou que está migrando para o Sui para reduzir a carga de manter uma L1 independente e aumentar sua escalabilidade. A rede existente continuará operando até a conclusão da transição, e os saldos $DATA serão transferidos 1:1, mantendo-se as condições de bloqueio e vesting. A adoção do Walrus e a migração da rede serão realizadas em fases, com cronogramas detalhados a serem anunciados separadamente. O DATA trará para o ecossistema Sui os registros de registro de Trace já em operação e dos aplicativos fornecedores de dados. O Sui pode representar conjuntos de dados e licenças como objetos programáveis, enquanto o Walrus armazena originais de grande volume. Isso também abre espaço para direcionar capacidades de desenvolvimento anteriormente dedicadas à operação da cadeia para produtos de registro, licenciamento e verificação de compra de dados. O critério para avaliar o sucesso dessa combinação não é apenas a velocidade com que os recibos de registro aumentam. O desempenho real do produto é medido pela capacidade dos compradores reais de selecionar os arquivos desejados, comparar a autenticação do fornecedor e os registros de consentimento, comparar os arquivos recebidos com os originais de referência e utilizar os dados com permissões de acesso conforme acordado. As 12.480 telas de auditoria de demonstração mostram como os compradores acessam os conjuntos de dados. O recibo de 19,1 KB demonstra até onde é possível verificar o histórico de registro de um único arquivo. A colaboração entre DATA e Sui visa conectar o armazenamento original e o controle de acesso a esses dois caminhos de verificação. Se fornecedores de dados para aprendizado de IA puderem apresentar registros e os compradores puderem revisar esses registros juntamente com os arquivos reais, então centenas de milhões de recibos de registro tornar-se-ão infraestrutura utilizável em contratos individuais de compra. #DATAonSuiQuest

[Por que Kaito liberou a Aura gratuitamente] @KaitoAI @KaitoStudio_ Mesmo que alguém no X diga “tenho certeza sobre esse negócio”, é difícil saber se realmente colocaram dinheiro em jogo. É exatamente essa lacuna de informação que o Kaito busca preencher com a Aura. A ideia é conectar o que as pessoas dizem nas redes sociais com o que realmente fazem, em um único histórico. Aura é o sistema de reputação do Kaito. Ela vincula atividades comerciais verificáveis à influência acumulada no X, apresentando e avaliando o histórico da conta. O Kaito apresenta a Aura como uma funcionalidade que avalia transações verificadas e atribui valor às atividades reais. Você pode conectar sua conta na página da Aura para verificar seu histórico; os pontos acumulados nas últimas 48 horas podem ser recalculados. Por exemplo, imagine alguém que frequentemente posta previsões no Polymarket. Você pode ver o alcance desses posts pelas reações no X. Mas saber se essa pessoa realmente abriu posições é uma informação separada. O Kaito Pulse exibe informações de transação ao lado das postagens no X, e a Aura utiliza essas atividades como material para reputação. O Aura Arc conecta graficamente as atividades vinculadas e as contas sociais de diversos serviços. A conexão de serviços depende da escolha do usuário, e o escopo dos dados públicos varia conforme os aplicativos parceiros. Ou seja, o Pulse mostra o histórico de atividades na interface social, a Aura trata esse histórico como reputação, e o Aura Arc tenta expandir essa relação para outros serviços. O Kaito declarou que disponibilizará a Aura Arc gratuitamente e permitirá seu uso por produtos externos. Essa decisão gratuita pode ter uma lógica comercial: quanto mais amplamente utilizada for uma base de dados comum sobre quem ganhou confiança em quais áreas, maior será a demanda por usá-la para encontrar pessoas adequadas ou executar colaborações. O Studio ajuda marcas a selecionar, contratar e gerenciar pagamentos a criadores, enquanto o Katalyst vincula resultados de campanhas — como cliques, inscrições e depósitos — a recompensas. Na campanha Jumper apresentada pelo Kaito em 22 de outubro, foram recebidas 2.065 inscrições de criadores, 69 foram contratados e geraram mais de 760 mil exibições em 119 posts. É um exemplo concreto da capacidade do Kaito de reunir pessoas e operar campanhas. Mas a Aura também enfrenta desafios. Não basta apenas verificar registros de transações. Se apenas contas bem-sucedidas forem conectadas e contas com prejuízos forem ocultadas, mesmo que os registros individuais sejam reais, a reputação geral poderá ser distorcida. Também não há base para assumir que alguém com bom desempenho em negociações seja igualmente competente em análise técnica ou pesquisa de segurança. No fim, é necessário ser capaz de distinguir entre quem é famoso e o que alguém realmente fez em cada área específica. Se essas reputações por área realmente melhorarem as decisões das empresas, o escopo do negócio InfoFi poderá se expandir. Indicadores-chave serão: a taxa de recontratação de criadores pelas marcas, o número adicional de clientes gerados pelas campanhas, os tipos de atividades conectadas pela Aura e se os vieses na seleção de dados estiverem diminuindo. A próxima vantagem competitiva do Kaito dependerá não da capacidade de medir quanto interesse as pessoas recebem, mas da capacidade de provar que os históricos por trás desse interesse servem como base real para decisões. #Kaito #Aura #InfoFi

[Será que a IA recomendou minha marca? Uma IA que investiga isso custa a partir de 5 dólares] @termix_ai Na plataforma de agentes da TermiX AI, surgiu um serviço inesperado. Chama-se GEO Specialist. Ele investiga com que frequência outra IA menciona uma marca específica, onde a recomenda e quais fontes cita. O preço inicial é de 5 dólares. Imagine uma equipe que desenvolve ferramentas de segurança na BNB Chain. Mesmo tendo um site bem feito, quando alguém perguntar à IA onde consultar segurança de contratos inteligentes, pode ser que apenas outros serviços apareçam. Esse é o problema que surge quando os clientes já dependem das respostas da IA para filtrar candidatos antes de analisar os resultados de busca manualmente. Essa área é chamada de GEO (Generative Engine Optimization). O Google também explica que as respostas e a composição de links podem variar entre o resumo da IA e o modo IA. Os princípios básicos do SEO tradicional ainda são válidos, e não são necessários marcapções especiais específicas para aparecer na busca por IA. Então, é possível medir diretamente com que frequência a marca aparece nas perguntas reais dos clientes? Escolha 10 perguntas dos clientes que não mencionam o nome da marca e repita as mesmas perguntas em dois serviços de IA durante três dias — isso gera 60 respostas no total. Aqui estão os três pontos a registrar: 1. O nome da marca apareceu? 2. Foi incluído como recomendação real? 3. Os links citados são fontes apropriadas para justificar a recomendação? O resultado pode variar conforme a forma como as perguntas são formuladas. Se você perguntar “O que é a nossa empresa?” e o nome aparecer, é como dar a resposta direta na prova. Mas se o nome surgir quando alguém pedir recomendações sobre onde resolver um problema, estará mais próximo do processo de descoberta de um cliente que vê a marca pela primeira vez. Na plataforma de agentes da TermiX, esse tipo de investigação já está registrado como serviço pago. A estrutura de negociação entre agentes e liquidação on-chain conecta-se não apenas ao desenvolvimento de contratos inteligentes ou análise de dados, mas também à investigação de como as marcas são descobertas no ambiente de busca por IA. O ponto de partida é diferente quando alguém que já conhece a marca pesquisa seu nome e quando alguém que a vê pela primeira vez recebe uma recomendação da IA. Ao medir a visibilidade da marca na busca por IA, é tão importante registrar com que frequência ela foi mencionada quanto em quais perguntas ela apareceu. #TermiX #GEO

[Para que o XO seja lançado na Coreia do Sul, primeiro é necessário definir quais contratos podem ser permitidos] O @xomarket iniciou, em 20 de outubro, o Pulse PnL Panache (PPP), um torneio no qual os participantes negociam se o BTC subirá ou cairá nos próximos 5 minutos, competindo por lucros e prejuízos (PnL). Um total de 3.000 USDC e 30.000 CP será distribuído aos 10 primeiros colocados. Após a inscrição, apenas as negociações serão contabilizadas, e para figurar no ranking, é necessário atingir um mínimo de 5 USDC por transação e um volume acumulado de 100 USDC. A data prevista para encerramento é 3 de novembro. Contudo, mesmo que os participantes na Coreia do Sul cumpram os requisitos de participação, isso não torna as negociações legais. Em agosto, foi aprovada a bloqueio do acesso ao Polymarket, e em setembro, 26 usuários domésticos foram investigados por suspeita de jogos de azar, dos quais 18 foram encaminhados ao Ministério Público. Ainda não há condenações definitivas, mas ficou claro que permitir o acesso e as negociações com serviços estrangeiros não equivale à autorização sob a legislação nacional. Para que o XO entre no mercado coreano, antes de permitir o acesso local, é necessário determinar quais contratos podem ser legalmente aceitos. O PPP BTC 5-min Up/Down define seus resultados com base no preço de ativos digitais. Já contratos que apostam em eleições ou resultados esportivos diferem na natureza do evento base. Um estudo de direito empresarial coreano em 2026 também concluiu que contratos baseados em eventos políticos ou esportivos são difíceis de classificar como derivativos sob a Lei do Mercado de Capitais. Contratos baseados no preço do BTC exigem uma análise jurídica separada quanto ao ativo subjacente, estrutura da negociação e método de liquidação. Usar um preço como indicador não torna automaticamente um produto financeiro legal. Após essa distinção, é necessário definir os caminhos reais de autorização: É possível tratar esse produto conforme a legislação vigente? Quem pode oferecê-lo e sob quais autorizações ou licenças? Como evitar conflitos com regulamentos sobre jogos de azar ou atividades lúdicas? Essas questões devem ser organizadas com base em avaliações das autoridades competentes e fundamentos jurídicos. Se o contrato não puder ser resolvido pelo sistema atual, poderá ser necessária uma discussão legislativa específica. A simples designação como sandbox regulatório não isenta automaticamente problemas penais relacionados a jogos de azar. Por fim, há o design do produto: Antes de garantir a base legal, deve-se avaliar se é possível restringir separadamente para usuários coreanos: negociações em USDC, participação em torneios e recompensas em dinheiro por produto; enquanto funções que não envolvem apostas — como visualização de dados de mercado ou análise das regras de julgamento — podem ser oferecidas separadamente. Os termos do XO já proíbem o uso em regiões onde seja ilegal sob a legislação local. Aqui surge um fator decisivo para a futura competitividade do XO: A capacidade de aplicar permissões de uso diferenciadas conforme país, tipo de contrato e comportamento do usuário pode ser tão importante quanto a habilidade de abrir mais mercados preditivos. Mesmo que haja um caminho legal para produtos baseados no preço do BTC, isso não significa que todos os mercados preditivos políticos ou esportivos e torneios com recompensas serão automaticamente autorizados. O verdadeiro lançamento para usuários coreanos ocorrerá somente quando o escopo dos contratos permitidos, a qualificação jurídica dos operadores e as condições locais para negociação, liquidação e recompensas forem publicamente definidas e efetivamente aplicadas. #PredictionMarkets

[Se eu receber meu salário em USDC, o meu empregador poderá ver meu saldo também?] @Americanfort_io Vamos supor que um freelancer receba USDC mensalmente no mesmo endereço de carteira. Se você inserir esse endereço, que forneceu ao empregador, em um block explorer, será possível visualizar todos os outros depósitos e o saldo desse endereço. A informação que você divulgou para receber pagamentos torna-se uma pista para rastrear suas atividades financeiras. A AmericanFortress da Americanfort busca resolver esse problema separando o nome público do endereço real onde os fundos são recebidos. Primeiro, registre um nome de usuário como @FortressName. O destinatário digita esse nome em vez do endereço de carteira complexo, e o sistema calcula automaticamente um novo endereço stealth para enviar os ativos durante o processo de pagamento aprovado. Endereços stealth são projetados para evitar que o nome público fique facilmente vinculado a transações individuais de recebimento. Dessa forma, você continua usando o mesmo nome, mas reduz a exposição repetida dos seus endereços reais de recebimento. E quando for necessário comprovar o pagamento? O SafeSend, atualmente em desenvolvimento, planeja incluir uma funcionalidade que permite compartilhar apenas as informações de pagamento necessárias, em vez de toda a história de transações da carteira. Por exemplo, imagine um freelancer que precise provar que recebeu um valor específico, ou uma empresa que deseja fornecer apenas certas transações ao auditor. As transações permanecem registradas na blockchain, mas o risco de vincular todas as suas atividades financeiras a um único endereço público é reduzido. A carteira macOS atualmente disponível é uma versão beta. Nomes registrados na beta não podem ser usados para transferências reais de ativos e não serão transferidos para o ambiente oficial. Um SDK para integrar essa funcionalidade a carteiras e serviços externos também está em preparação para lançamento. Uma experiência que permite receber dinheiro sem divulgar seu endereço de carteira diretamente, e fornecer comprovação apenas das transações específicas quando necessário. Se a proposta de pagamento privado da AmericanFortress for efetivamente implementada, poderá ser aplicada a atividades financeiras cotidianas, como salários em stablecoins ou pagamentos a freelancers.

[Ações preferenciais com rendimento anual de 15% investidas pelo Saturn, calculado com base no valor recebido pela empresa: 17,2%] @saturn_credit As ações preferenciais $SATS emitidas pela Strive em 20 de outubro tiveram um valor total de oferta de US$ 630 milhões. No entanto, ao calcular os dividendos acumulados anualmente contratados para os 7 milhões de ações, o valor total é de US$ 105 milhões. Isso representa cerca de 16,7% do valor total da oferta. O Saturn também participou deste IPO utilizando seus próprios fundos de tesouraria. A diferença começa com o valor nominal de US$ 10 por ação. As SATS têm um rendimento anual de 15%, mas o cálculo se baseia em um valor nominal de US$ 100 por ação. O preço da oferta foi de US$ 90. Portanto, o dividendo anual acumulado por ação é de US$ 15, e a proporção em relação ao preço da oferta é: 15 / 90 * 100 = cerca de 16,7% Agora, vamos fazer o cálculo do ponto de vista da emissora. A taxa de oferta divulgada pela Strive é de US$ 3 por ação, totalizando US$ 21 milhões. Subtraindo esse valor do montante total da oferta, o valor recebido pela empresa, antes das demais despesas de emissão, é de US$ 609 milhões. 105000000 / 609000000 * 100 = cerca de 17,2% Essa é a proporção do dividendo anual acumulado em relação ao valor efetivamente recebido pela emissora. Não reflete o retorno do investimento considerando flutuações de preço, reinvestimento ou o momento real do pagamento de dividendos. A Strive também mencionou no documento de registro que reservará uma quantia equivalente a US$ 22,50 por ação — correspondente aos primeiros 18 meses de dividendos — em uma conta de reserva. Com base nos 7 milhões de ações, isso representa US$ 157,5 milhões. Essa medida visa garantir recursos iniciais para cumprir o alto dividendo fixo planejado. Há também uma hierarquia de prioridade. As SATS são subordinadas às ações preferenciais SATA e superiores às ações ordinárias ASST. Os dividendos são acumulativos, mas o pagamento em dinheiro real exige declaração do conselho e disponibilidade legal de recursos. O primeiro pagamento regular está programado para 9 de novembro. Essa transação gera cálculos diferentes para investidores e emissores. Os investidores assumem riscos de volatilidade de preço e possíveis atrasos no pagamento, além da subordinação a títulos com prioridade mais alta, em troca de dividendos elevados. Já os emissores obtêm capital para fins como compra de Bitcoin ou capital de giro, mas também assumem o ônus contínuo dos dividendos a longo prazo. O significado da participação do Saturn também deve ser distinto aqui. Este investimento é feito com recursos próprios da tesouraria do Saturn, separados dos ativos dos usuários do USDat ou sUSDat. É um exemplo em que o Saturn escolheu produtos de crédito baseados em Bitcoin como destino real de alocação de capital, sem qualquer anúncio de alteração nas garantias ou condições de pagamento dos produtos existentes. O que precisaremos observar nos próximos passos são: o pagamento real dos dividendos a partir de novembro, o preço das SATS no mercado e a gestão dos recursos da conta de reserva e da empresa. A interação desses três fatores será essencial para avaliar a sustentabilidade dos altos dividendos no crédito digital. #Saturn

[Com um único GPU, provou-se o Ethereum. Mas o teste real que precisa ser superado é diferente.] O @zksync provou 7.200 blocos consecutivos da rede principal do Ethereum com um único GPU. Desses, 99% foram provados em menos de 10 segundos, e todos os blocos foram provados em menos de 12 segundos. No entanto, segundo as métricas de operação em tempo real da EthProofs, apoiada pela @ethereum Foundation, apenas 2 dos 8 provadores avaliados atenderam aos critérios de elegibilidade da semana mais recente. Esses dois resultados não podem ser comparados diretamente, pois os objetivos e ambientes de medição são diferentes. Pelo contrário, essa diferença revela o próximo desafio da tecnologia ZK. Resumo simples: - O Airbender Prime demonstrou a possibilidade de atender ao ciclo de geração de blocos do Ethereum, de aproximadamente 12 segundos, com apenas um único GPU. - Na operação real de provadores, é necessário considerar não apenas a velocidade de prova, mas também a disponibilidade, falhas de prova e requisitos de hardware. - A longo prazo, a competitividade do zkEVM provavelmente será determinada mais pela verificação de precisão, pelo custo de prova em condições extremas e pela capacidade operacional estável do que pela velocidade de processamento de provas. O Airbender Prime, anunciado pelo ZKsync em 13 de outubro, provou 7.200 blocos consecutivos da rede principal do Ethereum com uma única GPU NVIDIA RTX PRO 6000 Blackwell. Como o Ethereum gera blocos a intervalos de aproximadamente 12 segundos, 7.200 blocos correspondem nominalmente a cerca de 24 horas de blocos. O fato de 99% dos blocos terem sido processados em menos de 10 segundos — incluindo o tempo necessário para preparar os dados de entrada (witness) — é significativo. Se a velocidade de geração da prova for suficientemente rápida em relação à chegada de novos blocos, os verificadores poderão confirmar os resultados da execução por meio de provas criptográficas, em vez de reexecutar todas as transações. Isso reduz potencialmente a quantidade de cálculos necessários para verificação. No entanto, realizar um teste de desempenho com 7.200 blocos é diferente de fornecer provas continuamente em um ambiente operacional real. A EthProofs mede publicamente o desempenho e o estado operacional de vários sistemas que provam blocos do Ethereum em tempo real. Na consulta realizada em 26 de outubro, o painel exibia os seguintes dados: - 8 provadores avaliados; apenas 2 atenderam aos critérios de elegibilidade da semana mais recente. - Taxa de sucesso de provas dentro de 10 segundos em relação aos slots de bloco avaliados: 69,7%. - Proporção classificada como offline: 26,2%. Esses números não são resultados do teste único do Airbender Prime. Trata-se de uma agregação operacional com múltiplos provadores, com diferentes equipamentos, ambientes de execução e critérios de elegibilidade. Contudo, eles demonstram que, para utilizar provas na rede real, é necessário garantir confiabilidade operacional além dos registros individuais de desempenho. Mesmo que um provador leve em média apenas 5 segundos para gerar uma prova, se ele frequentemente interromper ou falhar em processar certos blocos, uma estrutura de verificação que dependa exclusivamente desse sistema será difícil de manter estável. É necessário verificar se outro implementação pode fornecer uma prova quando um provador específico falha e se atrasos no processamento se acumulam quando blocos difíceis chegam em sequência. Também é necessário verificar separadamente os requisitos de hardware. O guia GPU do repositório público do Airbender indica que GPUs são usadas nas etapas básicas e recursivas da prova, enquanto a etapa final da prova exige CPU e cerca de 150 GB de RAM. Não está confirmado se esse documento descreve a mesma configuração utilizada no benchmark mais recente do Prime. Portanto, não é possível determinar o requisito total de memória ou o custo operacional do sistema inteiro com base apenas no resultado do teste com um único GPU. Em 15 de outubro, @VitalikButerin elogiou fortemente o desempenho da equipe Airbender e apresentou três próximos desafios para zkEVM: Primeiro: verificar matematicamente que os cálculos usados na prova correspondem exatamente às especificações reais de execução do Ethereum. Segundo: impor limites rigorosos ao custo da prova em relação ao uso de gás do bloco. Terceiro: verificar a segurança criptográfica do próprio sistema de prova. O segundo requisito está diretamente ligado ao custo operacional real. Mesmo que blocos comuns sejam provados em menos de 10 segundos, e se alguém intencionalmente configurar operações extremamente difíceis dentro do limite permitido de gás? A execução do bloco pode ter sido paga normalmente, mas a geração da prova pode exigir quantidades excessivas de cálculo e tempo. Se tal situação for possível, mesmo que o tempo médio de prova por bloco seja muito curto, será difícil prever a carga máxima que a rede pode suportar com estabilidade. A viabilidade econômica da prova em tempo real depende não apenas do custo médio da prova por bloco, mas também da quantidade máxima de recursos necessária em cenários extremos. A rota da EthProofs também está avançando nessa direção.A fase atual de melhoria de desempenho foi concluída e a fase de verificação de segurança está em andamento. Em seguida, estão planejadas as etapas de integração direta da prova de atraso, prova de obrigação e prova no protocolo. Essa ordem é importante porque criar um sistema de prova rápido é diferente de fazer com que o Ethereum confie nessa prova no processo de consenso. O anúncio do Airbender Prime forneceu evidências fortes de que é possível reduzir a carga de hardware da prova em tempo real. A próxima conquista não poderá ser avaliada apenas por registros mais rápidos. É crucial saber por quanto tempo uma alta taxa de sucesso de prova pode ser mantida em ambiente real, se o custo da prova permanece limitado mesmo no pior bloco e se diferentes implementações provam com precisão os mesmos resultados de execução do Ethereum. A tecnologia de prova ZK está passando da fase de demonstrar cálculos rápidos para se tornar uma infraestrutura na qual a rede realmente pode confiar. #Ethereum #zkEVM