runtime-groundedcanônicoprofissional

Arquitetura Leve / Alpha Signals

Visão canônica da arquitetura com quatro lentes: runtime plugado, blocos ainda não plugados canonicamente, integrações futuras possíveis e foco prático da semana para evoluir de venda para humanos até um modelo que também possa servir agentes.

fase em foco

Humans + Agents

Hoje
a Leve vende sinais para humanos com fluxo já mais visível

Exploração
entender como servir agentes sem bagunçar o produto

Meta da semana
organizar buy flow, proof layer, payment layer e viewer

gráfico 1

Runtime Plugado Hoje

ativosuporte

flowchart TD U[User / Trader] FE[Frontend Next.js
PM2 :3001
app.leve.app.br] PUB[GET /api/alpha-signals/public] BE[Backend API
PM2 :3002] DB[(PostgreSQL
127.0.0.1:5432)] UNLOCK[user_signal_unlocks
unlock store] WALLET[Wallet on BSC] LEVE[LEVE Token
0x67e463AcC3B35406B0f35C8Ed531da89f9670861] SPLIT[PaymentSplitter
0x8Fe9A4FCAf515e611351B73Da6170E41Ba9932c2] X402[X402 BNB/USDT
resource por sinal] MERCHANT[Merchant Wallet
0x077E8d29E11FF1c0CCb236e0380D0053DcBa2B1c] USDT[USDT BNB
0x55d398326f99059fF775485246999027B3197955] ANCHOR[AlphaSignalsAnchor
next executable proof layer] AUDIT[AuditRegistry / ERC-8004
next trust layer after anchor] U --> FE FE --> PUB PUB --> BE FE --> BE BE --> DB BE --> UNLOCK UNLOCK --> DB FE --> SPLIT SPLIT --> BE WALLET --> LEVE LEVE --> SPLIT FE --> X402 X402 --> WALLET WALLET --> USDT USDT --> MERCHANT MERCHANT --> BE BE -. next proof write .-> ANCHOR ANCHOR -. proof metadata back to app .-> BE ANCHOR -. public integrity proof .-> FE AUDIT -. trust layer after anchor .-> ANCHOR classDef active fill:#143,stroke:#7ff,color:#fff; classDef support fill:#1e3a8a,stroke:#93c5fd,color:#fff; classDef caution fill:#5a4300,stroke:#ffcc66,color:#fff; class FE,BE,DB,PUB,UNLOCK,WALLET,LEVE,SPLIT,X402,MERCHANT,USDT active; class ANCHOR,AUDIT caution;

gráfico 2

Preparados, Mas Ainda Não Canônicos

cautelalegado

flowchart TD ANCHOR[AlphaSignalsAnchor
prepared integrity anchor] AUDIT[AuditRegistry / ERC-8004
trust and audit layer] REP[ReputationHook_v2
reputation bridge] ERC8183[ERC8183
commercial/escrow layer in repo] ERC8021[ERC8021
attribution layer] POY[ProofOfYield
legacy proof idea] GEN[Alpha Engine / generation
PM2 stopped] ERC8183 -. possible future commercial path .-> ANCHOR AUDIT -. possible trust stack .-> REP ERC8021 -. attribution concept .-> AUDIT POY -. replaced as canonical proof idea .-> ANCHOR GEN -. may feed future proof stack .-> ANCHOR classDef caution fill:#5a4300,stroke:#ffcc66,color:#fff; classDef legacy fill:#522,stroke:#f88,color:#fff; class ANCHOR,AUDIT,REP,ERC8183 caution; class ERC8021,POY,GEN legacy;

gráfico 3

Possíveis Integrações Futuras

futuro possível

flowchart TD FE[Frontend] BE[Backend] OC[OpenClaw] GEN[Signal Generation] DB[(PostgreSQL)] ANCHOR[AlphaSignalsAnchor] AUDIT[AuditRegistry / ERC-8004] REP[ReputationHook_v2] ERC8183[ERC8183] SPLIT[PaymentSplitter] WALLET[Wallet / BSC] X402[X402] VIEWER[Architecture / Ops Viewer] GEN -. generate canonical payload .-> BE BE -. hash + anchor signal .-> ANCHOR BE -. persist tx hash / proof status .-> DB ANCHOR -. expose signal integrity proof .-> FE OC -. automate verification / monitoring .-> AUDIT AUDIT -. feed trust signals .-> REP REP -. enrich product reputation view .-> FE ERC8183 -. possible unified payment + delivery path .-> BE ERC8183 -. possible replacement or coexistence review .-> SPLIT WALLET -. purchase / access / signature .-> ERC8183 X402 -. internet-native payment rail .-> ERC8183 X402 -. machine-to-machine payment possibility .-> BE OC -. update architecture state .-> VIEWER BE -. expose runtime metadata .-> VIEWER ANCHOR -. expose proof metadata .-> VIEWER AUDIT -. expose audit metadata .-> VIEWER X402 -. future payment observability .-> VIEWER classDef future fill:#0f3d2e,stroke:#34d399,color:#fff; class FE,BE,OC,GEN,DB,ANCHOR,AUDIT,REP,ERC8183,SPLIT,WALLET,X402,VIEWER future;

gráfico 4

Foco da Semana: Venda para Humanos e Agentes

semana de integração

flowchart LR H[Humans] A[Agents] FE[Frontend / UX] API[Backend / API] BUY[Buy Signal Flow] PROOF[Proof Layer] PAY[Payment Layer] OBS[Viewer / Observability] H --> FE A --> API FE --> BUY API --> BUY BUY --> PAY BUY --> PROOF PAY --> OBS PROOF --> OBS classDef sprint fill:#123b5d,stroke:#7dd3fc,color:#fff; class H,A,FE,API,BUY,PROOF,PAY,OBS sprint;

payment rail

Canal default e canal alternativo

Ativo no frontend
BNB + USDT como trilha X402 operacional atual para o público natural da Leve em BSC/BNB

Desativado no frontend
Base + USDC saiu do fluxo ativo até o settlement fechar corretamente ponta a ponta

Regra canônica atual
no produto live, manter só a trilha X402 que já está coerente com unlock por sinal e persistência real

Nota importante
X402 hoje aparece como payment rail, não como contrato proprietário canônico da Leve

Merchant atual
0x077E8d29E11FF1c0CCb236e0380D0053DcBa2B1c

execução

Fluxo atual, humano

1. Descoberta
usuário vê sinais no frontend via /api/alpha-signals/public

2. Compra
existem dois caminhos visíveis: payForSignal(...) no PaymentSplitter ou X402 BNB/USDT por sinal

3. Validação
backend confirma pagamento e grava unlock em user_signal_unlocks, convergindo os dois rails no mesmo modelo

4. Entrega
conteúdo completo é liberado no app após unlock validado para aquele sinal

gap

Fluxo futuro, agente

1. Descoberta programática
agente consome catálogo/API estável, sem depender da UI humana

2. Pagamento nativo de máquina
X402 entra como trilha de pagamento internet-native para software, não como enfeite

3. Prova verificável
âncora de integridade expõe hash, timestamp e prova pública do sinal comprado

4. Observabilidade
viewer mostra runtime, prova e status comercial sem misturar futuro com produção

explorer

Links operacionais

Merchant BscScan
0x077E8d29E11FF1c0CCb236e0380D0053DcBa2B1c

USDT BNB
0x55d398326f99059fF775485246999027B3197955

Leitura correta
na BscScan, o X402 atual aparece como payment rail via token transfer + merchant wallet, não como contrato proprietário canônico

matriz

Classificação técnica

Bloco	Categoria	Status	Direção
Frontend	plugado	ativo	superfície real do produto
Backend	plugado	ativo	núcleo runtime
PostgreSQL	plugado	ativo	verdade operacional do app
OpenClaw Gateway	suporte	ativo	camada operacional
X402 BNB/USDT	plugado / evolução	ativo	resource por sinal + 402 tratado + persistência em user_signal_unlocks
X402 Base/USDC	parcial	desativado no frontend	só reativar após settlement real ponta a ponta
PaymentSplitter	plugado	ativo	manter como caminho comercial real
AlphaSignalsAnchor	preparado	cautela	forte candidato à âncora, ainda sem uso canônico live
AuditRegistry / ERC-8004	preparado	cautela	boa diferenciação de confiança, ainda fora do fluxo live
ERC8183	repo-present	cautela	confirmar uso real antes de centralizar
ERC8021	legado/non-core	legado	não usar como centro
ProofOfYield	legado	legado	descartar versão atual
Alpha Engine	legacy/caution	parado	só reativar com disciplina

checklist

Como reconhecer uma tx X402 válida na BscScan

status da tx: Success
token: USDT BNB no contrato 0x55d398326f99059fF775485246999027B3197955
evento/log relevante: Transfer
from = wallet do pagador
to = merchant 0x077E8d29E11FF1c0CCb236e0380D0053DcBa2B1c
amount = maior ou igual ao mínimo exigido pela rota

Fonte canônica local: /root/openclaw/workspaces/cabral/ARCHITECTURE_CANONICAL_MAP.md