Upgrade Cobalt na Base traz novos controles para ativos tokenizados

A Base ativou o Cobalt em 30 de setembro. Para os emissores de seus tokens B20, o fork adiciona uma maneira de agendar multiplicadores de saldo, apreender saldos com um registro e combinar políticas de transferência. Nada disso torna um ativo tokenizado uma ação na empresa que ele rastreia. Isso torna as regras aplicadas pelo token mais explícitas, e a identidade do emissor mais relevante.

A especificação da atualização Cobalt registra uma ativação na mainnet em 30 de setembro, uma semana após a Sepolia. A página de status pública da Base colocou a janela de manutenção da mainnet às 18:00 UTC e a marcou como concluída às 20:00 UTC. O fork adiciona funções de ativo B20, transações condicionais ao estado da cadeia, um registro para agendamento de futuras atualizações em modo de monitoramento e um método on-chain para registrar certos signatários de provador de ambiente de execução confiável. Essas são mudanças separadas. A história dos ativos começa com o B20, o formato de token introduzido com a atualização Beryl anterior.

O fork entrou no ar, mas sua lista de desejos completa não

Duas ideias que apareceram em discussões anteriores do Cobalt estão ausentes do escopo implantado. O pagamento de taxas de rede em tokens B20 foi removido da lista do fork em 29 de setembro. Blocos canônicos mais rápidos de 200 milissegundos pertencem a uma proposta de atualização posterior, Denim, não a esta ativação. A abstração de conta nativa não tem portão de mainnet agendado aqui. Tratar qualquer uma dessas como funções ativas do Cobalt confundiria um roteiro com código que um emissor ou trader pode usar hoje. A distinção é especialmente importante para instituições que avaliam um padrão de token em relação aos requisitos de conformidade atuais.

O piso de versão do nó da Base é v1.4.2 para a mainnet, de acordo com a documentação da atualização. A v1.4.1 anterior incluía o timestamp, mas perdeu mudanças no encaminhamento de RPC de transações de validade; a v1.4.0 não contém a ativação da mainnet. Um nó que segue um fork sem encaminhar corretamente o novo tipo de transação pode apresentar uma visão parcial do que os usuários pensam ser uma rede uniforme. A distinção em nível de código é mais instrutiva do que uma declaração genérica de que o Cobalt está ativo.

O gancho de notícia é real, mas não é a tese completa. A ativação anterior do B20 já havia colocado ativos gerenciados por emissores na Base. O Cobalt aumenta as ações que o emissor pode tomar e as decisões de política que uma transferência pode enfrentar. A questão-chave é quem pode invocar essas funções, sob qual promessa legal, e como um detentor pode verificar o resultado.

Um saldo B20 é um registro contábil com um emissor

Um produto de capital tokenizado pode ser representado como um saldo na Base, enquanto os direitos sobre o título subjacente ficam com um corretor, custodiante ou emissor contratual. O padrão de token não pode, por si só, forçar um agente de transferência a reconhecer o detentor da carteira como acionista. O vínculo entre saldos on-chain e direitos de propriedade off-chain vem dos documentos do produto e das entidades responsáveis pela garantia, resgate e ações corporativas. Um token de segurança pode ser tecnicamente transferível e contratualmente restrito ao mesmo tempo.

A cobertura do lançamento de ações tokenizadas da Coinbase descreve um mercado no qual os arranjos de lastro e os usuários elegíveis importam tanto quanto as interfaces de negociação. Esse contexto torna as adições do Cobalt mais do que conveniências para desenvolvedores. Uma política pode excluir um endereço, exigir uma condição ou permitir apenas uma classe de transferência. Uma apreensão administrativa pode reatribuir um saldo. Um multiplicador pode alterar como os saldos são exibidos entre contas. Cada função pode atender a uma necessidade operacional lícita e também pode criar dependência do julgamento do emissor ou da segurança da chave administrativa.

O formato B20 precisa ser examinado no nível do token. O simples fato de a Base suportar seizeWithMemo não concede a todo emissor de B20 um direito de apreensão sobre todo token, muito menos sobre todo ERC-20 na Base. A referência de precompilações do B20 afirma que um token cujo emissor não configurou o slot de política aplicável não tem capacidade de apreensão. Um auditor precisa inspecionar a política e as contas autorizadas desse token. Dois ativos que usam o mesmo padrão podem ter direitos de titular acentuadamente diferentes.

Esta é a primeira divisão de controle a colocar em um quadro branco: a cadeia decide se uma transação está em conformidade com as regras implantadas; o emissor decide qual chamada administrativa permitida enviar; e o provedor do ativo do mundo real é responsável por determinar se o token corresponde a uma reivindicação executável. O Cobalt altera as duas primeiras camadas. Ele não resolve a terceira. O mesmo endereço pode negociar um token on-chain e ainda assim falhar em um teste de elegibilidade off-chain no momento do resgate.

A apreensão deixa um rastro, mas o motivo está off-chain

O Cobalt introduz o seizeWithMemo, uma operação autorizada pelo emissor que move tokens de um titular em uma única etapa administrativa, substituindo um fluxo anterior de burnBlocked. O memo pode deixar um marcador de motivo no registro on-chain. Ele não prova que o motivo era legalmente suficiente. Um contrato inteligente pode verificar que a conta chamadora tem autoridade e que as isenções configuradas se aplicam. Ele não pode decidir se uma ordem judicial era válida, se o emissor identificou o réu correto ou se a reclamação de um cliente deveria prosperar.

O guia de operações do emissor descreve a mecânica. Um token pode usar a apreensão para uma ordem de sanções, emissão equivocada, recuperação sob termos contratuais ou uma ação corporativa. Cada uma é uma justificativa diferente. O titular deve ser capaz de encontrar a identidade do administrador, a política, o evento e um processo de disputa nos documentos legais do produto. Se um emissor apenas diz que a tokenização é transparente, o leitor deve perguntar transparente sobre o quê: a transferência pode ser visível enquanto a decisão subjacente permanece opaca.

Há um detalhe sutil de implementação. A documentação diz que o escopo de isenção mudou de nome de SEIZE_HOLDER_POLICY para SEIZE_EXEMPT_POLICY, com um seletor diferente. Código que codifica fixamente o escopo antigo pode falhar ao ler ou definir o novo, embora os seletores mais antigos do Beryl continuem de outra forma. Esta é uma questão genuína de integração para emissores e auditores, não uma alegação geral de que os saldos se tornaram recém-apreensíveis em 30 de setembro. Verifique a configuração de política do token ativo e teste a chamada administrativa sob o fork implantado.

A cadeia fornece uma trilha de evidências que correções de contas convencionais podem não expor publicamente. Se um emissor move 100 tokens de uma carteira para outra, os observadores podem contar 100 tokens e identificar a transação. Eles não podem inferir uma transferência de 100 ações no registro de acionistas off-chain do emissor sem reconciliação. O argumento mais forte do emissor é que ativos regulados precisam de procedimentos para correção de erros e ordens legais; o volume de ações tokenizadas na Base fornece o contexto prático de por que esses procedimentos agora são escolhas de design em vez de debates abstratos. O trade-off é que o titular aceita um administrador com poder significativo.

O multiplicador pode alterar unidades sem um depósito correspondente

Um multiplicador programado permite que um emissor defina uma mudança futura na forma como o saldo unitário de um ativo B20 é representado. Pense em um desdobramento de ações. Se a quantidade exibida de um titular passa de 10 unidades para 20 em uma proporção de 2 para 1, enquanto a reivindicação econômica por unidade cai pela metade, o valor não precisa mudar. O mecanismo on-chain pode coordenar o ajuste de saldo sem exigir que cada titular assine. O emissor ainda precisa implementar a ação corporativa correspondente no mundo real e explicar a conversão a corretoras, custodiantes e feeds de preços.

A aritmética é simples e a reconciliação não é. Suponha que 1 milhão de unidades de token estejam em circulação e um multiplicador de 2 para 1 esteja agendado. As novas unidades exibidas seriam 2 milhões se o mesmo multiplicador se aplicar aos saldos relevantes. Isso não cria 1 milhão de ações subjacentes adicionais. Um emissor responsável deve mostrar que as reivindicações benéficas totais permanecem inalteradas e que o próprio desdobramento do título de referência entrou em vigor em termos correspondentes. Se as unidades de token dobrarem enquanto um sistema de negociação mantém uma referência antiga de preço por unidade, um gráfico ou motor de garantia pode declarar incorretamente a exposição por um fator de dois.

A função de agendamento melhora a coordenação ao nomear o momento antes que ele chegue. Também dá aos observadores algo para monitorar: uma atualização pendente, seu signatário autorizado e os saldos de oferta e detentores após a mudança. Não garante que todo sistema dependente consuma a atualização a tempo. Um livro de ofertas de exchange, oráculo, cofre de empréstimo e livro fiscal podem usar instantâneos diferentes. Um multiplicador executado corretamente on-chain ainda pode criar erros operacionais onde as integrações armazenam em cache a representação antiga.

A semântica de saldo do B20 também importa para dados históricos. Um explorador que mostra o saldo do detentor após o desdobramento pode não explicar quantas unidades o detentor possuía um dia antes ou o que cada unidade representava. Analistas devem normalizar as quantidades para o multiplicador em vigor em cada carimbo de data/hora antes de afirmar que os depósitos dispararam ou que a oferta inflou. Um registro de eventos publicado fornece um caminho para essa normalização, mas é um trabalho que alguém precisa fazer. O volume de negociação declarado como tokens brutos ao longo do evento não é comparável sem uma unidade ajustada.

Combinar políticas expõe a decisão de elegibilidade

Union e Intersect são os dois novos tipos de política composta. Union permite uma operação se uma política subjacente a aceitar sob a lógica configurada; Intersect exige que múltiplas condições subjacentes sejam aprovadas. As políticas constituintes exatas e a direção da autorização devem ser lidas na configuração do token. A analogia útil é um portão com emblemas alternativos versus um portão que exige vários emblemas. Não é uma declaração de que todo token deve realizar verificações de identidade.

Imagine um ativo cujo emissor permite transferências para carteiras de corretoras aprovadas ou para um contrato de resgate designado. Uma política Union pode expressar alternativas. Outro emissor pode exigir que tanto o remetente quanto o destinatário atendam a condições separadas, onde um arranjo Intersect é mais apropriado. Se uma condição for mantida off-chain por meio de um registro autorizado, a regra aparente de transferência on-chain ainda depende de uma organização atualizar esse registro. Uma lista de permissões alterada pode mudar a negociabilidade sem que o detentor mova um token.

Políticas compostas facilitam descrever um ativo regulamentado em módulos reutilizáveis. Elas também podem dificultar que um detentor descubra por que uma transferência falhou se a interface relatar apenas um revert genérico. Os invariantes e testes do B20 dão aos desenvolvedores um ponto de partida, mas um produto ainda precisa de divulgação legível por humanos de quais endereços podem agir, quem atualiza as listas e como os erros são contestados. Um token com permissão e um portão não documentado não é significativamente transparente só porque o portão está em uma cadeia pública.

O argumento oposto mais forte é prático. Um título tokenizado oferecido em várias jurisdições não pode prometer transferência irrestrita e também satisfazer restrições de elegibilidade, ordens judiciais e processamento de ações corporativas. Controles programáveis podem ser mais previsíveis do que congelamentos manuais em um banco de dados de corretora. Esse caso se sustenta quando os controles são estreitamente delegados, auditáveis e vinculados a termos executáveis. O risco oposto é igualmente específico: uma chave administrativa, registro de políticas ou interpretação do emissor pode determinar o acesso de um usuário. O fork Cobalt fornece primitivas. Os emissores fornecem governança.

Transações condicionais não substituem as regras do emissor

Cobalt também introduz transações de validade: transações assinadas emparelhadas com condições no estado da cadeia, mantidas até que essas condições correspondam. Este é um recurso geral de transação, não uma renúncia automática de conformidade. Um usuário pode querer que uma ordem seja executada apenas se um saldo, estado relacionado a preço ou outro predicado tiver um valor especificado. Uma transação que se torna elegível ainda precisa satisfazer a política de transferência do token no momento da execução. Se um emissor alterou uma lista de permissões nesse meio tempo, a transação pode falhar ou permanecer inelegível dependendo de suas condições.

Essa interação cria uma questão valiosa para a estrutura de mercado. Se um trader assina uma ordem hoje que se torna válida amanhã, quem pode alterar o estado do qual depende sua execução? Parte do estado vem de contratos neutros; parte vem de uma política controlada pelo emissor. Uma transação condicional pode reduzir uma forma de incerteza de execução enquanto deixa o detentor exposto à capacidade de um administrador de atualizar permissões. Documentos de integração devem dizer qual predicado foi verificado, quando foi verificado e o que acontece na expiração ou cancelamento.

O software do nó determina se as carteiras e os provedores de serviços veem o novo caminho de forma confiável. O mínimo da mainnet v1.4.2 inclui comportamento de RPC para encaminhar envios de validade a uma entrada de sequenciador compatível. Um nó v1.4.1 pode seguir o fork de consenso, mas falhar nessa rota de envio. Para um usuário, a distinção aparece como uma transação rejeitada confusa, não como uma discussão sobre tags de lançamento. Para uma instituição, exige testes de ponta a ponta com a versão exata do nó e o provedor de RPC usados em produção.

Há outra fronteira: o sequenciamento da Base e a infraestrutura de liquidação eventual. Uma política do emissor é aplicada na execução quando a transação é executada; o envio condicional não dá ao usuário uma garantia sobre quando um sequenciador incluirá uma transação elegível. Nem um recibo rápido on-chain, por si só, resolve um litígio legal sobre a ação subjacente. O Cobalt melhora a expressão e a admissão de transações. Ele não funde ordenação, propriedade legal e resgate em uma única prova.

A papelada determina o ativo por trás do token

Um detentor que avalia uma ação tokenizada deve começar fora da chain: quem é o dono do título de referência, onde ele é mantido, qual reivindicação o token confere e quem deve ao detentor no resgate? Se o produto for um derivativo ou uma reivindicação contratual sobre um emissor, o detentor pode não ter os direitos de voto ou de insolvência de um acionista direto. O Cobalt não altera essa classificação. Seus controles adicionados podem implementar termos já presentes no contrato ou dar ao emissor nova capacidade técnica que exige divulgação atualizada.

A lista crescente de ações tokenizadas da Coinbase ilustra a velocidade com que os menus de produtos podem crescer. Um ticker de ação familiar em um aplicativo não substitui o nome da entidade legal do emissor e os termos específicos do ativo. Alguns produtos estão disponíveis apenas para certos usuários ou jurisdições. Restrições podem ser aplicadas no onboarding, na transferência, no resgate ou nos três. Se a transferência on-chain for aberta, mas o resgate for permissionado, o comprador secundário pode acabar com um token que não consegue resgatar diretamente.

Uma divulgação transparente de políticas listaria cada função de administrador, as funções que ele pode chamar, se uma multifirma é exigida, se os poderes têm bloqueio temporal e como mudanças de emergência são anunciadas. Ela mapearia cada poder on-chain para uma cláusula contratual. Mostraria o processo de verificação de reservas ou custódia e como um detentor pode contestar uma apreensão. O número de carteiras on-chain que detêm um token não pode responder a essas perguntas. Um token pode se espalhar por milhares de endereços enquanto um único emissor mantém autoridade decisiva sobre cada resgate.

O Cobalt também torna uma palavra antiga, “propriedade”, mais difícil de usar casualmente. Uma pessoa pode possuir a chave privada que controla uma carteira. Outra entidade pode controlar a emissão de tokens e transferências administrativas. Um custodiante pode deter a ação de referência. Uma corretora pode controlar o acesso ao mercado. Um tribunal pode afirmar autoridade sobre a reivindicação. Esses direitos podem ser legalmente coerentes, mas sua alocação deve ser explícita. A chain não pode resgatar documentos de produtos ambíguos tornando uma parte do livro-razão pública.

Meça a implantação por ativos configurados, não pelo status do fork

A ativação do fork é verificável em um bloco e horário. A adoção de seus novos poderes B20 exige uma contagem diferente: quantos contratos de ativos ativos realmente configuram as novas políticas, quantos agendam multiplicadores e quantos invocam apreensão? Uma contagem zero logo após a ativação não significaria que o fork falhou. Significaria que os emissores ainda não usaram essas funções opcionais. Uma contagem grande não provaria que os ativos estão totalmente lastreados ou que os controles são bem governados.

Uma medição reproduzível inventariaria ativos B20, verificaria os seletores de política na mesma altura de bloco, identificaria endereços de administrador e classificaria as chamadas observadas após 30 de setembro. Contaria separadamente as tentativas que revertem e as mudanças de estado bem-sucedidas. Evitaria presumir que um ativo chamado “ação” tem uma ação subjacente apenas porque seus metadados dizem isso. Essa é uma medida de adoção melhor do que o volume de transações, que pode refletir negociação especulativa em tokens cuja estrutura legal difere amplamente.

O limite do registro atual é que a especificação do fork descreve uma capacidade, não um registro completo de emissores ativos e seus termos. Não há uma configuração universal do Cobalt que determine todos os direitos de ativos tokenizados. Cada emissor pode configurar funções de maneira diferente, e uma atualização posterior pode alterar permissões. Um nó pode verificar corretamente uma transferência enquanto a declaração do custodiante off-chain permanece atrasada ou disputada. Um token pode mostrar uma movimentação administrativa em público sem informar ao detentor se ela foi legal.

A conclusão é concreta. A Base agora tem ferramentas mais precisas para os emissores controlarem saldos de ativos e elegibilidade. Os detentores ganham uma chance melhor de inspecionar esses controles se os emissores os divulgarem claramente. O teste significativo começa em cada token: quem pode alterar o multiplicador, quem pode confiscar, quem pode alterar a política de transferência e qual reivindicação legal sobrevive se o emissor falir?

Um detentor pode testar três promessas contra um contrato

A primeira promessa é o fornecimento. Um relatório de lastro pode dizer que cada token corresponde a uma unidade de um ativo subjacente mantido por um custodiante. O detentor pode comparar o fornecimento de tokens relatado no snapshot do relatório com a posição declarada pelo custodiante, ajustando para qualquer multiplicador então em vigor. Os dois números precisam do mesmo carimbo de data/hora e unidade. Um relatório de 1 milhão de ações no fechamento de ontem não pode ser colocado ao lado de um fornecimento pós-desdobramento de 2 milhões de tokens hoje e chamado de déficit. Nem um agregado correspondente prova que cada detentor individual tem o direito de resgate que a página de marketing implica.

A segunda promessa é a transferência. Um produto pode anunciar liquidação ponto a ponto, então aplicar uma política que permite transferências apenas entre intermediários registrados. Ambas as afirmações podem ser verdadeiras se o conjunto de pares permitidos for restrito. Um detentor pode inspecionar as políticas configuradas do token, enviar uma simulação somente leitura de uma transferência entre tipos de endereço representativos e comparar o resultado com as regras de elegibilidade publicadas. Esse exercício deve incluir uma carteira elegível para manter, uma carteira inelegível e o destino de resgate. Se os resultados diferirem dos termos, o emissor deve explicar a discrepância antes que os usuários negociem.

A terceira promessa é o recurso. Um usuário cujo saldo é movido por seizeWithMemo precisa de mais do que um hash de evento. O emissor deve publicar uma referência de caso que proteja informações privadas enquanto identifica a autoridade invocada, o termo aplicável, a data do aviso e o canal para contestação. O detentor pode então comparar a movimentação registrada com essa conta. Um memorando que diz “compliance” sem um procedimento faz pouco por alguém contestando uma identidade equivocada ou instrução duplicada. Um padrão de token não pode compelir um recurso justo, mas seu rastro de eventos pode tornar a ausência visível.

Há um quarto teste prático para qualquer um que use esses tokens como garantia. Um protocolo de empréstimo pode marcar o ativo a um preço de mercado e aceitá-lo como segurança para um empréstimo. Se o emissor pode congelar ou confiscar o endereço da garantia, ou alterar a contagem de unidades através de um multiplicador, o software de liquidação precisa entender ambos os eventos. Um credor que precifica um ativo apenas pelo ticker pode perder uma restrição no nível do contrato para transferi-lo durante a liquidação. O mutuário, enquanto isso, pode ver uma cotação de preço saudável, mas ser incapaz de mover o saldo penhorado para pagar. A divulgação relevante é se o próprio contrato de empréstimo é isento, quem pode alterar essa isenção e o que acontece quando o emissor revoga a elegibilidade de um usuário.

Um custodiante pode responder algumas perguntas com uma atestação independente, mas uma atestação tem um escopo. Ela pode verificar ações mantidas em uma conta omnibus em um momento específico sem verificar que os detentores de tokens têm um interesse de propriedade direto. Pode verificar lastro agregado sem verificar se um confisco alterou a distribuição entre clientes. Uma auditoria séria declara a entidade legal, o identificador do ativo, o momento do snapshot, o método de reconciliação e as exclusões. O documento deve ser atualizado após emissão material, resgate ou ação corporativa. Os leitores devem ser capazes de comparar snapshots sucessivos, não apenas admirar um selo único em um aplicativo.

Há um caso de falha que a blockchain não pode resolver: o emissor entra em insolvência enquanto o token continua a ser negociado. O fornecimento on-chain, as políticas e os registros de eventos podem estar todos intactos. A questão decisiva então é se os ativos subjacentes estão segregados para os detentores, parte do patrimônio de um custodiante, ou uma reivindicação geral contra o emissor. Um contrato inteligente com execução perfeita de restrições de transferência não escolhe uma prioridade de falência. É por isso que a precisão administrativa do Cobalt aumenta a urgência de ler os termos do produto. Ela diz aos usuários exatamente o que o emissor pode fazer com o token, enquanto os documentos devem dizer-lhes o que eles podem exigir do emissor.

Uma auditoria que teste todas as três promessas iria além de mostrar que o código é executado. Ela conciliaria as reivindicações pendentes com os ativos mantidos, os portões de transferência reais com o livro de regras publicado e as ações administrativas com um processo fora da própria interface do emissor. A cadeia pública fornece evidências para cada teste, mas nunca a resposta completa. Os registros de custódia e os termos do contrato devem ser trazidos para a mesma data e unidade. Esse é o trabalho que um ativo tokenizado exige após o anúncio comemorativo do fork.

Mais um limite operacional merece um teste público. O administrador de um token pode ser uma carteira multifirma com vários signatários, mas uma única empresa poderia nomear todos os signatários. Publicar o limite sem nomear os órgãos de governança não demonstra supervisão independente. Um emissor pode divulgar o limite, o procedimento de rotação de chaves e a autoridade de emergência sem revelar segredos. Se ele afirma que os detentores podem recorrer de uma decisão, deve identificar a entidade legal que analisa um recurso e o período em que responde. Esses fatos transformam uma permissão on-chain em um processo responsável.

Um leitor cético também deve verificar se as mudanças de política emitem eventos que os provedores de dados acompanham. Se uma carteira foi autorizada a transferir ao meio-dia e bloqueada às 12h01, o momento importa para uma ordem pendente, o cálculo de margem de um credor e um detentor tentando resgatar. Um painel que atualiza uma vez por dia pode fazer uma mudança em tempo real parecer uma apreensão surpresa. Monitorar o contrato diretamente pode fechar essa lacuna, mas o provedor do produto ainda deve enviar aviso aos usuários cujos direitos mudam. A Cobalt torna as mudanças executáveis. A divulgação determina se essas mudanças são inteligíveis.

O que observar

• Contagens de políticas configuradas: Contratos B20 públicos usando permissões Union, Intersect e de apreensão após o fork de 30 de setembro.
• Primeiro multiplicador agendado: Seu horário efetivo anunciado, proporção aplicada e reconciliação com a ação corporativa off-chain.
• Movimentações administrativas: Eventos bem-sucedidos de seizeWithMemo, o papel autorizador e uma explicação do emissor para cada caso relevante.
• Paridade de RPC: Principais nós da Base e provedores de RPC executando pelo menos a v1.4.2 e aceitando envios de validade de forma consistente.
• Divulgações do emissor: Termos de produto que mapeiam cada poder de administrador on-chain para um direito exigível e um processo de recurso.

Perguntas frequentes