Método LPG‑RRR

Integração em 1.1.0-rc.1: o capítulo-fonte de 19/09/2026 é preservado abaixo como proposta. Sua edição original não é a versão geral deste White Paper. A nota final delimita o contexto dos novos anexos.

Estado da página: Proposta de governança

Edição: 1.0.0‑rc.1 · minuta · 19 de setembro de 2026

Posição sugerida: Parte 01 · Fundamentos, após "Princípios e CORE"

Classe de mudança (cap. 19): Documental substantiva — exige WXP, revisão especializada e consulta proporcional

Este capítulo formaliza um método que os materiais recuperados citam apenas como lema ("Lógica · Probabilidade · Gestão / Risco · Responsabilidade · Retorno"). Nenhum arquivo recuperado define os termos ou mostra uma decisão justificada por eles. O texto abaixo é uma proposta de definição, não a descrição de uma prática já em uso. Sua adoção depende de deliberação.

O que o método é

O LPG‑RRR é um critério de admissão. Nada entra no protocolo — regra, template, módulo, parâmetro econômico, integração, contrato ou afirmação pública sobre resultado — sem passar pelas três etapas de raciocínio (Lógica, Probabilidade, Gestão) e sem deixar registrada, em cada etapa, uma resposta às três perguntas de prestação de contas (Risco, Responsabilidade, Retorno).

LPG e RRR não são seis critérios soltos. São dois eixos:

Eixo	Função	Ordem
LPG	Processo de decisão: como se pensa antes de admitir algo	Sequencial: Lógica → Probabilidade → Gestão
RRR	Prestação de contas: o que cada etapa é obrigada a responder por escrito	Simultâneo: as três perguntas em cada etapa

O resultado é uma matriz de nove células. Uma célula vazia significa que a proposta não está pronta. "Não sabemos" ou "não estimável" são respostas válidas e devem ser escritas como tal. Um número inventado para preencher a célula é uma violação do método, não uma forma de cumpri‑lo.

O que o método não é

Não é uma metodologia de investimento, não é um sistema de recomendação de alocação e não substitui auditoria de código, parecer jurídico ou verificação on‑chain. Não autoriza afirmar retorno. Aplica‑se igualmente a uma regra de governança, a um template de label ou a uma estratégia financeira: a pergunta é sempre "por que isso deveria funcionar, com que evidência, e o que fazemos quando não funcionar".

Lógica

Pergunta central: por que isso deveria funcionar? Qual é a cadeia causal e quais condições precisam ser verdadeiras ao mesmo tempo?

Critérios de aprovação da etapa:

A cadeia causal está escrita em passos discretos, do início ao efeito esperado.
Cada passo declara a condição que o sustenta (ex.: "as cotações são simultâneas", "a execução é atômica").
Para cada condição, há um modo de falha identificado.
Não há passo que dependa de "confiar em" sem nomear em quem e por quê.

Saída obrigatória: lista de condições, lista de modos de falha, mapa de quem controla cada condição.

Pergunta RRR	O que a Lógica responde
Risco	Enumeração dos modos de falha da cadeia causal, antes de qualquer número
Responsabilidade	Quem controla cada condição: contrato, operador, usuário, terceiro externo, rede
Retorno	De onde o retorno vem mecanicamente. Se a origem não pode ser explicada, não há retorno a apresentar

Regra: uma proposta cuja Lógica não pode ser escrita não passa para Probabilidade. Isso inclui propostas populares, urgentes ou herdadas do legado.

Probabilidade

Pergunta central: com que frequência a cadeia se sustenta, e com que evidência?

Critérios de aprovação da etapa:

Cada afirmação quantitativa declara o estado da evidência segundo a escala do capítulo 13: amostra simulada, importado, declarado, verificado externamente, incompleto ou conflitante.
Distribuições substituem pontos: intervalo, período, amostra e exclusões são explícitos.
Custos são deduzidos antes de qualquer resultado ser chamado de líquido (cap. 16).
Backtests são identificados como backtests, com hipóteses e eventos ausentes (cap. 13).
"Não estimável nesta edição" é uma saída aceita e obrigatória quando não há dado validado.

Saída obrigatória: tabela de afirmações × estado de evidência × fonte, ou declaração de não estimabilidade com a lista do que seria necessário para estimar.

Pergunta RRR	O que a Probabilidade responde
Risco	Magnitude × frequência de cada modo de falha, com estado de evidência declarado
Responsabilidade	Quem tem o ônus de provar; o que foi provado versus o que foi apenas afirmado
Retorno	Distribuição, não ponto; líquida de custos; período e amostra visíveis

Regra: o White Paper proíbe prometer resultado. Esta etapa acrescenta a obrigação simétrica: toda afirmação de retorno vem acompanhada de estado de evidência e intervalo, ou da declaração explícita de que não é estimável. Proibir sem exigir produz um documento que não mente, mas também não informa.

Gestão

Pergunta central: dado o que a Lógica e a Probabilidade mostraram, o que fazemos — e o que acontece quando dá errado?

Critérios de aprovação da etapa:

Cada modo de falha relevante tem um controle nomeado (limite, validação, reversão, pausa, timelock) ou uma aceitação explícita do risco residual.
A permissão técnica real corresponde à responsabilidade declarada (cap. 14): quem se diz responsável tem a chave, o papel ou a função; quem tem a chave aparece como responsável.
O custo para o usuário é visível antes da autorização e não pode ser ocultado por personalização (cap. 8, 16).
Há formato de reporte definido: campos, unidade, período, origem de preço, inclusões e exclusões.
Existe caminho de reversão ou descontinuação documentado.

Saída obrigatória: mapa controle ↔ modo de falha, mapa permissão ↔ responsável, formato de reporte, plano de reversão.

Pergunta RRR	O que a Gestão responde
Risco	Controles, limites, reversibilidade, autoridade de pausa publicada e verificada
Responsabilidade	Correspondência demonstrada entre permissão e responsabilidade; não‑custódia como propriedade demonstrada, não como rótulo
Retorno	Escopo, custos, forma de reporte. Nunca meta, nunca promessa

A matriz completa

	Risco	Responsabilidade	Retorno
Lógica	O que quebra a cadeia	Quem controla cada condição	De onde vem, mecanicamente
Probabilidade	Magnitude × frequência, com estado de evidência	Quem prova; o que está provado	Distribuição líquida, período, amostra — ou "não estimável"
Gestão	Controles, limites, reversão, pausa	Permissão real = responsabilidade declarada	Escopo, custos visíveis, reporte

Proporcionalidade

A matriz não se aplica com a mesma profundidade a toda mudança. A classificação do capítulo 19 define a exigência:

Classe de mudança	Exigência LPG‑RRR
Editorial	Não se aplica
Documental substantiva	Lógica completa; Probabilidade e Gestão quando a mudança afetar interpretação de risco, permissão ou retorno
Experiência e catálogo	Lógica e Gestão; Probabilidade quando o componente preparar ações técnicas
Governança	Matriz completa
Econômica ou de permissão	Matriz completa, com revisão independente das células de Retorno
CORE ou infraestrutura	Matriz completa, mais processo técnico próprio (cap. 14, 17)

Rotular uma mudança em classe inferior para reduzir a exigência é a mesma infração que rotular uma mudança de sentido como "editorial" (cap. 19) e deve ser contestável.

Papel da inteligência artificial por etapa

Os materiais recuperados descrevem a WEbdEX como protocolo híbrido — inteligência coletiva da comunidade combinada com inteligência artificial — mas nenhum arquivo define o que a IA faz ou deixa de fazer. O método fornece a fronteira:

Etapa	O que a IA pode fazer	O que a IA não pode fazer
Lógica	Enumerar condições, modos de falha, invariantes e dependências; revisar exaustivamente cadeias causais; apontar passos sem condição declarada	Substituir a revisão humana da cadeia; ser a única fonte de um modo de falha "descartado"
Probabilidade	Organizar, classificar e cruzar evidência existente; calcular a partir de dados fornecidos e identificados; detectar amostras insuficientes	Produzir estimativa sem dado identificado; preencher uma célula com número gerado; elevar o estado de uma evidência
Gestão	Sugerir controles, redigir reportes, simular cenários rotulados como simulação	Deter permissão, autorizar, executar ou assinar; ocupar o lugar de um responsável nomeado

A regra síntese: a IA é mais útil onde o trabalho é exaustivo (Lógica), mais perigosa onde a fluência disfarça a ausência de dado (Probabilidade), e não tem autoridade onde a decisão tem consequência (Gestão). Toda saída de IA incorporada a uma ficha LPG‑RRR deve ser identificada como tal, com modelo, versão e data, e revisada por pessoa nomeada. Isso é uma aplicação do princípio "evidência antes de afirmação" (cap. 4), não uma exceção a ele.

Aplicação: arbitragem triangular

Este exemplo mostra o método aplicado ao único caso de uso financeiro citado nos materiais recuperados. Ele não descreve os contratos WEbdEX, cuja lógica não foi verificada nesta análise (cap. 14). Descreve o raciocínio genérico de uma arbitragem em três pares e o que seria exigido para admiti‑la como capacidade do protocolo.

Lógica

Cadeia causal. Três pares em um ou mais mercados (A→B, B→C, C→A) apresentam, em um instante, taxas cujo produto excede 1 somado a todos os custos. Uma única transação percorre o ciclo e termina com mais A do que começou.

Condições necessárias, simultaneamente:

Condição	Modo de falha	Quem controla
As cotações usadas são as vigentes no bloco de execução	Cotação obsoleta; preço muda entre leitura e execução	Rede e pools (terceiros)
A liquidez suporta o tamanho da operação sem consumir a margem	Slippage supera o spread	Pools (terceiros); tamanho da ordem (contrato/operador)
O ciclo é atômico: ou completa inteiro, ou reverte inteiro	Execução parcial deixa posição em ativo indesejado	Contrato (WEbdEX)
Gás + taxas dos pools < margem bruta	Operação lucrativa em bruto e negativa em líquido	Rede (gás); pools (taxas); contrato (cálculo prévio)
Nenhum outro agente captura a oportunidade antes ou reordena a transação	Front‑running, sandwich, competição de bots; a transação reverte e o gás é pago mesmo assim	Rede e mempool (terceiros); estratégia de submissão (operador)
Os contratos dos pools e o roteador se comportam como especificado	Bug, pausa, upgrade ou exploit de dependência externa	Terceiros; revisão do contrato WEbdEX
A carteira do usuário só autoriza o que a interface descreve	Permissão excessiva; aprovação ilimitada	Usuário; interface (WEbdEX); contrato

Origem do retorno. Discrepância momentânea de preço entre pools. É consumida por gás, taxas dos pools e pela competição de outros arbitradores. Não há retorno estrutural: a oportunidade existe apenas enquanto o mercado está desalinhado e alguém ainda não a fechou.

Conclusão da etapa. A Lógica é escrevível e passa. Ela também mostra que transações revertidas são custo real: uma tentativa que falha por competição paga gás e não é neutra. Qualquer reporte que omita tentativas revertidas superestima o resultado.

Probabilidade

Estado nesta edição: não estimável. Não há dataset validado (cap. 26), a semântica do evento OpenPosition não foi confirmada contra ABI e versão (cap. 13), e os campos profit, gas e fee não têm significado comprovado (cap. 13).

O que seria necessário para estimar:

Dado	Estado de evidência exigido
Eventos do ciclo por rede, contrato, transação, bloco e índice de log	Verificado externamente
Gás pago por transação, incluindo as revertidas	Verificado externamente
Taxas cobradas por cada pool no ciclo	Verificado externamente ou declarado com fonte
Preço de referência para conversão de unidades, com origem e instante	Declarado com fonte
Janela de amostra, seleção e eventos ausentes	Documentado
Contagem de tentativas revertidas no período	Verificado externamente

Sem esses dados, qualquer percentual histórico do White Paper legado permanece "declarado" e não pode ser reapresentado como resultado (cap. 24).

Gestão

Modo de falha	Controle exigido
Slippage e cotação obsoleta	Margem líquida mínima calculada on‑chain antes da execução; reverte se não atingida
Execução parcial	Atomicidade demonstrada por teste e revisão do contrato
Gás > margem	Limite de gás e verificação de lucratividade líquida na própria transação
Competição e reordenação	Estratégia de submissão documentada; reporte separado de tentativas revertidas
Dependência externa	Lista de contratos e pools dependentes com versão; autoridade de pausa publicada e verificada
Permissão excessiva	Aprovação limitada ao valor da operação; sem aprovação ilimitada por padrão

Responsabilidade. O inventário do capítulo 14 (rede, endereço, código, ABI, proxy, privilégios, dependências, revisão) é pré‑requisito. Quem detém a função de pausa, de alteração de parâmetros ou de upgrade deve constar como responsável. Não‑custódia deve ser demonstrada mostrando que o contrato não pode mover fundos fora do ciclo autorizado.

Retorno. Nenhuma meta. Formato de reporte obrigatório: bruto por ciclo, gás (incluindo revertidas), taxas de pool, líquido, número de tentativas, número de sucessos, período, rede, origem de preço, exclusões. Um indicador só pode ser chamado "líquido" com esses campos visíveis (cap. 16).

Conclusão da etapa. A arbitragem triangular pode ser admitida como capacidade somente quando: (a) o inventário técnico existir, (b) os controles acima forem verificados por revisão, (c) a Probabilidade sair do estado "não estimável" com dados verificados. Até lá, sua apresentação correta é "aplicação em desenvolvimento, sem resultado apresentável" — exatamente o tratamento que o capítulo 1 já adota, agora com a justificativa explícita.

Auditoria da edição atual contra o método

Capítulo	Etapa que cobre	Lacuna
04 Princípios e CORE	Gestão‑Risco, Gestão‑Responsabilidade	—
13 Scan e observabilidade	Probabilidade‑Risco (escala de evidência)	Não exige estimativa; só classifica
14 Contratos e permissões	Gestão‑Responsabilidade	Sem Lógica dos contratos: função de cada módulo não está explicada
15 BD	Gestão‑Retorno (o que não é prometido)	Sem Lógica: por que holding confere elegibilidade e qual efeito se espera
16 Economia	Gestão‑Retorno (campos obrigatórios)	Sem Probabilidade: nenhuma regra exige intervalo ou estado de evidência
17 Segurança	Gestão‑Risco	—
19–21 Governança	Gestão completa	Sem Lógica: por que o modelo de deliberação proposto produziria decisões melhores que alternativas
01 Manifesto (arbitragem)	Nenhuma	Citada como "aplicação possível" sem cadeia causal, evidência ou controles

Leitura: a edição atual é quase inteiramente Gestão. É por isso que soa cautelosa. Lógica está ausente como exigência em todos os capítulos; Probabilidade existe apenas como classificação, nunca como obrigação de estimar. O método, se adotado, corrige as duas ausências sem alterar nenhuma regra de Gestão já escrita.

Condições de adoção

Este capítulo é submetido como WXP de classe "documental substantiva".
A ficha LPG‑RRR (anexo) passa a integrar o conteúdo mínimo de uma WXP (cap. 20) para as classes que a exigem.
As pendências D‑05 (holding × staking), D‑06 (regras econômicas) e D‑07 (contratos e poderes) devem ser encerradas com ficha LPG‑RRR preenchida, e não apenas com decisão.
Toda contribuição de IA a uma ficha é identificada por modelo, versão, data e revisor humano.
O capítulo 1 passa a referenciar este capítulo ao citar a arbitragem triangular.

Limites deste capítulo

Não verifica contratos, não estima resultado, não define parâmetros de governança nem regras de BD. As definições de Lógica, Probabilidade e Gestão são propostas desta minuta e podem ser contestadas pelo mesmo processo que rege qualquer outra regra do documento. O exemplo de arbitragem é genérico e não descreve a implementação WEbdEX.

Anexo — Ficha LPG‑RRR (modelo)

FICHA LPG‑RRR
Proposta: [identificador WXP ou LOCAL/DRAFT]
Classe de mudança (cap. 19): [ ]
Exigência aplicável: [Lógica | L+G | L+P+G | completa + processo técnico]
Contribuição de IA: [nenhuma | modelo, versão, data, revisor]

L · LÓGICA
  Cadeia causal (passos):
  Condições necessárias → modo de falha → quem controla:
  Origem mecânica do retorno (ou "não há retorno a apresentar"):
  Passa? [sim | não — motivo]

P · PROBABILIDADE
  Afirmações quantitativas → estado de evidência → fonte:
  Custos deduzidos:
  Período, amostra, exclusões:
  Ou: NÃO ESTIMÁVEL — dados necessários para estimar:
  Ônus de prova: quem, o que já foi provado:

G · GESTÃO
  Modo de falha → controle (ou risco residual aceito):
  Permissão técnica → responsável nomeado:
  Custo visível ao usuário antes da autorização: [onde]
  Formato de reporte (campos, unidade, período, origem de preço, exclusões):
  Reversão / descontinuação:

CÉLULAS VAZIAS: [lista] → proposta não pronta

Nota de incorporação · revisão 1.1.0-rc.1

O texto acima foi preservado como proposta de 19/09/2026. Sua menção ao “único caso de uso financeiro citado nos materiais recuperados” descreve o universo de fontes daquela proposta, não todos os anexos recebidos nesta revisão. Os novos anexos acrescentam liquidez concentrada e swaps, tratados no capítulo 31. A auditoria de lacunas acima é diagnóstico da edição anterior; as ampliações presentes não equivalem a ratificação ou auditoria.

Uma regra normativa de adoção depende de WXP. Um preenchimento completo admite revisão, não execução. Esta incorporação não altera a direção holding, não cria staking/burn de BD e não estima resultado.