Duas contabilidades para o mesmo dinheiro

Todo sistema que registra dinheiro precisa responder a duas perguntas: quanto existe e de quem é. Existem exatamente duas famílias de resposta, e a literatura de moedas digitais de banco central consolidou seus nomes ([1], [2]): no modelo account-based, a unidade de registro é a conta, e o valor é um número armazenado dentro dela; no modelo token-based, a unidade de registro é o próprio valor, um objeto discreto que carrega seus atributos, e a conta vira uma forma de agrupá-los.

A distinção parece sutil porque, vista de fora, as duas contabilidades produzem os mesmos relatórios: extrato, razão, balancete. A diferença aparece no que cada uma consegue afirmar sem ajuda externa — e no que cada uma precisa reconstruir. Esta nota descreve os dois modelos com precisão, mostra que cada um pode representar o outro (a custos muito diferentes), e examina a pergunta que todo contador e todo auditor fazem primeiro: o que acontece com as partidas dobradas e com a não-duplicidade quando não existe mais um saldo para editar.

O que o modelo account-based registra

No modelo account-based, a conta é uma linha e o saldo é um número gravado nessa linha. Movimentar dinheiro é editar dois números sob uma transação: subtrair de uma linha, somar em outra. A pergunta que o sistema verifica antes de mover é sobre identidade: quem está pedindo tem autoridade sobre esta conta? ([1], [2])

Sobre o valor em si, o modelo registra uma única propriedade: a quantidade. Origem, condição de uso, estado de liquidação — quando existem, vivem em tabelas auxiliares, fora da aritmética que define a verdade do sistema. E dentro da conta, os créditos se somam. Como a nota anterior desta série argumenta em detalhe, essa soma destrói a informação de composição por definição, não por descuido: uma vez que a₁ + a₂ = S, nenhuma operação recupera as parcelas a partir de S, porque S nunca as carregou.

O que o modelo token-based registra

No modelo token-based, a unidade de registro é um objeto de valor: uma quantia discreta que carrega, como propriedades suas, o dono, a origem, a regra sob a qual pode se mover e o estado em que está. Movimentar dinheiro não é editar números — é consumir objetos existentes e criar objetos novos, numa transição única.

A pergunta verificada antes de mover muda de natureza. Não é apenas "quem pede tem autoridade?", é "este objeto existe, está no estado certo, e a transição proposta respeita a regra que ele carrega?" — a verificação recai sobre o objeto, não apenas sobre a identidade de quem o apresenta ([1]).

E o saldo deixa de ser uma coisa gravada. Ele é uma visão derivada, calculada no momento da pergunta:

saldo(conta) = o₁ + o₂ + ⋯ + oₙ

a soma dos objetos cujo dono é aquela conta. Não existe "editar o saldo" porque não existe o saldo como registro — existe o conjunto de objetos, e uma consulta sobre ele.

Cada modelo representa o outro — mas não ao mesmo custo

Os dois modelos são formalmente equivalentes: qualquer estado de um pode ser expresso no outro. O que difere, e difere de forma decisiva, é o custo de cada direção.

Do token-based para o account-based, a representação é uma consulta: agrupe os objetos por dono e some. Todos os artefatos da contabilidade clássica — extrato, razão, balancete — são visões deriváveis do conjunto de objetos, e podem ser materializadas quando a velocidade de leitura exigir, como qualquer cache reconstruível a partir da fonte.

Do account-based para o token-based, a representação exige construir uma estrutura para cada distinção que se quer preservar: uma subconta por origem, uma conta de passagem por operação em trânsito, uma tabela paralela de carimbos e finalidades. É o que a indústria faz há décadas, e funciona — até o ponto em que a distinção importa de verdade.

A assimetria é essa: num sentido, a representação é uma consulta. No outro, é uma arquitetura inteira de contornos — e a conciliação é o custo permanente de mantê-la de pé.

Nada no modelo account-based obriga a subconta e a verdade a andarem juntas; a disciplina é da aplicação que escreve, não do ledger que registra. Quando a aplicação erra, o ledger não percebe.

O que as partidas dobradas exigem

Desde a formalização de Pacioli ([3]), a contabilidade de partidas dobradas se apoia num invariante: valor não aparece do nada nem desaparece para o nada. Todo débito tem um crédito correspondente, e a prova de integridade é que as colunas fecham. Duas premissas operacionalizam esse invariante: a conservação de valor e a não-duplicidade. Vale examinar como cada modelo as cumpre.

Conservação. No account-based, a conservação é uma disciplina de lançamento — toda operação deve escrever as duas pernas — verificada depois, no balancete: se as colunas não fecham, algum lançamento quebrou a regra em algum momento do período. No token-based, a conservação é uma propriedade de cada transição: a transação declara quais objetos consome e quais cria, e só é válida se a soma do que cria for igual à soma do que consome. Os objetos consumidos são o débito; os criados são o crédito. As colunas continuam fechando — mas fecham por transição, no momento em que ela acontece, não por período, no relatório que confere depois. Emissão e resgate não são exceções ao invariante: são transições com regra própria, restritas a quem tem esse mandato, exatamente como o caixa de um banco não é uma violação das partidas dobradas.

Não-duplicidade. No account-based, o risco clássico é o mesmo número ser editado por duas operações concorrentes — o crédito aplicado duas vezes, o débito perdido — e a defesa são locks, serialização e idempotência: mecanismos corretos, mas externos ao modelo de dados, que precisam ser implementados certo em cada caminho de escrita. No token-based, o objeto é único e é consumido exatamente uma vez. Duas transações que tentem gastar o mesmo objeto não podem ambas ser válidas: a validade da segunda exige um objeto que a primeira já removeu do conjunto. O gasto duplo deixa de ser uma condição de corrida a administrar e vira uma impossibilidade da representação.

O resultado é que nenhuma premissa da contabilidade bancária se perde na troca de modelo. Partidas dobradas, conservação, não-duplicidade, trilha de auditoria: todas continuam valendo — cumpridas num grão mais fino, objeto a objeto, transição a transição, e verificadas antes de o lançamento existir, não depois.

A ressalva necessária

Duas honestidades para fechar. Primeiro: a distinção entre os dois modelos não é invenção nossa — é vocabulário padrão da literatura de CBDC e da economia de pagamentos ([1], [2]), e a contabilidade que resulta do modelo token-based é, em reais, a mesma contabilidade que o auditor já conhece, com o grão mais fino. Segundo: derivar o saldo em vez de armazená-lo não é gratuito. Somar objetos no momento da pergunta pede índices e projeções bem construídos, e um sistema real mantém visões materializadas para responder rápido. A diferença de arquitetura é que essas visões são caches deriváveis e reconstruíveis a partir dos objetos — nunca a fonte da verdade que precise ser editada quando o mundo muda.