Controladora. ZETAI WEB S.R.L., sociedade constituída segundo as leis do Paraguai (RUC 80159779-0), é a responsável pelas decisões de tratamento de dados pessoais relacionadas ao aplicativo e ao site/landing associados. Podemos contratar operadores para tratar dados em nosso nome, observando contratos e padrões internacionais de proteção de dados.
Âmbito territorial. Esta Política aplica-se globalmente.
Quando o aplicativo for oferecido a usuários localizados no Brasil, aplicam-se disposições adicionais específicas descritas no Anexo Brasil (LGPD), sem prejuízo deste texto principal.
Produto. Aplicativo móvel de carteira cripto não-custodial (“Wallet”) que permite ao usuário gerar e gerenciar endereços, assinar transações e interagir com redes blockchain compatíveis. Não mantemos custódia de ativos, seed phrase ou chaves privadas do usuário. As chaves são geradas e armazenadas localmente no dispositivo, sob controle exclusivo do titular.
Escopo do app.
Gerar e armazenar com criptografia local credenciais (seed/chave privada), assinar transações localmente e exibir saldos e históricos on-chain (dados públicos por natureza).
Conectar a DApps e serviços Web3 quando o usuário optar, mantendo o controle das chaves no dispositivo.
Este aplicativo não cria conta de usuário; as chaves e preferências permanecem no dispositivo. (Se futuramente houver criação de conta, será disponibilizada exclusão de conta e dados in-app e por URL pública, conforme exigências do Google Play – App Content.)
Escopo do site/landing.
Fornecer informações institucionais sobre a Wallet, documentação e canais de contato/suporte.
Quando houver formulários (ex.: contato), os dados enviados serão utilizados apenas para atendimento e suporte, conforme as seções “Finalidades e bases legais” e “Direitos do titular”.
O site/landing utiliza cookies apenas quando estritamente necessários ao funcionamento ou mediante consentimento expresso do usuário, conforme as boas práticas recomendadas por autoridades de proteção de dados (como o Guia de Cookies da ANPD).
Integrações de terceiros (visão geral).
A Wallet pode oferecer integrações opcionais com provedores externos:
On/off-ramp (fiat↔cripto/KYC): quando o usuário opta por comprar ou vender com moeda fiduciária, os parceiros atuam como controladores independentes, tratando dados segundo suas próprias políticas.
SDKs técnicos (diagnóstico/push): atuam como operadores, tratando dados em nosso nome para estabilidade e notificações, com termos de processamento específicos.
A lista nominal de parceiros/SDKs e os respectivos links para políticas estão na seção “Compartilhamento e Operadores.”
Conformidade com Google Play.
Esta Política descreve acesso, coleta, uso, compartilhamento e segurança de dados do aplicativo, inclusive por SDKs de terceiros, de forma idêntica ao que declaramos no Formulário “Data Safety” do Google Play Console.
Declaramos corretamente as Financial Features (software wallet e/ou exchange) e cumprimos formulários ou registros exigidos por jurisdição. Caso haja exigências não atendidas para algum país, a distribuição será restringida até a regularização.
Fora do escopo.
Não oferecemos custódia, recuperação de seed/chaves, execução de ordens financeiras em nome do usuário ou quaisquer serviços regulados sem base legal ou licença específica.
O usuário mantém posse e responsabilidade integral pela seed e pelas assinaturas — característica essencial de carteiras não-custodiais.
Modelo não-custodial. Esta Wallet é não-custodial: não guardamos, não acessamos e não conseguimos recuperar sua seed phrase (frase secreta) ou suas chaves privadas. Elas são geradas e permanecem no seu dispositivo, sob seu controle exclusivo. Se alguém obtiver sua seed/chave privada, terá controle total sobre os ativos; por isso nunca solicitaremos sua seed. Os mecanismos seguem padrões internacionais de segurança e privacidade de dados, compatíveis com as legislações das jurisdições em que o aplicativo é oferecido (incluindo Paraguai e Brasil)
Geração e armazenamento local. As credenciais (seed e chaves) são geradas no dispositivo do usuário e armazenadas em cofres criptográficos nativos do sistema:
Android: Android Keystore com suporte hardware-backed (TEE/StrongBox) quando disponível, com material criptográfico não-exportável e possibilidade de exigir autenticação do usuário para uso da chave.
iOS: Secure Enclave, um gerenciador de chaves isolado por hardware, usado para proteger chaves e operações criptográficas sensíveis.
Assinatura de transações. As transações são assinadas localmente: a chave privada não sai do dispositivo; apenas a assinatura é transmitida à rede. Os endereços e saldos são públicos por natureza da blockchain.
Backups e responsabilidade do usuário. O backup da seed é responsabilidade do titular. A Wallet não consegue recuperar nem redefinir seed/chaves. O usuário deve armazenar sua seed em local seguro, fora do dispositivo, e nunca compartilhá-la. (Padrão do setor para carteiras não-custodiais.)
Serviços opcionais de terceiros. Se o usuário optar por usar on-ramps (compra com moeda fiduciária), KYC, analytics, crash reports ou push, esses serviços são prestados por terceiros sob políticas próprias. Sempre indicaremos, de forma destacada, quais parceiros estão ativos. (Isso também deve estar coerente com o Data Safety do Google Play.)
Boas práticas técnicas adotadas. Implementamos medidas alinhadas às referências abertas de segurança móvel para evitar armazenamento inseguro de segredos e reduzir superfícies de ataque (por exemplo, proibir export de chaves, proteger arquivos de estado, checar root/jailbreak quando aplicável).
Declaração no Google Play (coerência). O comportamento descrito acima é refletido na seção Data Safety da ficha do app no Google Play: informamos com precisão quais dados ficam apenas no dispositivo (seed/chaves), quais dados podem ser coletados (se o usuário habilitar SDKs opcionais) e se há compartilhamento — garantindo consistência entre esta Política e o formulário do Play Console.
O que são: seed phrase, chaves privadas, material criptográfico e cofres locais do app.
Como tratamos: gerados e mantidos localmente; chaves marcadas como não-exportáveis; quando possível, uso vinculado à autenticação do usuário (biometria/PIN).
Android: Android Keystore com suporte a hardware (TEE/StrongBox); chave não-exportável e com restrições de uso (exigir autenticação; modos permitidos).
iOS: Secure Enclave/Keychain (CryptoKit), com isolamento por hardware e operações criptográficas sem expor o material de chave.
Declaração ao usuário: não temos acesso nem guardamos seed/keys; não é possível recuperar.
Data Safety (Play): declarar como “dados somente no dispositivo” (não coletados/compartilhados pelo app).
O que são: logs de falha, metadados técnicos (SO, versão do app), event breadcrumbs e stack traces.
Origem: SDKs como Firebase Crashlytics e/ou Sentry (configure para não enviar PII; retenção padrão do Crashlytics é curta, ~90 dias).
Como tratamos: somente se habilitado; finalidade exclusiva de estabilidade/diagnóstico; nunca inclui seed/keys.
Controles: documentar opt-out/desativação onde couber e minimizar chaves personalizadas.
Data Safety (Play): marcar coleta e finalidade “diagnóstico”, inclusive quando for via SDK de terceiro (auto-declaração precisa ser fiel).
Opcional separado: Push (FCM) coleta token de push e metadados técnicos apenas para entrega de notificações; se usar, declarar como coleta (finalidade “comunicação do app”). Ajuda do Google
O que são: endereços públicos, hashes, valores e eventos em redes suportadas.
Propriedade pública: blockchains públicas são transparentes e auditáveis (exploradores como Etherscan). O app não cria esses dados — apenas assina localmente e exibe.
Implicação: a privacidade é pseudônima; terceiros podem correlacionar endereços e comportamentos.
Data Safety (Play): não são “dados coletados do dispositivo”; são dados públicos consultados. Ainda assim, mantenha a descrição coerente no formulário.
O que são: identificação/KYC, meios de pagamento e verificações regulatórias quando o usuário opta por comprar/vender com moeda fiduciária.
Papel: parceiros como MoonPay, Transak e Alchemy Pay atuam como controladores independentes (definem finalidades e bases próprias; executam KYC/AML).
Transparência: listar nominalmente os parceiros ativos e linkar as políticas deles (na seção “Compartilhamento e Operadores” da sua Política).
Data Safety (Play): se houver SDK no app ou se você transmitir identificadores (e-mail, device ID, referral), isso vira coleta/compartilhamento pelo app e deve ser declarado com a devida finalidade.
1. Credenciais on-device (seed/chaves)
Finalidade: Gerar, guardar localmente e usar para assinar transações. As credenciais não saem do dispositivo.
Base legal: Execução de contrato (serviço de wallet). Não há tratamento fora do dispositivo.
Retenção: Apenas no dispositivo; o app não mantém cópias.
Terceiros / observações: Nenhum. Declarar no Data Safety como “dados somente no dispositivo”.
2. Uso / diagnóstico (Crashlytics, Sentry) — opcional
Finalidade: Estabilidade e correção de falhas; melhoria do aplicativo.
Base legal: Legítimo interesse (segurança/diagnóstico) ou consentimento quando o SDK exigir ou ativar rastreamento adicional.
Retenção: Tipicamente ~90 dias (Crashlytics) e até 180 dias se configurado; após esse prazo, dados anonimizados ou descartados.
Terceiros / observações: SDKs Crashlytics e Sentry. Devem ser listados na política e declarados no Data Safety com finalidades corretas.
3. Atividade no app (eventos agregados) — opcional
Finalidade: Métricas de produto e qualidade.
Base legal: Legítimo interesse (medição) ou consentimento (quando envolver IDs persistentes ou perfilamento).
Retenção: Mínimo necessário; preferir agregação e anonimização.
Terceiros / observações: Se usar Google Analytics ou outros terceiros, refletir coleta e compartilhamento no Data Safety.
4. Token de push (FCM) — opcional
Finalidade: Enviar notificações solicitadas (por exemplo, alertas de versão).
Base legal: Consentimento (opt-in no primeiro uso).
Retenção: Até revogação ou desinstalação; limpeza periódica de tokens inválidos.
Terceiros / observações: Firebase Cloud Messaging. Declarar no Data Safety como “identificadores do dispositivo/contato”.
5. Dados on-chain (públicos)
Finalidade: Executar e exibir transações/saldos em redes blockchain suportadas.
Base legal: Execução de contrato. Os dados são públicos por natureza da blockchain.
Retenção: Indefinida (registro público on-chain).
Terceiros / observações: Não é coleta do dispositivo; o app apenas lê e exibe. Manter coerência no Data Safety.
6. Suporte / atendimento (e-mails, anexos) — opcional
Finalidade: Responder solicitações do usuário e cumprir direitos de titulares.
Base legal: Execução de contrato e obrigação legal (respostas a solicitações).
Retenção: 12 – 24 meses conforme política interna; depois, descarte.
Terceiros / observações: Canal de suporte deve permitir o exercício de direitos. Para o Brasil, observar prazos do art. 19 da LGPD (confirmação imediata e resposta completa em até 15 dias).
7. On-ramp / KYC / pagamentos — opcional e fora do app
Finalidade: Compra de cripto com moeda fiduciária e verificação de identidade quando exigida.
Base legal: Controlador independente (parceiro on-ramp) com bases próprias — obrigação legal/regulatória e execução de contrato.
Retenção: Conforme política e regulação do parceiro.
Terceiros / observações: Listar parceiros e links de políticas (MoonPay, Transak, Alchemy Pay). Declarar coleta/compartilhamento no Data Safety se houver SDK ou envio de identificadores. Também declarar na seção Financial Features do Play Console.
Regra de ouro
Controladores independentes (compartilhamento): provedores de on/off-ramp (fiat↔cripto) que executam KYC/AML e definem finalidades próprias. Seus dados são tratados diretamente por eles, segundo as políticas deles.
Operadores (processadores): SDKs técnicos que tratam dados em nosso nome para fins de diagnóstico/estabilidade ou push — com DPA/termos específicos.
Ativados somente quando o usuário opta por comprar/vender com moeda fiduciária. Incluem verificações KYC/AML e requisitos regulatórios próprios.
Os provedores abaixo atuam como controladores independentes, com políticas e bases legais próprias. O tratamento de dados ocorre diretamente com eles quando o usuário opta por comprar ou vender criptomoedas com moeda fiduciária (fiat).
A Wallet não acessa nem armazena dados de identificação, documentos ou comprovantes enviados nesses fluxos.
Parceiro: MoonPay
Papel: Controlador independente
Dados tratados: Identidade, dados de pagamento, informações de conformidade e verificações KYC/AML.
Finalidade: Processar transações de compra e venda de criptoativos (on-ramp/off-ramp), aplicar controles regulatórios (KYC/AML), auditorias e comunicações obrigatórias (SARs).
Política e evidência: Política de Privacidade e materiais públicos da MoonPay sobre KYC/AML.
Parceiro: Transak
Papel: Controlador independente
Dados tratados: Identidade, níveis de verificação KYC, informações de pagamento e dados de conformidade.
Finalidade: Processamento de transações on/off-ramp e execução de verificações KYC de múltiplos níveis.
Política e evidência: Política de Privacidade, Central de Ajuda de KYC e documentação sobre Light KYC.
Parceiro: Alchemy Pay
Papel: Controlador independente
Dados tratados: Identidade e informações de pagamento, quando aplicável.
Finalidade: Execução de serviços on-ramp (compra de cripto com moeda fiduciária) e processamento de pagamentos globais.
Política e evidência: Política de Privacidade e documentação pública sobre o serviço de On-Ramp.
Observação:
Esses provedores cumprem regulações locais de prevenção à lavagem de dinheiro (AML) e de verificação de identidade (KYC) e operam sob suas próprias políticas de privacidade. O app apenas redireciona o usuário para o ambiente do parceiro ou integra SDKs quando necessário, sempre informado de forma transparente no Data Safety do Google Play.
Nota de coerência (Google Play). Integrações via SDK (ou quando transmitimos identificadores para um parceiro, inclusive em WebView sob nosso controle) configuram coleta/compartilhamento pelo app e são declaradas no Data Safety (tipos de dados e finalidades). Quando apenas redirecionamos o usuário para um serviço de terceiro e não acessamos/transferimos dados, a coleta ocorre diretamente pelo terceiro sob a política dele — e esse fluxo não é declarado como coleta pelo app. Mantemos a seção do Data Safety sincronizada com esta Política.
Ativados apenas para funções técnicas. Configuramos para minimizar dados e evitar PII desnecessária.
O aplicativo utiliza SDKs técnicos apenas para funções essenciais de estabilidade, notificações e monitoramento de erros. Todos os SDKs atuam como operadores, processando dados em nosso nome, de acordo com seus respectivos Acordos de Processamento de Dados (DPAs) e Cláusulas Contratuais Padrão (SCCs).
Fornecedor: Firebase Crashlytics (Google)
Papel: Operador
Dados tratados: Logs de falha, stack traces, identificadores técnicos (Installation UUID) e minidumps NDK temporários.
Finalidade: Diagnóstico e estabilidade do aplicativo, depuração de erros e prevenção de falhas.
Termos e práticas: Conforme a Política de Privacidade do Firebase e os Data Processing Terms da Google. Retenção padrão aproximada de 90 dias para logs de falhas.
Fornecedor: Firebase Cloud Messaging (FCM)
Papel: Operador
Dados tratados: Token de push e metadados técnicos do dispositivo.
Finalidade: Envio de notificações solicitadas pelo usuário (ex.: atualizações ou alertas de sistema).
Termos e práticas: Criptografia ponta a ponta (TLS) e conformidade com os requisitos de divulgação do Data Safety do Google Play
Fornecedor: Sentry (erro/performance)
Papel: Operador
Dados tratados: Eventos de erro, métricas de performance, URLs e metadados técnicos com data scrubbing habilitado (remoção de PII).
Finalidade: Monitoramento de erros e desempenho do aplicativo para aprimorar estabilidade e desempenho.
Termos e práticas: Conforme a Privacy Policy e o DPA do Sentry, que incorporam SCCs e detalham medidas técnicas e organizacionais de segurança.
Observação: Nenhum desses SDKs acessa ou armazena seed phrases, chaves privadas ou qualquer informação pessoal sensível do usuário. Todos os dados processados têm caráter técnico e limitado à operação segura do aplicativo.
Observação sobre push (transparência): metadados de push podem ser objeto de requisições legais a Apple/Google; conteúdo da notificação não vai nos registros, mas tokens/metadata podem ser requisitados por autoridades. Documentamos isso como risco residual.
Para garantir o funcionamento correto e seguro da Wallet, o aplicativo pode solicitar certas permissões de dispositivo.
Todas as solicitações são realizadas com consentimento explícito do usuário e apenas quando necessárias para a execução de recursos específicos.
O aplicativo solicita apenas as permissões estritamente necessárias para seu funcionamento. Todas são apresentadas pelo sistema operacional com aviso e opção de recusa.
Permissão: Câmera
Finalidade: Capturar imagens para leitura de QR Codes de endereços de carteira ou, quando o usuário opta por integrações de compra/identificação (on-ramp KYC), para verificação facial ou documentos.
Condição de uso: Solicitada somente durante o uso dessas funções; o usuário pode negar sem afetar o restante do app.
Compartilhamento: As imagens capturadas para KYC são tratadas diretamente pelos parceiros on-ramp (MoonPay, Transak, Alchemy Pay) conforme suas próprias políticas.
Permissão: Microfone
Finalidade: Em casos de verificação KYC de voz ou gravação curta exigida por provedores parceiros.
Condição de uso: Somente quando o usuário inicia um processo de verificação que exige áudio.
Compartilhamento: O áudio é enviado diretamente ao parceiro KYC; a Wallet não armazena gravações.
Permissão: Armazenamento / arquivos locais
Finalidade: Salvar exportações de seed ou comprovantes locais (quando o usuário gera manualmente backup criptografado).
Condição de uso: Permissão solicitada apenas durante a exportação.
Compartilhamento: Os dados permanecem no dispositivo, sem envio a servidores.
Permissão: Rede (Internet)
Finalidade: Comunicação com blockchains públicas e serviços de parceiros (on/off-ramp, verificação de saldo, taxas).
Condição de uso: Necessária para o funcionamento básico do app.
Compartilhamento: Conexões protegidas (TLS) e logs sem informações pessoais (PII).
Importante: nenhuma dessas permissões é usada para coleta oculta de dados ou monitoramento. Todas as funções dependem de ação consciente do usuário, e o sistema operacional exibe as solicitações antes de conceder acesso.
Podemos realizar transferência internacional de dados quando necessário para prover o serviço (ex.: uso de infra/SDKs com servidores localizados fora do Paraguai ou do país do usuário). Nesses casos, seguimos padrões internacionais de proteção de dados e, quando aplicável a usuários localizados no Brasil, também as disposições da LGPD (arts. 33–36) e da Res. CD/ANPD nº 19/2024, que disciplina decisões de adequação e mecanismos contratuais (como Cláusulas-Padrão Contratuais – SCCs/CCPs).
Como garantimos conformidade
Hipóteses legais (LGPD 33–36). Realizamos transferências internacionais apenas quando necessárias e amparadas por uma base legal ou contrato adequado, como: (i) país/organismo com nível adequado; (ii) garantias contratuais (p.ex., SCCs/CCPs); (iii) consentimento específico do titular; (iv) execução de contrato; ou outras hipóteses previstas em lei.
Cláusulas-Padrão Contratuais (SCCs/CCPs) e acordos internacionais equivalentes. Quando não há decisão de adequação, firmamos Cláusulas-Padrão Contratuais conforme os anexos da Resolução, para assegurar nível de proteção equivalente no país de destino. Para titulares localizados no Brasil, aplicamos as SCCs/CCPs da Resolução CD/ANPD nº 19/2024.
Compromissos dos fornecedores (exemplos).
Google/Firebase (Crashlytics/FCM): operamos sob os Data Processing & Security Terms e SCCs disponibilizados pela Google/Firebase.
Sentry (erros/performance): operamos sob DPA com SCCs e documento de transferências internacionais (DPF/SCCs conforme a jurisdição).
Transparência e direitos do titular. Mantemos transparência sobre provedores e países envolvidos e preservamos direitos como acesso, correção, eliminação e portabilidade; o titular pode solicitar informações sobre as salvaguardas contratuais aplicadas, por meio dos canais do Encarregado (DPO).
Minimização e necessidade. Limitamos a transferência ao mínimo necessário (ex.: telemetria técnica de crash, tokens de push), priorizando processamento local e pseudonimização/anonimização. Mantemos coerência com o formulário Data Safety no Google Play.
Evolução regulatória. Monitoramos atualizações de autoridades de proteção de dados e legislações aplicáveis (incluindo eventuais normas do Paraguai, da ANPD e da União Europeia)
Princípio geral. A Wallet é não-custodial: seed e chaves privadas ficam apenas no dispositivo e são usadas localmente para assinar transações. O app implementa controles de confidencialidade, integridade e resiliência alinhados às referências da OWASP MASVS/MASTG.
Android Keystore (hardware-backed/StrongBox quando disponível): geração/armazenamento de chaves não-exportáveis; restrições de uso por algoritmo, propósito e exigência de autenticação do usuário (PIN/biometria) ao utilizar a chave.
iOS Secure Enclave / Keychain (CryptoKit): chaves isoladas por hardware; operações criptográficas sem expor material chave à CPU/app; armazenamento no Keychain com atributos de acesso.
Derivação/uso: chaves de sessão (DEK) protegidas por chaves do Keystore/Keychain (KEK); nunca registrar/serializar seeds/chaves em logs, crash reports ou analytics. (Ver guias MASTG “Data Storage”.)
Vincular ao usuário: onde for adequado, configurar chaves bound-to-auth (uso exige BiometricPrompt/lockscreen; atentar para invalidação ao mudar biometria/senha).
Em repouso (at-rest): qualquer dado sensível auxiliar (ex.: rótulos locais, preferências que indiquem contas) cifrado com AES-GCM via chaves do Keystore/Keychain. Diretriz: zeroização de memória após uso. (OWASP MASTG – armazenamento.)
Em trânsito (in-transit): TLS moderno. Pinning: avaliar com cautela; o Android não recomenda pinning rígido por risco operacional (quebras em troca de CA). Se adotar, gerenciar via Network Security Config (pin-by-SPKI, períodos de sobreposição).
Play Integrity API: validar no backend se requests vêm de app íntegro, instalado pela Play Store e em dispositivo certificado; reagir a sinais de risco (emulação, tampering). Integrável também via Firebase App Check.
Hardening contra engenharia reversa: aplicar ofuscação/minificação e verificações de integridade do binário, conforme MASVS-RESILIENCE (sem “security through obscurity” como único controle).
Detecções de risco: sinalizar root/jailbreak, debug ativo, hooking frameworks; degradar funcionalidades sensíveis quando necessário (conforme MASVS).
Logs/Crash: nunca incluir seed/chaves/endereços de recuperação; configurar Crashlytics/Sentry para scrubbing e retenção mínima de minidumps.
Clipboard/Screenshots: evitar copiar seed automaticamente; opcionalmente bloquear screenshots em telas de seed (avaliando UX).
Teclados de terceiros: desabilitar em campos de seed (Android: FLAG_SECURE/TYPE_TEXT_FLAG_NO_SUGGESTIONS) quando aplicável, reduzindo telemetria indevida.
Assinatura e distribuição: utilizar Play App Signing e política de rotação de chaves conforme necessário; revisar libs nativas e SDKs quanto a permissões e coleta de dados (consistência com Data Safety).
Ciclo seguro (SDLC): incorporar checklist MASVS e testes MASTG em PRs e releases; pentest periódico; automações de SAST/DAST móveis.
Biometrias e bloqueio: usar BiometricPrompt (Android 9+) e chaves auth-bound; no iOS, Secure Enclave + Keychain Access Control (CryptoKit). Seguir diretrizes de UX/acessibilidade e NIST SP 800-63B para fatores/erros.
Observação: Quando o aplicativo for oferecido a usuários localizados no Brasil, as transferências internacionais relativas a esses dados seguem também as disposições específicas do Anexo Brasil (LGPD), que detalha as salvaguardas exigidas pela legislação brasileira.
Sem backup automático de seed: nunca sincronizar seed/chaves com nuvem. Exportação somente manual, sob controle do usuário, com passphrase forte e aviso de riscos. (Prática setorial; ver restrições de chave não-exportável.)
Play Integrity + telemetria mínima para detectar abuso/tampering; plano de resposta com remoção de versões comprometidas, invalidação de sessões e comunicação a usuários quando cabível.
Seus direitos (conforme legislação aplicável). O titular pode, a qualquer momento, exercer: confirmação de tratamento, acesso, correção, eliminação ou bloqueio de dados desnecessários/excessivos, portabilidade, informação sobre compartilhamentos, revogação de consentimento e oposição a tratamentos irregulares. Esses direitos são exercidos mediante requisição expressa ao controlador. Quando o tratamento envolver usuários localizados no Brasil, também se aplicam os direitos previstos no art. 18 da LGPD.
Prazos de resposta. Para confirmação de existência ou acesso:
Atenderemos solicitações dentro de prazos razoáveis conforme a legislação aplicável.
Para titulares localizados no Brasil, observamos os prazos do art. 19 da LGPD:
Confirmação ou acesso simplificado: imediato;
Declaração completa (origem, critérios e finalidades): até 15 dias do pedido.”
Como solicitar. Envie uma requisição com: (i) direito desejado; (ii) identificação suficiente (podemos pedir verificação adicional para evitar fraude); (iii) detalhes que nos ajudem a localizar os dados. Canal oficial:
E-mail do Encarregado (DPO): [dpo@zetaiweb.com]
Papel do Encarregado (DPO). Nomeamos um Encarregado como canal de comunicação entre a ZETAI WEB, os titulares e eventuais autoridades de proteção de dados, incluindo a ANPD quando aplicável. Suas atribuições incluem receber e responder requisições de titulares, receber comunicações da ANPD e orientar a equipe sobre práticas de proteção de dados. Identidade e contato do DPO devem ser divulgados publicamente (site/app).
Escopo e limitações.
Responderemos às solicitações sem custos, salvo pedidos manifestamente infundados/excessivos.
Podemos negar ou restringir o atendimento quando houver impedimento legal, segredo comercial/industrial, direitos de terceiros ou quando os dados forem anonimizados. Explicaremos o fundamento quando aplicável.
Reclamações à Autoridade. Caso entenda que seu pedido não foi atendido, o titular pode entrar em contato conosco pelos canais acima e, quando aplicável, reclamar perante a autoridade competente de seu país de residência (no Brasil, ANPD). A ANPD mantém material público sobre direitos dos titulares e formas de contato.
Boas práticas adicionais.
Manteremos registro dos atendimentos e prova de resposta dentro dos prazos legais;
Disponibilizamos informação clara sobre tratamento, inclusive uso de cookies no site/landing (com consentimento ou outra base adequada, conforme boas práticas de proteção de dados e, para o Brasil, o Guia de Cookies da ANPD).
Este aplicativo não é destinado a crianças nem a menores de 18 anos.
Por se tratar de um produto financeiro e de gestão de criptoativos, requer capacidade civil plena e aceitação dos Termos de Uso.
Implementamos um age-gate simples (confirmação de maioridade) para reforçar essa restrição e atender às regras de classificação etária do Google Play/IARC.
A Wallet não coleta, armazena ou trata dados de menores, não exibe publicidade e não contém qualquer conteúdo visual, educativo ou lúdico voltado a esse público.
Se, por erro ou uso indevido, identificarmos interação de menor de idade, os dados serão eliminados imediatamente, preservando apenas registros técnicos mínimos quando houver obrigação legal ou de segurança.
Como tratamos mudanças. Esta Política pode ser atualizada para refletir alterações de produto, SDKs/fornecedores, requisitos legais ou de plataforma (Google Play). Mantemos versão, data de publicação e data de vigência no topo do documento e arquivamos versões anteriores em URL pública. Isso segue o princípio da transparência e da boa-fé previsto nas legislações de proteção de dados aplicáveis.
Quando avisamos o usuário.
Mudanças materiais (ex.: nova categoria de dado pessoal, novo compartilhamento com terceiros, nova finalidade, base legal diferente, tratamento que requeira novo consentimento): comunicaremos com destaque (aviso no app/site e, quando aplicável, e-mail/alerta in-app) antes da vigência. Onde a base legal for consentimento, solicitaremos novo aceite.
Mudanças não materiais (ajustes de redação/organização sem impacto no tratamento): publicaremos a nova versão com indicação de “última atualização”.
Coerência com Google Play. Qualquer mudança que afete coleta/uso/compartilhamento (inclusive por SDKs de terceiros) será refletida imediatamente na seção Data Safety do Google Play. O Google exige que as informações sejam exatas e atualizadas; discrepâncias podem levar a rejeição/ação de compliance. Essas atualizações também são comunicadas no formulário Data Safety e, quando aplicável, nas Financial Features do Play Console.
Critérios objetivos para mudança material (legislação aplicável). Consideramos material quando ocorrer qualquer um dos itens abaixo:
inclusão de nova categoria de dado pessoal (ex.: identificadores persistentes, dados de contato);
alteração de finalidade ou base legal;
início de compartilhamento com novo controlador (ex.: parceiro on-ramp adicional) ou troca relevante de operador (SDK) com escopo de dados distinto;
ampliação de retenção;
introdução de decisão automatizada que afete o titular;
mudança que impacte os direitos ou a capacidade de controle do titular (transparência/consentimento).
Como o titular acompanha.
Exibimos banner de alteração por período razoável após a vigência, linkando para “O que mudou nesta versão”;
Mantemos histórico de versões com changelog;
Disponibilizamos canais do Encarregado (DPO) para dúvidas, contestação e exercício de direitos conforme a legislação aplicável.
Exigências específicas do Play (exemplos).
Mudanças em controles de privacidade (ex.: fluxo de exclusão de conta/dados ou de opt-out) também devem ser refletidas na ficha do app conforme as regras vigentes do Play.
Também revisamos a classificação etária (IARC) e as declarações de privacidade do app, se qualquer alteração afetar o público-alvo ou a forma de tratamento de dados.
Versão: [ex.: 1.0.0]
Publicado em: [03/11/2025]
Vigente a partir de: [03/11/2025]
Declaração de coerência.
Esta Política mantém coerência total com o que declaramos no Formulário “Data Safety” do Google Play Console, descrevendo de forma idêntica os tipos de dados que o app coleta, usa e compartilha (inclusive via SDKs de terceiros), suas finalidades, bases legais e medidas de segurança. Mantemos essas declarações precisas e atualizadas sempre que houver qualquer mudança de produto, parceiros/SDKs, políticas de privacidade de terceiros ou configurações de coleta e armazenamento. Essa prática garante transparência contínua e conformidade com as regras globais de privacidade e com as políticas de publicação do Google Play.
Onde o usuário encontra isso.
Na ficha do app no Google Play, seção “Data safety” (sincronizada a partir do formulário do Play Console).
Dentro do app: Configurações → Privacidade → “Como tratamos seus dados (Data Safety)”, com link para a ficha do Play e para esta Política. (O Play exige transparência e consistência entre o formulário e sua política pública.)
O link para esta Política também pode ser acessado diretamente a partir da tela inicial de configurações da Wallet, em conformidade com o requisito de acessibilidade de política pública do Google Play.
Finanças (wallet/exchange).
Declaramos, no App content → Financial features, que o app é software wallet e/ou exchange, cumprindo exigências e eventuais formulários específicos por país. Caso existam restrições regulatórias ou ausência de licença específica em determinadas jurisdições, a Wallet não será disponibilizada nesses países até que as exigências sejam devidamente cumpridas. Também declaramos essas restrições no campo ‘Financial Features’ do Play Console, conforme as exigências de transparência e conformidade internacional.