canna-br | Blog

Como modelamos um ledger sem especulação usando Event Sourcing

Wed, 10 Jun 2026 00:00:00 GMT

O canna-br precisava de um ledger desde o primeiro dia. Não por moda, não por ser “web3” — mas porque o problema que o sistema resolve exige rastreabilidade contábil imutável por obrigação legal.

Quando a ANVISA fiscaliza uma associação de cannabis medicinal, ela quer saber: quem recebeu o quê, quando, de qual lote, com base em qual prescrição, com saldo disponível no momento da dispensação. Isso não é relatório gerencial. É trilha de auditoria que precisa sobreviver a questionamento judicial.

A resposta óbvia seria um banco de dados relacional com tabelas de saldo. O problema é que tabelas de saldo mutáveis não respondem a uma pergunta simples: o que aconteceu para o saldo chegar aqui? Você pode ter o número certo e não ter a história. Em ambiente regulatório, a história é o que importa.

O padrão

A solução é Event Sourcing: em vez de salvar o estado atual, você salva cada fato que aconteceu. O estado é derivado. A história é imutável.

No canna-br, cada operação emite um ou mais eventos de domínio. Uma dispensação gera DispensationRecorded e LotQuantityDeducted — dois fatos atômicos, imutáveis, com timestamp e metadados. Nenhum UPDATE em tabela de saldo. Nenhuma linha desaparece. A projeção (o saldo que você vê na tela) é computada a partir do stream de eventos, e pode ser recomputada a qualquer momento para auditoria.

O engine de eventos é o NATS JetStream, configurado como append-only com retenção ilimitada (LimitsPolicy sem MaxAge). Duas armadilhas que aprendemos cedo:

InterestPolicy apaga mensagens sem consumer ativo — destrói o histórico exatamente quando você precisa dele
WorkQueuePolicy apaga no primeiro ack — idem

A configuração correta é LimitsPolicy sem teto. O histórico nunca some.

Por que não blockchain

A pergunta inevitável é: se você quer imutabilidade, por que não blockchain?

A resposta está em quatro eixos:

Implementação. Blockchain permissionada exige governança de nós, gestão de chaves, protocolo de consenso. Isso não está na capacidade operacional de uma associação de pacientes com três voluntários.

LGPD. Dados de saúde em cadeia pública — ou mesmo permissionada compartilhada — criam problema sério de conformidade. O RGPD europeu já tem decisões sobre isso; a tendência LGPD aponta na mesma direção. Crypto-deletion (Art. 18 IV LGPD) em blockchain é tecnicamente inviável sem arquitetura específica.

Superfície regulatória. “Blockchain” no contexto de cannabis no Brasil é lido como “cripto” por qualquer interlocutor regulatório. Isso cria ruído que não ajuda.

Custo-benefício. O que a blockchain oferece (imutabilidade, auditoria distribuída) o event log local já oferece com menos complexidade. A diferença é o componente de confiança distribuída — relevante quando há múltiplas partes não confiáveis. Internamente a uma associação, esse requisito não existe.

A camada econômica

Event sourcing resolve o histórico operacional. Mas associações precisam também de posições econômicas: saldo interno, cotas de compra coletiva, garantias, governança.

Para isso existe o token-ledger — mas a palavra “token” aqui é técnica, não comercial. O que o usuário vê é “saldo”, “cota”, “garantia”, “nível”. O backend usa tipos contábeis (CREDIT, PO_SHARE, ESCROW, REPUTATION_SBT, GOVERNANCE_RIGHT) para manter as regras de transferibilidade, idempotência e segregação corretas.

A lógica de dupla-entrada (débito, crédito, saldo que nunca fica negativo) é delegada a um engine de ledger pronto — TigerBeetle ou Formance. Não se reimplementa contabilidade de dupla-entrada. As armadilhas são conhecidas: idempotência em falha parcial, atomicidade cross-conta, overflow de ponto flutuante. Esses problemas já foram resolvidos por quem construiu esses engines.

O que o auditor vê

Quando a fiscalização chega, o sistema pode reproduzir o estado da associação em qualquer ponto no tempo. Cada dispensação tem um hash de checkpoint que vincula o evento ao snapshot do ledger naquele momento. O auditor pode verificar que nenhum evento foi retroativamente modificado.

Isso não é feature de UX. É o produto. O sistema existe para tornar a operação de uma associação verificável por uma autoridade externa.

Arquitetura em camadas

Core AGPL (Emmett — TypeScript)
    ↓ Domain Events
NATS JetStream — log imutável, fonte da verdade
    ↓
Token-Ledger Service (TigerBeetle ou Formance)
    ↓
Projeções SurrealDB — saldo, cotas, extrato
    ↓
Projection API → Interface

O frontend nunca acessa o JetStream diretamente. O usuário nunca vê evento bruto. A interface consome projeções — leituras desnormalizadas construídas para display. Quando a projeção está errada, você reprocessa o stream. O stream nunca muda.

O que fica travado intencionalmente

O ledger da v0.1 não tem tipos financeiros. LOAN_POOL_SHARE, RECEIVABLE_SHARE, YIELD_RIGHT, PLANTING_INVESTMENT_POSITION — todos bloqueados. Não porque a arquitetura não suporte, mas porque produto financeiro exige estrutura regulada que ainda não existe. CVM classifica criptoativos como valores mobiliários pela substância econômica, não pelo nome. Errar aqui não é bug técnico.

A arquitetura foi desenhada para que essa barreira seja um controle, não uma limitação acidental. Cada tipo econômico tem um flag regulated_flag e regras de transferibilidade explícitas. Nada sai bloqueado por esquecimento; sai bloqueado por decisão.

A documentação técnica completa está em Token-Ledger (arquitetura) e Token-Ledger v0.1.

Se você quer construir essa infraestrutura junto ou conectar sua associação como piloto, entre em contato. O projeto é aberto, AGPL-3.0, e o código está em construção pública.

Por que AGPL e não MIT para infraestrutura de compliance

Wed, 10 Jun 2026 00:00:00 GMT

Todo projeto OSS enfrenta a mesma conversa em algum momento: “por que não MIT? é mais simples, mais adotado, menos polêmico.”

Para a maioria dos projetos, MIT é uma escolha razoável. Para o canna-br, seria um erro que destrói o argumento de venda mais forte do produto.

Este post explica a lógica da licença — para contribuidores, para associações que vão rodar o sistema, e para quem pensa em fazer fork.

O argumento central

Associações de cannabis medicinal operam em zona cinzenta regulatória. O maior risco operacional que uma diretoria carrega não é funcional — é perda de controle sobre dados sensíveis de saúde dos membros.

Um sistema fechado, mesmo que auditado por terceiros, não oferece garantia verificável. A diretoria precisa confiar na palavra do fornecedor. Se o fornecedor muda de dono, muda de política, vai à falência ou é pressionado por alguma autoridade — a associação não tem visibilidade.

AGPL-3.0 transforma esse argumento em diferencial concreto:

“Você pode ver cada linha de código que processa os dados dos seus membros. Qualquer advogado da associação pode revisar. Qualquer contribuidor pode auditar. Nenhum SaaS fechado consegue oferecer isso.”

Esse argumento só funciona com AGPL. Com MIT, funciona na teoria mas não na prática — porque MIT permite que qualquer fork feche o código e rode como SaaS proprietário, sem obrigação de publicar modificações.

O limite do AGPL: hosting parasita

AGPL protege de quem modifica e hospeda sem publicar o código. Não protege de quem hospeda sem modificar.

O risco real do canna-br não é um hyperscaler. É a consultoria local que pega o código, hospeda para cinco associações a R$ 500/mês e nunca contribui de volta — capturando valor sem pagar o custo da plataforma. Esse caso está fora do escopo de proteção do AGPL puro.

Por isso adotamos o modelo Metabase: AGPL + licença comercial obrigatória via CLA para os casos de hosting gerenciado de terceiros, embedding em soluções fechadas e integrações com certeza jurídica de obra derivada. O CLA é o instrumento que fecha esse ciclo sem abrir mão do reconhecimento OSI nem do trust moat de auditabilidade. Detalhes em Modelo OSS.

Sujeito a revisão jurídica antes de vigorar.

Por que não BUSL

Business Source License é a alternativa favorita de projetos que querem “parecer OSS” sem ser OSS.

BUSL torna o código disponível com restrições comerciais por um período (geralmente 4 anos), depois converte para licença mais permissiva. O problema é que advogados de associação não vão aprovar código com licença restritiva como base do sistema de saúde dos membros. “Disponível mas não open source” é a pior posição possível: perde os benefícios de auditabilidade real sem ganhar nenhuma proteção regulatória.

Se o argumento comercial central é auditabilidade, BUSL o destrói.

Por que não Open-Core

Open-core (núcleo gratuito, features premium pagas) funciona quando o comprador tem budget e incentivo para pagar por funcionalidades adicionais.

O perfil das associações de cannabis brasileiras não tem esse padrão:

Budget apertado — toda receita vai para custo operacional do produto cannabis
Decisão coletiva — a diretoria não vai aprovar upgrade para “tier Enterprise” em reunião
Compliance é obrigação legal, não feature diferenciadora — não existe “Premium SNGPC” ou “LGPD Pro”

Open-core funciona com buyer corporativo que tem linha de aprovação de software e budget dedicado. Associação civil sem fins lucrativos não é esse perfil.

A fronteira AGPL/Comercial na prática

AGPL-3.0 + CLA (Contributor License Agreement) é o modelo que permite que o canna-br tenha um negócio sustentável sem violar a lógica OSS.

A fronteira funciona assim:

Core AGPL — tudo que é o produto:

Cadastro de associação, membros, prescrições
Rastreabilidade seed-to-dispensação
Dispensação, controle de cotas, estoque
RBAC, logs operacionais
LGPD básico, SNGPC, relatórios
APIs públicas, eventos de domínio, conectores MCP básicos
Ledger técnico interno

Comercial (serviço externo, não modificação fechada):

Hosting gerenciado, backups, observabilidade, SLA
Suporte e implantação
Risk engine, cobrança, conciliação financeira
Auditoria especializada, BI executivo
Marketplace de fornecedores
Agentes MCP financeiro/compliance avançado

A linha jurídica é clara: modificação do core AGPL rodando via rede exige publicação do código correspondente. Serviço separado que consome API ou eventos pode ser comercial fechado. Operação, hospedagem, suporte e auditoria são serviços — não precisam abrir playbook interno.

Isso significa que a InfraCo pode cobrar por managed hosting, suporte e serviços complementares sem violar AGPL. O código core continua aberto. Qualquer associação pode self-hospedar sem pagar nada além de infraestrutura.

O que o CLA permite

CLA (Contributor License Agreement) é o mecanismo que permite dual-licensing. Quando você contribui para o canna-br e assina o CLA, você mantém seu copyright — mas concede à InfraCo o direito de usar sua contribuição em contextos comerciais (como o managed hosting).

Isso é o mesmo modelo do Plausible, Bitwarden e GitLab CE. Não é incomum, mas precisa estar explícito antes de qualquer contribuição.

O que o CLA não permite: fechar o código core. A InfraCo não pode pegar contribuições da comunidade e distribuí-las em versão proprietária sem publicar o fonte.

Trust moat em dados sensíveis

O padrão de crescimento baseado em auditabilidade está validado em outros setores:

Bitwarden cresceu como alternativa auditável ao LastPass. Cofre de senhas é exatamente o perfil de “dados sensíveis onde confiança não pode ser prometida, só demonstrada”
GitLab construiu crescimento enterprise com “você pode ver tudo, inclusive o código do GitLab”
Sentry tem ~90% dos usuários em self-host gratuito — o modelo de negócio funciona porque a confiança gerada pela transparência converte quando a escala cresce

Para dados de saúde em zona cinzenta regulatória, o trust moat é mais forte ainda. A diretoria da associação é pessoalmente responsável por um vazamento de dados de saúde. Usar um sistema auditável reduz esse risco pessoal de forma demonstrável.

Uma armadilha clássica: o modelo professional services

OpenMRS e Bahmni são sistemas OSS de saúde bem-sucedidos tecnicamente que foram capturados pelo modelo de consultoria:

Revenue veio majoritariamente de implementação e customizações
A equipe core virou basicamente consultoria disfarçada de produto
Escalabilidade zero: crescimento de receita = crescimento linear de pessoas

O canna-br tem um hard limit explícito: máximo 20% da receita de services. Qualquer serviço contratado (migração, treinamento, customização) tem um cronograma de eliminação via documentação e automação.

Se o modelo de negócio depende de manter o cliente dependente de serviços, AGPL não resolve nada — o software pode ser aberto mas o conhecimento operacional fica trancado. O modelo certo é: o cliente cresce em autonomia ao longo do tempo, e a InfraCo cresce em escala, não em horas.

Como contribuir

O repositório está em estruturação (organização dedicada prevista para v0.3, jul/2026). Enquanto isso, o desenvolvimento acontece em repositório de trabalho aberto.

Para contribuir:

Leia os ADRs antes de propor mudanças de arquitetura — as decisões técnicas têm contexto regulatório que não é óbvio
Qualquer contribuição ao core precisa respeitar AGPL-3.0
O CLA será apresentado antes do merge — é necessário para o modelo de negócio funcionar
Issues abertas aparecem no roadmap público

Se você quer discutir a licença, o modelo de negócio ou como o canna-br pode se encaixar num projeto que você tem, escreve direto.

E se sua associação quer fazer parte do piloto — usar o sistema desde o início e ajudar a moldar o produto —, leia sobre o piloto e entre em contato.

RDC 1.014/2026 na prática: o que muda para associações de cannabis

Wed, 10 Jun 2026 00:00:00 GMT

Aviso legal: este post é informativo e não substitui orientação jurídica. Cada associação tem uma situação específica. Consulte advogado especializado antes de tomar decisões com base neste conteúdo.

Por quase vinte anos, associações de cannabis medicinal no Brasil operaram sob um regime jurídico improvisado: Habeas Corpus coletivo concedido pelo judiciário local, renovado periodicamente, sem uniformidade nacional e sem fiscalização administrativa clara.

Isso mudou com a RDC 1.014/2026.

O que é a RDC 1.014

A Resolução da Diretoria Colegiada 1.014/2026 da ANVISA criou o primeiro “sandbox regulatório” formal para associações de pacientes de cannabis medicinal no Brasil. Vigência: 4 de agosto de 2026.

O que ela faz, na prática:

Cria um regime de autorização administrativa para associações aprovadas no sandbox
Transfere a fiscalização primária do judiciário para a ANVISA
Estabelece um conjunto de obrigações operacionais que as associações precisam cumprir para manter a autorização

Antes da RDC, a proteção era judicial — cada associação negociava seu HC com o judiciário local. Com a RDC, existe um caminho administrativo, mas ele vem com requisitos concretos.

O que fica igual

Associações que não solicitarem o sandbox continuam no regime anterior: HC coletivo, risco penal sobre diretores, fiscalização indireta. A RDC não revoga o regime anterior — ela cria uma alternativa. Para quem está no sandbox, a lógica muda completamente.

Também não muda o seguinte: cannabis continua sendo substância controlada. A regulação autoriza operação dentro de regras específicas; não descriminaliza em sentido amplo.

O que muda para quem entra no sandbox

Fiscalização direta. A ANVISA passa a ser a autoridade fiscalizadora. Isso significa visitas de inspeção, auditorias documentais e a possibilidade de suspensão ou cassação da autorização por não conformidade.

Proibições absolutas que precisam estar no sistema:

Proibição	O que significa operacionalmente
Comercialização vedada	Nenhuma transação financeira pelo produto cannabis em si
Só para membros cadastrados	Dispensação restrita ao quadro associativo ativo
Sem fins lucrativos	Toda receita vai para operação e pesquisa; proibida distribuição de resultado
Publicidade proibida	Sem material de divulgação de produtos ou serviços

Rastreabilidade obrigatória. A RDC exige que toda dispensação, transferência e evento de produto seja registrado e verificável. Isso inclui a cadeia completa: de onde veio o insumo, qual lote, qual COA (Certificate of Analysis), quem recebeu, em qual quantidade, com base em qual prescrição vigente.

SNGPC. O Sistema Nacional de Gerenciamento de Produtos Controlados — hoje usado por farmácias para registrar dispensação de substâncias controladas — passa a ser requisito para associações no sandbox. As associações precisam enviar registros periódicos de dispensação no formato ANVISA.

RBAC com segregação de funções. A RDC implica que diferentes papéis dentro da associação (diretor, responsável técnico farmacêutico, cultivador, dispensador) precisam estar claramente definidos no sistema, com log de quem fez o quê. Não basta separar na prática — precisa estar no registro.

LGPD aplicada a dados sensíveis de saúde. Dados dos membros (diagnóstico, prescrição, dosagem, histórico de uso) são dados sensíveis nos termos da LGPD (Art. 5 II). Isso exige: consentimento explícito, controle de acesso restrito, possibilidade de exclusão efetiva (Art. 18 IV), e — para quem usa sistema externo — contratos de processamento com o fornecedor.

Por que planilha não resolve mais

Associações que operam com Google Sheets, WhatsApp e planilhas paralelas estão em risco crescente por uma razão simples: esses sistemas não produzem trilha de auditoria verificável.

Quando o fiscal ANVISA pede o histórico de dispensações do lote LT-001, a resposta não pode ser “deixa eu procurar nos registros”. Precisa ser: aqui está o evento com timestamp, hash, responsável, quantidade, vinculo à prescrição do paciente, dedução do estoque correspondente.

Planilha não tem idempotência. Pode ser editada retroativamente. Não tem hash de verificação. Não tem RBAC. Em auditoria, a ausência dessas propriedades é um problema que nenhuma justificativa resolve.

O que precisa estar no lugar

Para uma associação que quer entrar no sandbox ou se preparar para a fiscalização administrativa, o checklist operacional mínimo é:

Cadastro de membros com consentimento LGPD documentado, dados de saúde segregados
Rastreabilidade de lotes desde o insumo até a dispensação final
Registro de dispensações com vinculo a prescrição vigente, quantidade, lote, dispensador
Controle de cotas — cada membro tem um limite prescrito; o sistema precisa validar isso antes de registrar a dispensação
SNGPC — capacidade de gerar e enviar relatórios no formato ANVISA
Audit trail imutável — histórico que não pode ser editado retroativamente
RBAC — cada usuário só faz o que seu papel permite; tudo logado

Isso é exatamente o que o canna-br entrega, construído com a RDC como referência desde o início.

Responsabilidade pessoal dos diretores

Um ponto que não aparece no texto da resolução mas que qualquer advogado especializado vai mencionar: a RDC não elimina a responsabilidade pessoal dos diretores da associação.

Em caso de vazamento de dados de saúde dos membros, a LGPD impõe responsabilidade civil e, em alguns casos, criminal. Em caso de irregularidade operacional grave, o HC coletivo pode ser contestado. A autorização administrativa do sandbox não é escudo para qualquer tipo de irregularidade.

Usar um sistema que pode ser auditado publicamente — onde o código que processa os dados dos membros é aberto e verificável — é uma forma concreta de reduzir esse risco pessoal. A diretoria pode mostrar, para qualquer advogado ou auditor, exatamente o que o sistema faz com os dados.

O que o canna-br está construindo agora

O sistema está em v0.1.0 com 154 testes passando. Os módulos de dispensação, rastreabilidade de lotes e controle de cotas estão implementados. O SNGPC está em mock — o schema XSD específico para associações ainda não foi publicado pela ANVISA, mas a arquitetura está pronta para integração quando o documento sair.

O piloto está sendo estruturado com associações que queiram construir esse padrão desde o início — não adaptar um sistema genérico depois que a fiscalização chegar.

Se sua associação está avaliando como se preparar para o novo regime regulatório, entre em contato ou veja a documentação técnica de compliance em /build/compliance/.