Cookie de sessão CSRF
Um cookie aleatório nsw pela duração da sessão do navegador. Usado apenas para proteger a API de criação de pedidos. Nenhum identificador dentro.
Transparência
Como isso realmente funciona.
Especificidades sobre a arquitetura, os dados e a política de sinalização. Se você se importa se "sem logs" é um slogan ou uma descrição, esta página é para você.
Arquitetura
Um frontend fino sobre um camada de roteamento
O NoKYCSwap é um frontend em PHP 8.2 sobre um agregador de liquidez de terceiros. Não há banco de dados — sem tabela de usuários, sem tabela de pedidos, nada relacional. O estado efêmero dos pedidos vive como arquivos JSON planos no sistema de arquivos, apagados na liquidação.
O único armazenamento persistente além disso é um cache em sistema de arquivos para cotações (TTL de 60 segundos) e para a lista de moedas (TTL de 5 minutos).
Cada pedido é uma capability: o ID do pedido mais um token retornado pelo backend. Você guarda a URL com esses valores; nós guardamos o endereço de depósito correspondente e um timestamp. Nada mais.
Sem analytics. Sem fingerprinting. Sem ID de usuário persistente. O roteador upstream vê o mínimo de metadados de swap necessários para executar — e nada correlaciona você entre sessões.
Inventário de dados
O que nós record
Todos os campos que tocamos, listados. Sem gavetas escondidas.
Registro do pedido
Par, valor, endereço de depósito, endereço de pagamento, tipo (flutuante/fixa), timestamp de criação. Apagados na liquidação (ou após 30 dias no máximo).
Contadores antiabuso
Contadores de limite de taxa por IP, reiniciados a cada minuto. Nunca vinculados a dados pessoais.
Logs de acesso do Nginx
Método, caminho, status, user-agent. Rotacionados a cada 24 horas.
O que nós never record
Nome, e-mail, telefone, identidade, data de nascimento, nacionalidade
Qualquer tag de analytics de terceiros (sem GA, sem Hotjar, sem Segment, sem Meta Pixel)
Cookies de rastreamento além do token de sessão CSRF
Logs de IP de longo prazo (rotação < 24h)
Impressões digitais de dispositivo ou navegador
Qualquer identificador de correlação entre sessões
Sinalização
O que acontece quando um pedido é sinalizado
1
O pedido entra no estado Emergência
O roteador upstream filtra endereços de depósito contra listas de sanções e feeds de fluxos ilícitos. Se um endereço coincidir, a página do pedido exibe ações de emergência.
2
Duas opções, ambas sob seu controle
Reembolso para um endereço que você fornecer (sem perguntas), ou aceitar a taxa de mercado atual e continuar. Você decide. Não há uma terceira opção escondida.
3
Nunca uma exigência de identidade
Não pedimos documentos de identidade nesta fase. Jamais. Se ambas as ações forem rejeitadas, o depósito é devolvido ao endereço de remetente visível on-chain.
Terceiros
Todos os serviços externos chamamos
CDN / TLS (rede)
Cloudflare
Serve ativos estáticos. TLS termina na Cloudflare; recebemos o IP real do cliente via CF-Connecting-IP apenas para limitação de taxa.
Fontes web
fonts.bunny.net
Inter e JetBrains Mono. Um espelho do Google Fonts respeitoso com a privacidade que não registra IPs.
Roteador de liquidez
ff.io
Recebe os metadados da solicitação de swap necessários para executar: par, valor, destino, endereço opcional de reembolso. Assinados com HMAC.
Postura de segurança
Endurecimento em um relance
- Apenas HTTPS com configuração elegível a preload HSTS.
- Content-Security-Policy estrita; sem scripts inline além de payloads JSON.
- X-Frame-Options SAMEORIGIN · X-Content-Type-Options nosniff · Referrer-Policy estrita.
- Permissions-Policy restringe geolocalização, microfone, câmera e pagamento para "none".
- Tokens CSRF em todos os endpoints de API que alteram estado.
- Toda configuração sensível (chaves de API, material de assinatura) fica fora do webroot.
Relatórios de segurança: [email protected]. Veja também security.txt e a política completa de divulgação.
