VoltchainHub — Whitepaper v0.1

Abstract

1. O Problema

1.1 Energia Centralizada: Ineficiência e Custo

O modelo elétrico brasileiro é estruturalmente centralizador. Geração em usinas distantes, transmissão em linhas de alta tensão com perdas médias de 14,9% (ANEEL, 2024), distribuição por concessionárias regionais com poder de monopólio legal — e o consumidor final pagando a conta de toda essa cadeia.

A tarifa residencial média nacional ultrapassou R$ 0,90/kWh em 2025. Nesse valor estão embutidos: encargos setoriais (CDE, PROINFA, EER), perdas técnicas, perdas comerciais (furtos, inadimplência), custos de manutenção de infraestrutura do século XX e margem das distribuidoras. O brasileiro paga uma das tarifas mais caras do mundo em proporção à renda per capita.

O modelo funciona como um funil: energia entra no topo (grandes geradoras), percorre milhares de quilômetros, e chega ao consumidor final tributada, perdida e cara. Não há mecanismo de mercado local. Vizinhos com painéis solares não podem vender energia diretamente uns aos outros.

1.2 O Prosumidor Brasileiro Sem Infraestrutura

A ANEEL REN 1000/2021 criou o marco legal da geração distribuída no Brasil. Em 2025, o país já ultrapassava 5 milhões de unidades de micro e minigeração distribuída, majoritariamente solar fotovoltaica. A projeção é alcançar 20 milhões de prosumidores até 2030.

O prosumidor brasileiro investe R$ 15.000–50.000 em um sistema solar, gera excedente de energia durante o dia e recebe em troca créditos de energia na distribuidora local — créditos que se expiram em 60 meses e são compensados em tarifas cheias de distribuição. Não há mercado real. Não há precificação dinâmica. Não há peer-to-peer.

O resultado: prosumidores que poderiam vender energia a R$ 0,05–0,15/kWh para vizinhos são obrigados a "ceder" essa energia para a distribuidora a custo zero, que a revende com toda a sua estrutura de custos.

1.3 Gap Tecnológico: Standards Europeus Inexplorados no Brasil

A Europa resolveu boa parte desse problema. O protocolo S2 (IEC 62746-10-3) padroniza a comunicação entre dispositivos de energia e sistemas de controle. O OpenEMS conecta mais de 50 fabricantes de inversores, baterias e medidores. O PowerMatcher implementa mercados multi-agente de energia em tempo real.

Nenhum desses padrões foi adaptado ao contexto brasileiro. Não existe implementação nacional. Não existe protocolo open-source que una a infraestrutura de IoT com blockchain e com o marco regulatório da ANEEL.

Esse é o gap que VoltchainHub preenche.

2. A Visão: Luz Livre

2.1 Inspiração Tesla: Energia como Bem Comum

Nikola Tesla dedicou sua vida a uma ideia radical: energia deveria ser tão acessível quanto o ar. Seu projeto Wardenclyffe Tower foi destruído não por falha técnica, mas por resistência econômica — porque energia livre não tem dono, não tem monopólio, não tem tarifa.

VoltchainHub herda esse espírito. Não porque acreditamos em física impossível, mas porque acreditamos que a tecnologia de 2026 — blockchain, IoT, protocolos abertos — nos dá as ferramentas para criar o que Tesla imaginou: uma infraestrutura de energia que serve ao povo, não ao monopólio.

2.2 O Que "Energia Livre" Realmente Significa

"Energia livre" no contexto VoltchainHub não é violação da termodinâmica. É liberdade de mercado:

• Livre para gerar — qualquer pessoa pode instalar geração e participar do protocolo
• Livre para vender — sem intermediário obrigatório entre produtor e consumidor
• Livre para auditar — todo código, todo contrato, toda transação é pública e verificável
• Livre de rent-seeking — o protocolo não extrai valor, apenas facilita a troca

O preço de equilíbrio no mercado P2P VoltchainHub converge para o custo marginal real de produção — próximo de zero para solar durante o dia. Esse é o "livre" que importa.

2.3 Princípios do Protocolo

1. Abertura total — Apache 2.0, nenhum componente proprietário obrigatório
2. Soberania do dado — medições ficam no dispositivo do prosumidor; blockchain registra apenas hashes e saldos
3. Composabilidade — cada camada pode ser substituída; o protocolo não impõe lock-in
4. Neutralidade de rede — o protocolo não favorece nenhum prosumidor, região ou tamanho de instalação
5. Conformidade regulatória — opera dentro da ANEEL REN 1000, não contra ela
6. Progressividade — começa simples (créditos tokenizados), evolui para mercado totalmente autônomo

3. Arquitetura Técnica

3.1 Visão Geral das Camadas

┌─────────────────────────────────────────────────────────────┐
│  FRONTEND  │  Dashboard Web (React) + App Mobile           │
├─────────────────────────────────────────────────────────────┤
│  BLOCKCHAIN│  Polygon PoS — LuzToken, DeviceRegistry,      │
│            │  EnergyOracle, EnergyVault                    │
├─────────────────────────────────────────────────────────────┤
│  PROTOCOLO │  S2 Protocol (CEM↔RM) + SHIP (TLS over Wi-Fi) │
├─────────────────────────────────────────────────────────────┤
│  EDGE      │  OpenEMS (Java) + PowerMatcher (market agent) │
├─────────────────────────────────────────────────────────────┤
│  HARDWARE  │  ESP32-S3 + PLC HomePlug AV + WPT local       │
└─────────────────────────────────────────────────────────────┘

Cada camada é independente e substituível. Um prosumidor pode participar do protocolo com apenas um medidor ESP32-S3 conectado ao inversor solar via Modbus.

3.2 Camada Hardware: ESP32-S3 + PLC + WPT

ESP32-S3 — O Nó de Medição

O ESP32-S3 é o coração do dispositivo VoltchainHub. Com núcleo Xtensa LX7 dual-core a 240 MHz, 8MB PSRAM e suporte a ARM TrustZone, é o microcontrolador mais capaz da família Espressif no segmento de custo (<$5 USD).

• Leitura de medidores via Modbus RTU/TCP (compatível com 90%+ dos inversores brasileiros)
• Assinatura criptográfica de leituras com ECDSA P-256 usando chave privada armazenada em eFuse + TrustZone
• Publicação de telemetria via MQTT over TLS
• Capacidade de operação offline com buffer de 72h (SPIFFS)

PLC HomePlug AV — Transmissão pela Rede Elétrica

O HomePlug AV utiliza a própria fiação elétrica como meio de transmissão. Eficiência de até 88%. Permite comunicação entre medidores sem infraestrutura adicional de rede — especialmente relevante para condomínios e microrredes industriais.

WPT — Transferência de Energia por Indução Ressonante

Para ambientes de curta distância (<5m), o protocolo suporta transferência de energia por acoplamento ressonante magnético, com eficiência de 72%.

3.3 Camada Edge: OpenEMS + PowerMatcher

OpenEMS — Sistema de Gestão Energética

OpenEMS é um framework Java open-source desenvolvido originalmente pela FENECON GmbH, compatível com 50+ fabricantes de inversores, baterias e medidores (Fronius, SMA, Huawei, BYD, Victron).

PowerMatcher — Mercado Multi-Agente

PowerMatcher implementa um algoritmo de market clearing descentralizado. Cada dispositivo de energia age como um agente autônomo que publica curvas de oferta/demanda. O concentrador calcula o preço de equilíbrio local a cada 5 minutos.

Ciclo de clearing:
  1. Cada agente publica bid (curva preço × quantidade)
  2. Auctioneer agrega bids de todos os agentes
  3. Preço de equilíbrio = interseção oferta/demanda
  4. Agentes recebem sinal de despacho
  5. Resultado é commitado no contrato EnergyVault

3.4 Camada Protocolo: S2 / SHIP

S2 Protocol (IEC 62746-10-3) define a interface entre o Customer Energy Manager (CEM) e o Resource Manager (RM). Implementado em Python (referência) e Rust (produção) no VoltchainHub.

Modelos de controle suportados:

• FRBC — Fill Rate Based Control (baterias e armazenamento)
• DDBC — Demand Driven Based Control (cargas flexíveis)
• PEBC — Power Envelope Based Control (geração solar)
• OMBC — Operation Mode Based Control (EVs e carregadores)

SHIP (Smart Home IP) provê a camada de transporte segura (TLS 1.3) para comunicação local entre dispositivos. Resolve o problema de discovery e autenticação em redes residenciais sem dependência de servidor central.

3.5 Camada Blockchain: Contratos Inteligentes

Rede: Polygon PoS  ·  Custo: <$0,001  ·  Finalidade: ~2s  ·  Framework: Hardhat + OpenZeppelin v5

3.6 Diagrama de Fluxo Completo

[Painel Solar] → [Inversor] → [ESP32-S3]
                                    │
                              Modbus RTU
                                    │
                              [OpenEMS Edge]
                                    │
                         S2 Protocol / SHIP
                                    │
                          [PowerMatcher Agent]
                                    │
                           5-min market clearing
                                    │
                    ┌───────────────┴───────────────┐
                    │                               │
              [Comprador]                     [Vendedor]
                    │                               │
              EnergyVault.lock()           LuzToken.mint()
                    │                               │
              [Entrega de energia]          [Confirma entrega]
                    │                               │
              EnergyVault.release()        LuzToken.transfer()
                    │
              [Saldo atualizado on-chain]

4. LuzToken — Modelo Econômico

4.1 Tokenomics (ERC-1155)

Padrão: ERC-1155 (multitoken). Permite que cada kWh carregue metadados de fonte (solar/eólico/bateria), timestamp e localização do gerador.

LuzToken não tem supply fixo. Tokens são mintados na medida em que energia é medida e verificada, e queimados quando energia é consumida.

100 kWh gerados e verificados
  └─ 100 kWh → LuzToken para o prosumidor vendedor
     (fees acontecem no marketplace, não no mint)

Token IDs são determinísticos:

tokenId = keccak256(deviceAddress, timestamp_slot, sourceType)

4.2 Ciclo de Vida de uma Transação Energética

1. GERAÇÃO
   Prosumidor A gera 10 kWh excedentes às 13h
   → ESP32-S3 mede, assina com ECDSA
   → OpenEMS envia leitura assinada ao EnergyOracle

2. VERIFICAÇÃO
   EnergyOracle valida assinatura + consistência histórica
   → Se válido: emite evento ReadingVerified
   → LuzToken.mint(prosumidorA, 9.9 kWh) // 1% fee retido

3. OFERTA
   PowerMatcher agent de A publica bid:
   "10 kWh disponíveis @ R$0,08/kWh"

4. MATCHING
   PowerMatcher clearing encontra comprador B
   Preço de equilíbrio: R$0,10/kWh

5. ESCROW
   EnergyVault.lock(comprador=B, vendedor=A, amount=5, price=0.10)

6. ENTREGA
   Energia flui fisicamente (rede distribuidora como carrier)
   Após 5 min, OpenEMS de B confirma recebimento

7. LIQUIDAÇÃO
   EnergyVault.release() → VoltMarketplace.settle()
   → 5 LuzToken transferidos A→B (e queimados pelo B)
   → SettlementRouter converte pagamento de B
     para a moeda preferida de A (swap via
     Uniswap v3 se necessário)
   → A recebe em USDC, BRZ, WBTC ou no token que escolheu

Tempo total do ciclo: ~7 minutos (5 min de ciclo PowerMatcher + ~2 min blockchain)

4.3 Precificação P2P via PowerMatcher

4.4 Sustentabilidade do Protocolo

Fonte de receita: 0,5% sobre o valor financeiro de cada transação, cobrado em stablecoin no VoltMarketplace. Isso é ~10× menor que cartão de crédito e ~3× menor que maquininha brasileira.

Destino do treasury:

• 60% → Desenvolvimento e manutenção do protocolo
• 25% → Grants para contribuidores open-source
• 15% → Fundo de emergência (bugs críticos, auditorias)

A partir da Fase 3, o treasury é controlado pela DAO. Antes disso, por multisig 3/5.

4.5 Payment Abstraction Layer

VoltchainHub não emite token de recompensa próprio. Prosumidores recebem pagamento na moeda de sua escolha, não em um token sintético cujo valor depende da saúde do próprio protocolo.

Por que essa decisão:

1. Reduz risco regulatório — VoltchainHub não cria ativo financeiro que a CVM possa classificar como valor mobiliário. LuzToken é recibo de commodity física (kWh); pagamento é em criptoativo de terceiros.
2. Liberdade do prosumidor — quem quer BRL-stable (BRZ, BRLA, cBRL) recebe BRL-stable; quem quer USD-stable (USDC/USDT/DAI) recebe; quem quer BTC ou ETH recebe. Protocolo é neutro quanto a moeda.
3. Adoção simplificada — onboarding para não-crypto vira "você recebe R$ na sua carteira" via BRZ/BRLA + off-ramp PIX, sem precisar entender tokenomics.
4. Composabilidade — outros protocolos podem integrar sem adotar token interno incompatível.

Comprador paga em X (ex.: BRZ)    Prosumidor prefere receber em Y (ex.: USDC)
         │                                            │
         ▼                                            │
┌──────────────────────────────────────────────┐      │
│  VoltMarketplace (contrato Solidity)         │      │
│  1. Recebe X do comprador                    │      │
│  2. Retém 0,5% fee em X → Treasury           │      │
│  3. SettlementRouter decide rota:            │      │
│     - Se X == Y: transferência direta        │      │
│     - Se X ≠ Y: swap via Uniswap v3 Polygon  │      │
│  4. Transfere Y ao prosumidor                │      │
│  5. Emite evento PaymentSettled              │      │
└──────────────────────────────────────────────┘      │
                                                      ▼
                                                 Y na wallet

Tempo típico de liquidação: ~2 minutos (1 bloco Polygon + confirmação do swap). Slippage protection: comprador define maxSlippageBps (padrão 50 = 0,5%); se o swap exigir slippage maior, a transação aborta e os fundos voltam ao comprador.

4.6 TokenRegistry — Lista de Moedas Suportadas

A whitelist de tokens aceitos é controlada pelo TokenRegistry (contrato separado, governável). Critério de inclusão:

• Liquidez mínima diária no Uniswap v3 Polygon: USD 50.000
• Contrato auditado publicamente (Certik, OpenZeppelin, Trail of Bits ou equivalente)
• Não estar em lista de sanções OFAC
• Não ser token rebase/deflacionário (incompatível com escrow)

Lista inicial (Fase 1, testnet Amoy):

4.7 Off-Ramp para Reais (BRL)

Prosumidor que escolhe receber em BRZ / BRLA / cBRL pode converter para PIX real via parceiros de off-ramp já existentes no ecossistema Polygon:

• Transfero — BRZ ↔ PIX, sem KYC até R$ 3.000/mês, KYC simples acima
• Ripio — BRLA ↔ PIX, KYC obrigatório
• Mercado Bitcoin — múltiplas stables ↔ PIX, KYC obrigatório

VoltchainHub não opera off-ramp próprio — integra os existentes. Isso isola completamente o protocolo de responsabilidade bancária/cambial.

5. Segurança e Confiança

5.1 Device Attestation (TrustZone + ECDSA)

• Camada 1 — Hardware Security: Chave privada ECDSA P-256 gerada durante provisionamento; armazenada em eFuse (não legível por software); TrustZone separa execução de assinatura
• Camada 2 — Attestation On-Chain: Durante registro, o dispositivo assina um challenge do contrato DeviceRegistry; nonce sequencial previne replay attacks
• Camada 3 — Validação Estatística: EnergyOracle mantém histórico de leituras; anomalias geram flag e revisão manual

5.2 Oracle Security Model

• Multi-oracle: Mínimo 3 oracles independentes para mint acima de 100 kWh
• Stake de operador: Operadores fazem stake em MATIC — comportamento malicioso resulta em slash
• Janela de contestação: 30 minutos após cada leitura
• Fallback: Oracle offline >15 min → ciclo de clearing pausado

5.3 Smart Contract Audit Approach

1. Análise estática automatizada — Slither, MythX
2. Testes de fuzzing — Echidna para invariantes críticos
3. Revisão de código por pares — mínimo 2 revisores externos
4. Audit profissional — mínimo 1 firma de auditoria reconhecida antes de Fase 3
5. Bug bounty público — programa ativo a partir da Fase 2

5.4 Regulatório: ANEEL REN 1000

Prosumidor A gera excedente
  → Injeta na rede da distribuidora (como sempre, conforme REN 1000)
  → Distribuidora credita kWh na conta
  → VoltchainHub tokeniza esse crédito como LuzToken
  → Prosumidor pode vender LuzToken para vizinhos
  → Vizinhos usam LuzToken para abater suas próprias faturas

6. Roadmap

Fase 1 — MVP Técnico (30 dias)

• Firmware ESP32-S3: leitura Modbus + assinatura ECDSA + MQTT
• Contratos Solidity: LuzToken, DeviceRegistry, EnergyOracle (testnet Polygon Mumbai)
• OpenEMS adapter: publicação de leituras para oracle
• PowerMatcher: instância local com 2 agentes simulados
• Dashboard básico: saldo LuzToken, histórico de transações

Critério de sucesso: Transação end-to-end simulada com hardware real

Fase 2 — Piloto 10 Prosumidores MG (90 dias)

• Deploy em 10 residências na Região Metropolitana de BH
• Integração com 3 modelos de inversores populares (Fronius, Growatt, Deye)
• Contratos em Polygon mainnet com valor real
• Análise estatística de fraude em produção
• Relatório técnico público de resultados

Critério de sucesso: ≥ 500 kWh transacionados P2P com latência <10 min

Fase 3 — Protocolo Público + DAO (180 dias)

• Auditoria de segurança por firma externa
• Deploy de governança Aragon OSx
• SDK público (TypeScript + Python) para integradores
• Documentação completa (pt-BR + en)
• Programa de grants para contribuidores

Critério de sucesso: ≥ 3 integradores independentes usando o protocolo

Fase 4 — 1000 Nós Ativos (1 ano)

• 1000+ dispositivos registrados on-chain
• Expansão para 5 estados brasileiros
• Parceria com pelo menos 1 distribuidora piloto
• Mercado de certificados de energia renovável sobre LuzToken
• Bridge para outros protocolos de energia (Energy Web Chain)

Critério de sucesso: ≥ 100.000 kWh mensais transacionados no protocolo

7. Diferenciais Competitivos

vs. Energia Centralizada

vs. Outros Protocolos Blockchain de Energia

8. Governança

8.1 Open-Source (Apache 2.0)

Todo código do VoltchainHub é e sempre será Apache 2.0 — firmware, contratos, adapters e SDKs. Nenhuma funcionalidade core será proprietária.

8.2 Fase 1-2: Multisig Gnosis Safe 3/5

Treasury e upgrades de contratos são controlados por um multisig Gnosis Safe 3-de-5 com signatários públicos. Todas as transações do treasury são visíveis on-chain.

8.3 Fase 3: DAO com Aragon OSx

• Token de governança: LuzToken acumulado de participação confere direito de voto
• Quorum: 10% para propostas regulares; 30% para upgrades críticos
• Timelock: 48h entre aprovação e execução de qualquer mudança de contrato
• Veto: Multisig fundador retém veto de emergência por 12 meses pós-DAO (sunset automático)

8.4 Como Contribuir

• Código: PRs no GitHub — issues marcadas como good-first-issue
• Hardware: Testar com novos inversores/medidores e contribuir adapters OpenEMS
• Pesquisa: Simulações de mercado, otimização de algoritmos PowerMatcher
• Documentação: Guias de instalação, tradução, casos de uso regionais
• Auditoria: Revisão de contratos, análise de segurança, fuzzing

9. Equipe e Contexto

VoltchainHub é um projeto pessoal iniciado por Vinicius, engenheiro e desenvolvedor com foco em soberania tecnológica, descentralização e impacto social. O protocolo nasce da convicção de que tecnologia deve servir às pessoas, não a monopólios.

O protocolo não pertence a uma empresa. Pertence a uma visão: tecnologia como instrumento de libertação econômica.

Buscamos:

• Engenheiros de firmware com experiência em ESP32 e protocolos de energia
• Desenvolvedores Solidity com foco em segurança
• Especialistas em OpenEMS/PowerMatcher
• Advogados de energia familiarizados com regulação ANEEL
• Prosumidores dispostos a ser piloto na Fase 2

Se você acredita que energia é um direito, não um privilégio de quem pode pagar R$ 0,90/kWh — você já é parte disso.

10. Conclusão

O Brasil está na encruzilhada energética. De um lado, uma infraestrutura centralizada do século XX, cara e ineficiente. Do outro, 5 milhões de prosumidores gerando energia limpa, travados em um sistema que não permite a troca direta entre vizinhos.

VoltchainHub é a infraestrutura que falta. Não é uma startup. Não é um produto. É um protocolo aberto — como o HTTP é para a web, como o Bitcoin é para o dinheiro, o VoltchainHub aspira ser para a energia distribuída brasileira.

A tecnologia existe. O marco regulatório existe. O mercado existe. O que faltava era alguém colocar as peças juntas, de forma aberta, para que qualquer pessoa possa usar, auditar e melhorar.

A rede começa com o primeiro nó. Seja o primeiro.

• GitHub: github.com/viniciusvj/voltchainhub
• Comunidade: Discord VoltchainHub (em breve)
• Para pilotos Fase 2: (em breve)

Apêndice A — Contratos Inteligentes (Interfaces Solidity)

// SPDX-License-Identifier: Apache-2.0
pragma solidity ^0.8.20;

// ============================================================
// LuzToken — ERC-1155 Multitoken
// ============================================================
interface ILuzToken {
    function mint(
        address to,
        uint256 tokenId,
        uint256 amount,
        bytes calldata data
    ) external;

    function burn(address from, uint256 tokenId, uint256 amount) external;

    function balanceOf(address account, uint256 id) external view returns (uint256);

    function encodeTokenId(
        address device,
        uint32 slot,      // slot de 5 minutos desde epoch
        uint8 sourceType  // 0=solar, 1=eolico, 2=bateria, 3=rede
    ) external pure returns (uint256);

    event TokenMinted(address indexed to, uint256 indexed tokenId, uint256 amount);
    event TokenBurned(address indexed from, uint256 indexed tokenId, uint256 amount);
}

// ============================================================
// DeviceRegistry — Registro e Attestation de Dispositivos
// ============================================================
interface IDeviceRegistry {
    struct Device {
        address owner;
        bytes32 publicKeyX;
        bytes32 publicKeyY;
        uint64  registeredAt;
        bool    active;
        string  metadata;
    }

    function registerDevice(
        bytes32 deviceId,
        bytes32 pubKeyX,
        bytes32 pubKeyY,
        bytes calldata attestationSig,
        string calldata metadata
    ) external;

    function verifyReading(
        bytes32 deviceId,
        bytes32 readingHash,
        bytes calldata signature
    ) external view returns (bool valid);

    function deactivateDevice(bytes32 deviceId, string calldata reason) external;
    function getDevice(bytes32 deviceId) external view returns (Device memory);

    event DeviceRegistered(bytes32 indexed deviceId, address indexed owner);
    event DeviceDeactivated(bytes32 indexed deviceId, string reason);
}

// ============================================================
// EnergyOracle — Ponte entre medição física e blockchain
// ============================================================
interface IEnergyOracle {
    struct Reading {
        bytes32 deviceId;
        uint256 wattHours;
        uint64  timestamp;
        uint32  slot;
        bytes   signature;
    }

    function submitReading(Reading calldata reading) external;
    function confirmReading(bytes32 readingId, bytes calldata oracleSig) external;
    function contestReading(bytes32 readingId, bytes calldata evidence) external;

    event ReadingSubmitted(bytes32 indexed readingId, bytes32 indexed deviceId, uint256 wh);
    event ReadingConfirmed(bytes32 indexed readingId);
    event ReadingContested(bytes32 indexed readingId, address contester);
}

// ============================================================
// EnergyVault — Escrow para transações P2P
// ============================================================
interface IEnergyVault {
    enum TradeStatus { Pending, Locked, Delivered, Settled, Expired, Disputed }

    struct Trade {
        address seller;
        address buyer;
        uint256 tokenId;
        uint256 energyAmount;
        uint256 pricePerKwh;
        uint64  deadline;
        TradeStatus status;
    }

    function lockTrade(
        address seller,
        uint256 tokenId,
        uint256 energyAmount,
        uint256 pricePerKwh,
        uint64 deliveryDeadline
    ) external payable returns (bytes32 tradeId);

    function confirmDelivery(bytes32 tradeId) external;
    function settleTrade(bytes32 tradeId) external;
    function disputeTrade(bytes32 tradeId, string calldata reason) external;
    function expireTrade(bytes32 tradeId) external;
    function getTrade(bytes32 tradeId) external view returns (Trade memory);

    event TradeLocked(bytes32 indexed tradeId, address seller, address buyer, uint256 amount);
    event TradeSettled(bytes32 indexed tradeId, uint256 energyWh, uint256 valueMatic);
    event TradeDisputed(bytes32 indexed tradeId, string reason);
}

Apêndice B — Stack Tecnológica Completa

Apêndice C — Referências e Projetos Base

Regulatório Brasil

• ANEEL REN 1000/2021 — Marco legal de geração distribuída
• ANEEL REN 1059/2023 — Atualização sobre sistemas de armazenamento
• MME PDE 2031 — Plano Decenal de Expansão de Energia

Padrões Técnicos

• IEC 62746-10-3 (S2 Protocol)
• IEEE 1901 (HomePlug AV)
• IEC 61968/61970 (CIM)

Projetos Open-Source Base

• OpenEMS
• PowerMatcher
• S2 Protocol Reference
• Hardhat
• OpenZeppelin Contracts

VoltchainHub Whitepaper v0.1 — Março 2026
Licença Apache 2.0 — Livre para uso, modificação e distribuição com atribuição
"A rede começa com o primeiro nó."