Haon: trabalho útil como prova de bloco.

01 · AbstractTrabalho útil em vez de hash cego.

A Haon é uma blockchain Layer 1 desenhada para que cada bloco selado represente trabalho físico real — entregas de comida, transporte de pessoas, encomendas — em vez de poder de cálculo gasto em puzzles arbitrários. O substrato económico da rede é o Proof of Delivery (PoD): um objeto criptográfico de ~357 B contendo três assinaturas SECP256k1 (driver, cliente, comerciante), células H3 do trajeto e HMAC do hash GPS.

PoW SHA-256d sobre header de 80 B sela cada bloco como camada de imutabilidade. PoS com slashing automático filtra atores económicos. Uma malha LoRa em 868 MHz mantém a rede operacional mesmo na ausência de internet. Governança tripartida — operacional, técnica, económica — separa três populações disjuntas para que a captura de duas câmaras seja proibitivamente cara.

Plataformas tradicionais convergem para extracção: o algoritmo opacifica, a tarifa decai, o trabalhador é eventualmente substituído. A Haon inverte a polaridade: o trabalhador deixa de ser custo a optimizar e passa a ser nó da rede que valida o seu próprio trabalho.

02 · O problemaPlataformas extraem. Redes deviam distribuir.

Toda plataforma centralizada de delivery, ride-hailing ou logística cresce ao longo de um eixo previsível: aumenta volume, aumenta custos operacionais, e o único caminho para defender margem é baixar a tarifa de quem está na rua. Em paralelo, investem em IA e robotização para um dia eliminar o trabalhador. O modelo é estruturalmente extractivo.

Soluções existentes têm três limitações fatais quando aplicadas a logística:

• Custo de transação. L1 generalistas (Ethereum) têm fees impagáveis em pico de mil entregas/min; L2s introduzem dependência de sequencer centralizado.
• Modelo de prova. Não existe primitivo nativo para validar entregas físicas com geofence, multi-sig e RSSI. Implementar via smart contract custa gas imprevisível.
• Resiliência. Toda a infraestrutura assume internet permanente. Apagão, censura ou zona rural derrubam o serviço.

03 · ArquiteturaQuatro camadas em cima de Go.

A Haon assenta em quatro camadas verticais, cada uma com responsabilidades disjuntas e contratos bem definidos:

┌──────────────────────────────────────────────────────┐
│  L4 · Apps (Flutter)                                  │
│       Driver · Cliente · Restaurante                  │
├──────────────────────────────────────────────────────┤
│  L3 · API HTTP/gRPC + Câmaras de governança         │
│       proposta · voto · execução                     │
├──────────────────────────────────────────────────────┤
│  L2 · Consenso                                        │
│       PoD (workload) + PoW (sela) + PoS (filtra)     │
├──────────────────────────────────────────────────────┤
│  L1 · Núcleo Go                                       │
│       UTXO · SHA-256d · Header 80B · Mempool · P2P    │
│       LoRa codec · BLE bridge · Wallet HD             │
└──────────────────────────────────────────────────────┘

3.1 — Núcleo (L1)

Implementado em Go puro para portabilidade. UTXO model herdado de Bitcoin, com extensão para suportar PoD outputs. Header de 80 B com SHA-256d. Persistência via SQLite em modo WAL.

3.2 — Consenso (L2)

PoD é o trabalho útil; PoW é a finalidade. Um bloco fecha quando: (a) 100 PoDs validados estão no mempool, ou (b) 60 segundos passaram desde o último bloco. Dificuldade ajusta a cada 2016 blocos para target de ~10 min.

3.3 — API + Governança (L3)

Camada de transporte HTTP/gRPC para apps. Sistema de propostas on-chain por câmara com quórum (33%), aprovação (66%) e regra reforçada (80%) para mudanças no hard cap.

3.4 — Apps (L4)

Três apps Flutter independentes — Driver, Cliente, Restaurante — partilham um SDK comum em Dart. Wallet HD BIP32/39/44 com chave dual: SECP256k1 on-chain + Ed25519 para LoRa.

04 · Proof of DeliveryTrês assinaturas, um objeto.

O PoD é a unidade fundamental da Haon. Toda entrega válida produz exactamente um PoD, com a estrutura abaixo. Drivers competem pela inclusão dos seus PoDs no próximo bloco e ganham coinbase ao serem incluídos.

┌─ PoD struct ──────────────────────────────── 357 B ──┐
│ version           u16    2 B                          │
│ tx_id             [32]   32 B                         │
│ pickup_h3         u64    8 B    (resolução 10, ~65 m) │
│ dropoff_h3        u64    8 B                          │
│ path_hash         [32]   32 B   (sha256 de GPS poly)  │
│ timestamp_start   u64    8 B                          │
│ timestamp_end     u64    8 B                          │
│ distance_m        u32    4 B                          │
│ price_hcent       u64    8 B                          │
│ sig_driver        [65]   65 B   secp256k1             │
│ sig_customer      [65]   65 B   secp256k1             │
│ sig_merchant      [65]   65 B   secp256k1             │
│ hmac              [32]   32 B   chave compartilhada   │
│ witness_refs      var    20–60 B (LoRa witnesses)     │
└──────────────────────────────────────────────────────┘

4.1 — Validação

Um validator aceita um PoD se e só se: (a) as três assinaturas verificam contra as chaves públicas registadas em chain; (b) a velocidade média implícita pelo timestamp e distância é fisicamente plausível; (c) as células H3 de pickup e dropoff fazem parte do trajeto declarado; (d) o HMAC bate com a chave compartilhada da sessão.

4.2 — Anti-fraude

Reputação on-chain por driver, cliente e merchant. Slashing automático em PoDs com sigs inconsistentes ou trajetos fisicamente impossíveis. Fórmula de risco multi-fator que penaliza cancelamentos repetidos, padrões de colusão e velocidades anómalas.

05 · Mesh LoRa offlineA rede continua quando a internet cai.

Apagão, zona rural sem cobertura, censura, catástrofe natural — todos derrubam serviços convencionais. A Haon mantém entregas a fluir através de uma malha LoRa em 868 MHz construída com módulos comerciais ESP32 + SX1276 (~€15 BOM).

5.1 — Pacote LoRa

Cada pacote tem 240 B máximos: magic (4) + version (1) + type (1) + ttl (1) + payload (≤181) + ed25519 sig (52). Ed25519 é ~4× mais rápido a verificar num ESP32 do que SECP256k1.

5.2 — Witnesses cruzados

Cada PoD em trânsito ganha N≥3 assinaturas de vizinhos LoRa. Cada witness inclui RSSI/SNR. Witnesses são válidos apenas se o RSSI for coerente com o modelo log-distance dada a distância H3 declarada. Isto torna fraude por GPS-spoofing detectável estatisticamente.

5.3 — Reconciliação

Quando um nó com internet (gateway) recebe um PoD da malha, faz uplink ao backend. O mempool aceita, deduplicando por tx_id. Se o mesmo PoD chegar simultaneamente por internet e por LoRa, prevalece o conjunto com maior número de witnesses.

06 · Tokenomics21 milhões. Halving. Split 2×1.

HaonChain (HNC) é a moeda nativa. Hard cap absoluto de 21 000 000 HNC, alterável apenas com 80% de aprovação reforçada nas três câmaras. Unidade mínima é o hcent (10⁻⁸ HNC).

6.1 — Curva de emissão

6.2 — Split do coinbase

Cada coinbase parte-se em três terços iguais:

• 33,33% — Despesa do driver. Cobre combustível real, desgaste e manutenção.
• 33,33% — Lucro do driver. Margem líquida que vai diretamente para a wallet do trabalhador.
• 33,34% — Treasury da rede. Sustenta desenvolvimento, auditoria, expansão geográfica, antifraude.

Note-se que 2/3 do coinbase vão para quem fez o trabalho físico. A Haon não cobra take rate sobre venda — o que entra em fiat liquida apenas o pedido; HNC é recompensa do protocolo, não comissão.

6.3 — Fórmula tarifária universal

CUSTO = ((Combustível × 2,5) + (Tempo × 1,75)) × 1,235

A tarifa é função explícita de combustível real, tempo investido e imposto local. Três variáveis, todas auditáveis. Não há tarifa dinâmica.

07 · GovernançaTrês câmaras. Captura proibitiva.

Uma câmara colapsa em tirania da maioria. Duas câmaras alinham-se em interesse económico. Três câmaras separam três populações disjuntas com incentivos parcialmente conflituantes, tornando a captura de duas delas economicamente proibitiva.

7.1 — Regra de aprovação

Proposta aprovada ⇔ ≥ 2 câmaras com quórum mínimo de 33% e aprovação ≥ 66%, e nenhuma com veto > ⅔ contra.

Para mudanças no hard cap de 21M, a regra é reforçada: aprovação ≥ 80% nas três câmaras simultaneamente. Na prática, isto torna alteração da emissão quase impossível sem consenso massivo.

7.2 — Anti-captura

Reputação tem teto (~1,5× o voto base) — não basta acumular stake, é preciso atuar bem ao longo do tempo. Slashing por sigs inconsistentes destrói stake automaticamente. Forçar fork malicioso destrói o stake do atacante e a sua reputação.

08 · Roadmap & limitesConstruído em público. Sem dono.

O desenvolvimento divide-se em 10 fases: core types e UTXO (concluído); PoW e dificuldade adaptativa (em execução); persistência e reorgs; wallet HD; mempool; mining service; P2P TCP + LoRa codec; PoD validador completo; API + governança + Flutter; e finalmente testbed end-to-end com simulação multi-nó.

8.1 — Limites conhecidos

• Throughput. Estimativa atual: ~150 TPS no L1 com PoDs validados. Suficiente para 10–50 cidades portuguesas.
• Latência LoRa. Pacote 240 B em SF7 leva ~100 ms; em SF12 (alcance 10 km) leva ~1,5 s.
• Onboarding. Seed de 24 palavras é fricção real. Carteira social com guardiões eleitos pelo driver está em RFC para Fase 12.
• Regulação. PoD não substitui obrigações fiscais — driver continua autónomo regulado pela legislação local.

8.2 — Não-objectivos

Haon não pretende ser uma chain generalista. Não existe EVM, não existem smart contracts arbitrários. O modelo de transações é fechado e orientado a logística. Esta restrição é deliberada: simplicidade do protocolo é proporcional à robustez face a captura económica.

Este resumo cobre 8 das 21 secções do whitepaper completo. A versão integral inclui ataques considerados, comparação com Helium/Filecoin, derivação económica do split 2×1, pseudo-código do validador PoD, e modelo formal da rede LoRa. Disponível em haon.network/whitepaper.pdf (52 páginas).