Explicado · Stellar
Stellar propõe endereços que identificam clientes dentro de um mesmo contrato
A proposta CAP-84 permite acrescentar um identificador de 64 bits ao endereço de um contrato inteligente; a votação para ativar a atualização Bell na rede principal está marcada para 23 de novembro.
A proposta CAP-84, incluída na atualização Bell (Protocolo 30) da Stellar, cria endereços muxed para contratos inteligentes. O endereço pode carregar um identificador de 64 bits associado a um cliente. Quando um token é enviado a esse endereço, o valor chega ao contrato e o identificador fica registrado no evento da transferência, permitindo que o aplicativo reconheça a quem creditar o depósito.
O mecanismo adapta aos smart accounts uma função já usada por contas tradicionais muxed. Nelas, uma empresa recebe depósitos de vários clientes em uma conta agregada e usa um ID para separar os registros. Contratos inteligentes ainda não tinham esse formato: para distinguir saldos de clientes, uma empresa precisava implantar um contrato separado para cada um. Com a CAP-84, um único contrato pode atender vários clientes mantendo a identificação de cada transferência.
O novo tipo de endereço começa com W, enquanto endereços muxed de contas tradicionais usam M. Carteiras, exchanges, exploradores e aplicativos que validam ou processam endereços precisam reconhecer o novo formato e atualizar seus SDKs. A mudança não altera o princípio de que os tokens são recebidos pelo contrato; ela acrescenta a identificação do cliente ao registro da transferência.
A Bell também propõe que contratos verifiquem assinaturas pós-quânticas ML-DSA e que o horário de fechamento dos livros use precisão de milissegundos. A verificação ML-DSA pode permitir que um contrato de conta exija esse tipo de assinatura para autorizar gastos, mas as assinaturas das transações da rede continuam em Ed25519. O relógio em milissegundos prepara ajustes futuros e não acelera sozinho o fechamento dos livros.
A Stellar Development Foundation marcou a votação de validadores para ativar o Protocolo 30 na rede principal em 23 de novembro de 2026, às 17h UTC. A ativação depende da aprovação dos validadores; até lá, as mudanças são uma atualização proposta, não uma capacidade já disponível na rede principal.