Oracle3
Oracle3: 예측시장 거래 엔진·MCP 서버
아직 감지된 업데이트가 없습니다. GitHub 릴리스가 나오면 여기에 보입니다.
개인 계정의 공개 저장소 소유자는 GitHub로 로그인해 운영자를 확인하고 소개를 직접 관리할 수 있습니다. 관리자 승인은 필요하지 않습니다.
로그인한 뒤 확인 파일을 만들어 이 저장소의 기본 브랜치에 30분 안에 커밋해 주세요. 다른 브랜치나 포크의 파일은 인정하지 않습니다. 파일을 올린 뒤 아래에서 확인하면 관리자 승인 없이 관리할 수 있습니다. 자격을 유지하려면 파일을 남겨 두세요.
로그인이 필요하면 로그인 화면으로 이동합니다. 로그인 후 이곳으로 돌아와 원하는 확인 버튼을 다시 눌러 주세요.
프로젝트 폴더에서 /nomorevibe verify를 실행하면 소유권을 확인하고 소개를 직접 관리할 수 있습니다.
1분 만에 확인하기README 전체를 불러오는 중입니다. 아래는 저장된 발췌입니다.
Protótipo digital do projeto Raízes do Futuro (Youth Challenge Blockchain — UNICEF Brasil). Demonstra o ciclo completo: Coleta → Validação DeTrash → Relatório de Circularidade → Receita (turistas + empresas) → Cofre multisig 2-de-3 (Fundo Infância) → Conta Decaf da família → Pix, incluindo o onboarding gamificado das famílias — sem seed phrase, sem jargão.README 전문 보기 ↗
Protótipo digital do projeto Raízes do Futuro (Youth Challenge Blockchain — UNICEF Brasil).
Demonstra o ciclo completo: Coleta → Validação DeTrash → Relatório de Circularidade → Receita (turistas + empresas) → Cofre multisig 2-de-3 (Fundo Infância) → Conta Decaf da família → Pix, incluindo o onboarding gamificado das famílias — sem seed phrase, sem jargão.
Pré-requisito: Node.js 18+
npm install
npm run dev
Duas telas independentes:
| Endereço | Para quem |
|---|---|
| http://localhost:5173 | landing page do projeto — porta de entrada pública |
| http://localhost:5173/#/painel | painel da operação e dos parceiros (8 abas) |
| http://localhost:5173/#/login | entrada da operação (autentica de verdade, via lib/auth.js) |
| http://localhost:5173/#/familia | app da família, mobile-first — a tela que a família usa no celular |
| http://localhost:5173/campo.html | app de campo do catador — registro de coleta com evidência verificável, funciona sem internet |
| http://localhost:5173/revisao.html | painel de revisão da coordenação — os registros que pediram conferência humana (a mesma tela está na aba Conferência do painel) |
As duas últimas são o módulo de Validação de Coleta, que transforma a etapa de validação (hoje apoiada em confiança pessoal) em evidência verificável por máquina: classificação do material no próprio aparelho, hash perceptual da foto, árvore de Merkle diária e ancoragem. Documentação em VALIDACAO.md; o pipeline do modelo em modelo/README.md.
| Camada | Escolha | Por quê |
|---|---|---|
| Rede | Solana (devnet simulada) | taxa de fração de centavo e confirmação em segundos — viável para bônus de R$ 30 |
| Transações | signature base58 de 88 chars + slot incremental | mesmo formato do explorador da Solana; cada signature carrega a da anterior, formando a cadeia auditável |
| Endereços | pubkey base58 de 44 chars | idem |
| Cofre do Fundo Infância | multisig 2-de-3 (padrão Squads) | nenhuma organização move o dinheiro sozinha |
| Signatários | Instituto Vivá, DeTrash, Representante Comunitário | validação social, verificação ambiental e voz da comunidade |
| Stablecoin | BRZ/cRED (1 = R$ 1) | a família nunca vê o valor oscilar |
| Carteira da família | Decaf (provider: 'Decaf', rede: 'Solana') | custódia simplificada: celular + PIN de 4 números, sem seed phrase |
comprovação enviada pela família (foto, off-chain)
→ Instituto Vivá valida → tx VALIDAÇÃO
→ cofre cria uma proposta → tx PROPOSTA (status: aguardando)
→ signatário 1 assina → tx ASSINATURA (1/2)
→ signatário 2 assina → tx ASSINATURA (2/2) → limiar atingido
→ cofre executa automaticamente → tx LIBERAÇÃO (debita cofre, credita a conta Decaf)
Sem conta Decaf ou sem saldo livre no cofre, a proposta nasce reservada (tx RESERVA): o valor nunca é perdido e a proposta é reaberta sozinha quando a família cria a conta.
Tipos de transação no explorador: RECEITA, VALIDAÇÃO, PROPOSTA, ASSINATURA, LIBERAÇÃO, RESERVA, CARTEIRA, SAQUE, RENDA (renda incondicional da coleta), CONSENTIMENTO, CONTESTACAO e ANCORAGEM (registro real na devnet) — mais GÊNESE e CIRCULARIDADE.
| Perfil | O que faz |
|---|---|
| 📊 Dashboard | Indicadores vs. metas do piloto, gráfico de kg por semana (barras) e receita por fonte (donut) — SVG puro. Botão ▶ Ver o ciclo completo |
| 🧹 Coletor | Registra ações de coleta (material, kg, local) |
| ✅ Instituto Vivá | Valida coletas (metodologia DeTrash), emite Relatórios de Circularidade e valida comprovações — que passam a criar propostas no cofre |
| 🛒 Mercado | Turista compra produto reciclado; empresa compra crédito/relatório ESG. Cada venda dispara a animação do split 60/25/15 com contadores animados |
| 🔗 Cofre Multisig | Saldo e endereço do cofre, painel de propostas com os 3 signatários e botão "Assinar como […]", animação de execução ao atingir 2/3, e explorador de transações (tipo, descrição, signature truncada, slot) com modal de detalhes |
| 📝 Cadastro | Inclui família no piloto (nome, crianças, código pseudônimo) com o consentimento no mesmo formulário, e abre os compromissos de cada mês em lote |
| 👨👩👧 Família (operação) | Visão do agente: conectar carteira Decaf, metadados (rede: Solana · provider: Decaf), extrato e saque Pix |
| 📱 App da Família | A tela do celular, dentro de uma moldura — igual à rota #/familia |
#/familia)Mobile-first e com zero jargão cripto — nunca aparece "wallet", "token", "blockchain", "multisig" ou "hash". A linguagem é "conta da família", "dinheiro", "bônus" e "cofre digital".
PIN da família abaixo)Na primeira vez que alguém abre o painel, um tour de 9 passos aparece sozinho e apresenta o ciclo do projeto e o que as abas da jornada fazem. Ele troca de aba conforme avança e destaca a aba descrita com um anel pulsante.
Esc para fechar, ou clique direto num dos pontos de progressolocalStorage (raizes-tour-v1)No Dashboard, ▶ Ver o ciclo completo executa a jornada inteira em 13 passos automáticos (~50 s), trocando de aba sozinho, destacando o elemento ativo e narrando cada etapa num card fixo:
ponto de partida → coleta → verificação DeTrash → relatório → receita → split 60/25/15 → comprovação da família → validação social → multisig 1 de 2 → multisig 2 de 2 (executa) → bônus na conta Decaf → retirada pelo Pix → ciclo completo
O primeiro passo já dá RESET, então a gravação pode ser repetida quantas vezes for preciso e sempre parte do mesmo estado.
Há também um 🎥 Modo gravação no rodapé: esconde os elementos que denunciam a simulação (marcações "(simulação)" etc.), deixando a tela limpa para o vídeo. Sai pelo botão flutuante no canto.
O app tem dois modos, e a tela diz qual está valendo:
| sem sessão | com sessão da operação | |
|---|---|---|
| App funciona | sim, inteiro, offline | sim |
| Lê a base compartilhada | não | sim, conforme o papel |
| Envia para a base | não | sim, conforme o papel |
Sem login o app roda 100% local — é o modo da demonstração e do vídeo. Entrar (canto superior direito) serve para sincronizar entre os aparelhos da operação.
Papéis: coletor registra coleta e não valida; validador e gestor validam, criam proposta e cadastram. Sem papel atribuído, estar autenticado não dá acesso a nada.
A família não tem senha. Ela entra no app dela com PIN, no celular. Quem tem credencial é a operação, no aparelho de trabalho — dar login e senha para a mãe em Boipeba seria transferir a ela o custo de um problema nosso.
2-de-3 de verdade: cada pessoa só assina em nome da organização registrada no seu papel. Antes, quem tivesse a chave do frontend produzia as três assinaturas e o multisig não protegia ninguém.
Detalhes, o SQL e os dois passos manuais de configuração: SUPABASE.md.
O consentimento vale 24 meses e é renovável em visita de campo. Vencido, os dados daquela família saem da base compartilhada; 30 dias depois (carência para renovar) podem ser expurgados.
O expurgo apaga o que é pessoal — familias, condicoes, extrato, propostas — e mantém transacoes e movimentos, que são contabilidade pseudonimizada sem nome nem código de família, com base legal distinta do consentimento. O registro do consentimento fica, marcado como expurgado: apagar a prova de que houve consentimento, prazo e expurgo destruiria a demonstrabilidade que a LGPD pede.
Não é "apaguei tudo" nem "guardei tudo". Detalhes e comandos: supabase/migracoes/03-retencao.sql.
O expurgo não roda sozinho. Agendador que ninguém monitora apaga dado em silêncio; a rotina mensal está em IMPLANTACAO.md.
O caranguejo lê os balões em voz alta (Web Speech, nativo, zero dependência). Não é enfeite: em Boipeba há adultos com pouca leitura fluente, e a tela fala de dinheiro e de saúde de criança — quem não lê bem depende de outra pessoa para entender o próprio saldo, que é a dependência que o projeto quer remover.
Três regras que não se negociam:
R$ 90,00 sai como "noventa reais", não "erre cifrão noventa vírgula zero zero", e emoji é removido (a síntese tenta descrever cada um).O projeto vende verificabilidade — e a família era a única que não podia verificar nada. O turista audita a jornada da peça na página pública, o júri audita o cofre no explorer, a operação vê tudo. A família via dinheiro, não o registro que produziu aquele dinheiro: não tinha como saber se os 60 kg que entregou foram lançados como 60 ou como 6.
Suas entregas mostra data, material, peso e situação de cada coleta no nome dela, com o total entregue e o total já conferido. E cada registro — entrega ou compromisso — tem "Isso está errado?".
O circuito fecha: a contestação vira pendência na aba do Instituto Vivá (o mesmo lugar onde o erro foi cometido), a operação pode corrigir o peso ali mesmo se a coleta ainda não foi validada, responde em linguagem simples, e a resposta aparece no app da família.
Regras que valem a pena saber:
Num programa que condiciona dinheiro a comprovação, quem é avaliado precisa poder contestar a avaliação. Sem isso, "erro do sistema" é sempre problema da família.
A família define uma meta ("consertar o telhado", R$ 1.500) e a tela mostra quanto falta. Guardar para um objetivo é algo que as pessoas querem e é difícil sem ferramenta — então a ferramenta existe.
As travas contra virar tutela estão no desenho, não no discurso, e cada uma tem teste:
Seletor PT/EN no cabeçalho. Português é sempre o padrão — é um projeto brasileiro, e o inglês é camada de leitura para fora. Nada de adivinhar pelo idioma do navegador: um avaliador brasileiro com Windows em inglês cairia numa tradução parcial sem pedir.
Traduzido por inteiro:
#/rastreio/CÓDIGO) — quem escaneia o QR da peça em Boipeba é turista, e boa parte é estrangeira. É a única tela com leitor em inglês real, e o seletor fica nela mesma, porque quem chega pelo QR não passa pelo painel.Não traduzido, de propósito: o app da família (quem usa é a mãe em Boipeba) e as telas de operação (quem opera é a equipe local). Meia tradução silenciosa é pior que tradução nenhuma — o avaliador clica, cai em português no meio do fluxo e conclui que o resto foi feito com o mesmo descuido. Por isso o seletor avisa na tela quando a aba aberta só existe em português, em vez de deixar a pessoa descobrir sozinha.
O PIN é verificado de verdade e nunca sai do celular: guarda-se SHA-256 de sal + pin, com sal por família. Cinco tentativas erradas travam o aparelho, e só o agente destrava — presencialmente, apagando o PIN para a família escolher outro. Ninguém do projeto consegue ver o PIN de ninguém, nem para ajudar.
Não há recuperação por SMS de propósito: seria mais um canal para falhar justamente com quem tem menos recurso.
Está em IMPLANTACAO.md — e o que falta agora não é código: distribuir as três credenciais entre as três organizações (sem isso o 2-de-3 é cumprido por uma pessoa), definir o responsável pela rotina mensal de retenção, e limpar os dados de demonstração (supabase/scripts/limpar-demonstracao.sql).
Os dados de demonstração na base foram criados pelos testes, sem termo de consentimento — e não há registro fabricado para eles, porque consentimento inventado é pior que consentimento nenhum: mente exatamente na prova.
A jornada do app é simulada de propósito — roda offline, é repetível e resetável. Três coisas saem da simulação, e são reais na devnet: o hash do Relatório de Circularidade (programa Memo), as liberações do cofre 2-de-3 (multisig nativo do SPL Token, assinadas por duas organizações distintas) e o registro da decisão coletiva de fechamento de ciclo.
Por que o relatório: é o artefato que tem valor externo (é o que a empresa ESG compra) e é apenas um SHA-256 — nenhum dado de família ou criança sai daqui.
O cofre é um multisig nativo do SPL Token, 2-de-3, e cada liberação pode ser executada de fato na devnet — o app guarda o comprovante e o link para o explorer (aba Cofre Multisig → "Liberações no cofre real").
O app não assina, e isso é proposital. Assinar exige chave privada: em bundle de navegador ela é pública, e numa função de servidor o servidor passa a ser o signatário — o 2-de-3 morre. Então quem assina é a pessoa da organização, na máquina dela:
cd onchain
node liberar-bonus.mjs preparar --valor 60 --org viva --proposta 42
# a saída é uma transação parcialmente assinada; mande para a outra organização
node liberar-bonus.mjs assinar --org detrash --tx <base64>
São duas etapas porque o multisig do SPL Token exige as duas assinaturas na mesma transação — não existe "a Vivá assina hoje e a DeTrash amanhã" com estado num servidor nosso. O que viaja entre as organizações é a própria transação. O passo 2 imprime o que está sendo assinado antes de enviar: assinar às cegas um blob que chegou por mensagem transforma multisig em teatro.
Verificado na devnet: R$ 30 saíram do cofre (585 → 555) para a conta da família (60 → 90), com viva e detrash assinando e comunidade não — slot 479156986.
O residual do ciclo vai para ações de saúde e educação decididas com a comunidade. A decisão é da assembleia; o que a rede registra é a prova pública de qual decisão foi tomada, com qual valor (aba Cofre Multisig → "Fechamento de ciclo" → onchain/ancorar-decisao.mjs).
Não virou função de contrato de propósito: um contrato que distribuísse o residual sozinho tomaria a decisão no lugar das pessoas. O que precisa ser imutável é o registro da decisão, não a decisão. Por isso contracts/FundoInfancia.sol está marcado como não implantado — ele é EVM, e o piloto ficou só na Solana.
Assinar transação exige chave privada, e ela não pode ficar em dois lugares:
VITE_*, que são inlinadas em dist/assets/*.js;Então o fluxo é: o app calcula o SHA-256 e mostra o comando pronto → quem opera roda na própria máquina → cola a assinatura de volta no app. Menos cômodo, e o registro fica verificável por qualquer pessoa.
cd onchain
node ancorar-relatorio.mjs <sha256> "<período>"
O script usa a mesma conta pagadora do implantar-devnet.mjs, grava o histórico em onchain/dados/ancoragens.json e imprime o link do explorer. No app: aba Instituto Vivá → relatório → ancorar na Solana devnet.
O relatório "Julho 2026 — quinzena 1" (105 kg) está na devnet:
hash 3bb13611cde6b9f67cd97964d4b4736a4c6fe86840595e4b16b8049673511d4b
tx 32236oNENMrvKmfp5e62Asi7Uxf7DabAiJynAeLc5JE6hVDWmEeRUYMJjGspJgt9UadUVKiUVzgKicc1F9LqDN6w
slot 479128408
Conferível em explorer.solana.com/tx/<tx>?cluster=devnet — o log do programa mostra o memo com o hash.
A integração com a Rede Recy foi retirada: sem o contrato da API (endpoint, header de autenticação e formato do corpo), o código só devolvia
503e era código morto no repositório. Está no histórico do git se a Recy responder.
A jornada é simulada: as transações ficam num localStorage (chave raizes-mvp-v2) com signatures base58 encadeadas e slot incremental, reproduzindo o formato da Solana sem nenhuma dependência web3 — o app roda 100% offline. O cofre não é simulado: existe na Solana devnet como multisig nativo do SPL Token 2-de-3, e as liberações são executadas de verdade por duas organizações (ver onchain/). Em produção: mesma lógica, cofre Squads e carteiras Decaf.
Estado salvo de versões anteriores é descartado automaticamente se não tiver o formato atual, então o app nunca abre quebrado depois de uma atualização.
Para restaurar os dados da demo: botão Resetar demo no rodapé (traz também a proposta multisig de exemplo com 1 assinatura já coletada).
src/
main.jsx ponto de entrada Vite
App.jsx abas + rotas por hash (#/familia, #/rastreio/CÓDIGO)
estado/
store.jsx estado + reducer + cadeia de transações (base58/slot) + multisig
componentes/
ui.jsx toasts, modal, contadores animados, badges, estados vazios, confete
graficos.jsx barras (kg/semana) e donut (receita por fonte) em SVG puro
demo.jsx motor do modo demo guiado e card narrador
tour.jsx tour de primeira visita do painel (9 passos)
OnchainDevnet.jsx painel de liberações/fechamentos reais na devnet
lib/
qr.js gerador de QR Code real (Reed-Solomon), sem dependência
ancoragem.js hash SHA-256 do relatório + validação da assinatura Solana
evidencia.js SHA-256 da foto no aparelho + geolocalização
nuvem.js cliente do esquema compartilhado (Supabase)
sincronizacao.js fila offline-first entre aparelho e nuvem
auth.js sessão, papel e permissões da operação
i18n.jsx seletor e strings PT/EN
preferencias.js letra grande, voz do Tuca etc. (guardadas no aparelho)
voz.js Web Speech — números por extenso, sem emoji
estilos/
styles.css casco do painel + app da família
estilos-rastreio.css página pública de rastreio (PT/EN)
views/
Dashboard.jsx Coleta.jsx Validacao.jsx Mercado.jsx
Fundo.jsx Carteira.jsx PaginaFamilia.jsx Rastreio.jsx Cadastro.jsx
public/
manifest.json fica na raiz por convenção de PWA
sw.js fica na raiz — scope do service worker cobre o app inteiro
imagens/ logo.png, emblema.png
dados/ onchain.json (cópia gerada por onchain/implantar-devnet.mjs)
produtos/ fotos dos produtos reciclados (ver LEIA-ME.txt)
contracts/
FundoInfancia.sol contrato EVM, marcado como não implantado (piloto ficou só na Solana)
build/ bytecode compilado
onchain/
implantar-devnet.mjs cria o token cRED e o cofre multisig 2-de-3 na devnet
ancorar-relatorio.mjs grava o hash do relatório numa transação real
ancorar-decisao.mjs registra a decisão coletiva de fechamento de ciclo
liberar-bonus.mjs prepara/assina a liberação 2-de-3 do cofre
dados/ enderecos.json, ancoragens.json, liberacoes.json (gerados pelos scripts acima)
supabase/
schema.sql tabelas por entidade, transações append-only
migracoes/ 01 a 06, aplicadas em ordem no SQL Editor
scripts/ seeds e manutenção avulsos (não são migração)
testes/
executar.mjs runner do `npm test`
fluxo.mjs regras de negócio no reducer (sem navegador)
navegador.mjs app inteiro no Edge, via DevTools Protocol
qr.mjs QR gerado é decodificado por leitor independente
nuvem.mjs garantias do esquema, contra o Supabase real
migracoes.mjs inventário: o que o banco tem vs. o que o código supõe
autorizacao.mjs anônimo barrado, papel, consentimento (Supabase real)
canal-familia.mjs celular sem sessão contesta e a reclamação sai do aparelho
dois-aparelhos.mjs dois navegadores, um offline durante uma coleta
telas.mjs capturas para conferir o visual com o olho
npm test # tudo o que o ambiente permitir
npm test -- fluxo # só o reducer, em segundos
npm test -- navegador # só o app no navegador
npm test -- migracoes # quais migracoes estao aplicadas no banco
npm test -- autorizacao # RLS por papel e consentimento, no banco real
npm test -- canal # canal da família sem sessão, no banco real
npm test -- telas # grava capturas/ para conferir o visual
O runner sobe o servidor de desenvolvimento sozinho e o derruba no fim, e pula com aviso — em vez de falhar — quando falta Edge, internet, credencial do Supabase ou usuário de operação.
Pular não é passar. Suíte pulada aparece como ⏭️ no resumo e o runner diz explicitamente que aquela garantia não foi verificada — antes ela saía com código 0 e o resumo mostrava ✅ para uma suíte que não conferiu nada, o que é pior que vermelho.
Estado verificado contra o banco real, com sessão de operação (nenhuma suíte pulada):
| suíte | o que garante |
|---|---|
fluxo 233 | regras de negócio no reducer, sem navegador |
qr | o QR gerado é decodificado por leitor independente |
nuvem 39 | append-only real, idempotência de dinheiro, saldo como soma, CHECKs |
autorizacao 44 | anônimo barrado, papel, 2-de-3 por organização, ciclo do consentimento, canal da família |
canal 17 | celular sem sessão deposita e a operação recebe, sem o segredo vazar |
aparelhos 19 | dois navegadores, um offline durante uma coleta |
navegador 356 | app inteiro no Edge, em 1280px |
As suítes nuvem, aparelhos e a metade da operação do canal precisam de sessão da operação, porque a nuvem não responde mais a anônimo — por desenho.
O .env já vem apontando para um usuário de testes criado pela suíte, com senha gerada na hora — não é a senha de ninguém. Para ele funcionar, dois passos no painel do Supabase, uma vez só:
.env (SUPABASE_TEST_EMAIL) → confirme o usuário. Se ainda não existe, crie com Add user → Auto Confirm User: o signup pela API não serve, porque o projeto tem mailer_autoconfirm desligado e o remetente padrão do Supabase só entrega para membros do projeto.supabase/scripts/papel-usuario-de-teste.sql.Depois disso, npm.cmd test roda tudo. Se preferir usar uma conta de pessoa real em vez do usuário de testes, há duas formas de dar a senha, e a segunda é melhor:
# 1) gravada no .env (copie .env.exemplo). Simples, mas fica em disco.
npm.cmd test
# 2) digitada na hora, mascarada: não vai para disco nem para o histórico do shell
powershell -ExecutionPolicy Bypass -File testes\rodar-com-senha.ps1
O -ExecutionPolicy Bypass é necessário porque a política padrão do Windows bloqueia .ps1 — é o mesmo motivo pelo qual npm precisa ser chamado como npm.cmd aqui.
Sem dependências além de React + Vite no app. O @solana/web3.js vive num package.json separado em onchain/, então não entra no bundle do site; o esbuild é dependência de desenvolvimento, usada pelos testes.