Desenvolvimento local
Chains EVM locais que emulam as testnets públicas, dados de demo pelo pipeline real e as duas suítes de aceitação.
Última atualização 27 de out. de 2026
Você precisa de Docker (Postgres + Redis), Bun e Foundry para o anvil (brew install foundry, ou curl -L https://foundry.paradigm.xyz | bash && foundryup).
Chains locais: bun run chain:dev
apps/server/scripts/chain/dev.ts sobe um anvil por rede de teste com o chainId real (Polygon Amoy 80002 em :18002, BSC Testnet 97 em :18097, Base Sepolia 84532 em :18532) e planta uma stablecoin mock em cada endereço de token canônico com anvil_setCode. O servidor roda o mesmo registry e os mesmos caminhos de código que usa nas testnets públicas; só a URL de RPC muda.
- As contas padrão #1–#3 do anvil são os compradores: cada uma tem 1.000.000 de cada token em cada chain.
- A hot wallet (índice 0 de
CRYPTO_MASTER_MNEMONIC) recebe gas nativo. - Flags:
--block-time 2(padrão, mineração por intervalo),--block-time 0(um bloco por transação; os testes mineram comanvil_mine),--mainnets(adiciona os chainIds 137 / 56 / 8453 em:18137/:18056/:18453para demos locais em modo live),--fresh(apaga o estado persistido emscripts/chain/.state/).
Aponte o servidor para elas em apps/server/.env:
CRYPTO_MASTER_MNEMONIC="depend mechanic screen brush dust raven sure found body super chronic parrot" # public dev mnemonic
CRYPTO_RPC_POLYGON_AMOY=http://127.0.0.1:18002
CRYPTO_RPC_BSC_TESTNET=http://127.0.0.1:18097
CRYPTO_RPC_BASE_SEPOLIA=http://127.0.0.1:18532e, opcionalmente, passe os mesmos RPCs para o botão de wallet do checkout (apps/client/.env.local: NEXT_PUBLIC_CRYPTO_RPC_POLYGON_AMOY=http://127.0.0.1:18002, …), para que uma wallet de navegador possa adicionar a chain local.
Depois rode a API (bun run dev) e o worker (bun run --cwd apps/server worker): sem o worker nada é escaneado, varrido pelo sweep ou enviado.
Dados de demo: bun run crypto:demo
apps/server/scripts/crypto-demo.ts preenche uma stack em execução com a história da Glyphyard pelo pipeline real (API de merchant, API pública do checkout e transfers ERC-20 reais a partir das wallets dos compradores): os vendedores Halden Type, Kiso Foundry, Pampa Type, Ribbon & Rule, Osaro Studio, o parceiro Kerning Weekly, dois payment links e invoices em todos os estados (pagas em várias redes, paga a mais com um refund resgatável, paga a menos, pendente, expirada, reembolsada, uma ainda confirmando), além de um payout concluído. É idempotente e leva cerca de 2,5 minutos. Roda na org acme do seed (entre como [email protected] / password123).
Os seus padrões são --api http://localhost:3405 --checkout http://localhost:3404; com as portas padrão passe --api http://localhost:3005 --checkout http://localhost:3004. --webhook-url <url> também registra um endpoint de webhook.
Aceitação: bun run --cwd apps/server crypto:e2e
A definição de pronto da fase 1, no nível da API, cerca de 1:35. Ela sobe a sua própria stack isolada (um schema Postgres descartável, Redis DB 9, três chains anvil nas portas +100 com um bloco por transação, a API em :3105 e o worker) e verifica cada resultado on chain e no ledger: criação idempotente de invoice, visualização pública, pagamento, DETECTED → PAID, as linhas do ledger 90 / 10 / 2 / 0.50, um webhook assinado, um transfer com token errado em escrow e devolvido no seu próprio token, o sweep, um payout, e paga a menos → expirada → refund resgatado (endereço de contrato rejeitado). Ela imprime ALL PASSED e sai com 0 apenas se todos os passos passaram.
Suíte de navegador: bun run e2e:crypto
Cinco specs do Playwright (tests/e2e/crypto-*.spec.ts) conduzem a UI real contra chains locais:
| Spec | Cobre |
|---|---|
crypto-checkout | escolher um par → Pay with wallet (um provider EIP-1193 injetado, apoiado no anvil; começa em outra chain, então a troca acontece) → DETECTED → recibo PAID com a barra de split → invoice imprimível; o valor exato saiu do comprador on chain |
crypto-refund | paga a menos → expirada → refund retido na página pública (sem link) → link de resgate pela API de merchant → o portal rejeita um contrato, paga uma EOA on chain |
crypto-dashboard | overview em modo Test → detalhe da invoice: resumo, ledger balanceado, aba Technical com claim_url oculto |
crypto-payout | ativar 2FA em Settings → New payout com um código TOTP → COMPLETED, valor líquido no destino on chain |
crypto-payment-link | criar um link no dashboard → /l/:slug → checkout → PAID, contagem de vendas 1 |
tests/scripts/run-e2e.ts com E2E_CRYPTO=1 cria e migra um schema isolado, faz o seed, sobe as chains (portas +200, um bloco por transação) e o worker no Redis DB 10, e roda a API em :3205 e o client em :3204, então pode rodar ao lado de bun run dev e chain:dev. As specs mineram as confirmações por conta própria. Se outro next dev já estiver rodando em apps/client (o Next.js permite um por diretório), use E2E_CLIENT_MODE=start para servir um next build novo (E2E_SKIP_CLIENT_BUILD=1 reaproveita o último). O Playwright roda em Node, não em Bun: coloque um Node real primeiro no PATH.
Testnets públicas
Defina CRYPTO_RPC_<NETWORK> com RPCs públicos (veja apps/server/.env.example) para rodar o caminho de leitura contra Amoy, BSC Testnet e Base Sepolia. A Amoy não tem USDT canônico (o contrato de USDT da Amoy existe apenas nas chains locais), então pague as invoices da Amoy em USDC lá. Os padrões do scanner (intervalos de 200 blocos, divididos pela metade quando o provider limita) são dimensionados para esses providers; a evidência está em docs/superpowers/specs/2026-10-27-public-testnet-smoke.md.