Aviso de privacidade

Última atualização: 3 de outubro de 2026 · Bernuvia

A versão vinculativa deste documento é a inglesa. A versão espanhola foi redigida por nós; as versões em outros idiomas são traduções automáticas de cortesia geradas pela plataforma.

1. O que é este aviso e do que não fala

1.1. Este aviso explica quais dados tratamos, por que, com quem os compartilhamos e o que você pode nos pedir. Aplica-se ao site, à API, às interfaces públicas (a API pública do catálogo e nosso arquivo de registro público), aos webhooks e ao servidor MCP.

1.2. Está escrito a partir da arquitetura real do produto: cada coisa que diz corresponde a um dado que realmente existe em nossa base, a um cookie que realmente é colocado, ou a um fornecedor que realmente recebe algo.

1.3. O que acontece dentro dos templates que você compra não tratamos nós. Se você implanta um template e coleta dados de seus usuários, o responsável por esse tratamento é você.

1.4. Para qualquer assunto deste aviso, escreva-nos pelo formulário de contato com a categoria de proteção de dados. Essa categoria não está sujeita ao limite de uma mensagem por dia e comunicamos o resultado por e-mail.

2. Quais dados guardamos

2.1 Sua conta

E-mail, obrigatório e único: é a chave da sua conta e da sua wallet, e por isso não pode ser alterado.
Nome e nome de usuário público (seu *handle*), que também é seu código de referência. Guardamos também seus handles anteriores, para que ninguém possa reivindicar um que você soltou e herdar seus links.
Iniciais e avatar, se você optar por colocar. Se você entrar com Google ou GitHub, o avatar pode ficar vinculado ao servidor de imagens desse provedor.
Identidade social, se você entrar com Google ou GitHub: o provedor e seu identificador estável nesse provedor.
Verificação em duas etapas: o segredo TOTP, guardado criptografado, e os códigos de backup, guardados como impressões digitais. Nunca vemos seus códigos.
Preferências de idioma e de tema, seu papel na plataforma e as datas de criação, de aceitação das condições e, se houver, de suspensão.
Quem te convidou, se você chegou por um link de referência, e quando.

2.2 Sua wallet e suas operações

O endereço público da sua wallet de Polygon, e a última vez que se conectou. Um endereço não pode pertencer a duas contas. Em uma conta criada por assinatura de wallet (seção 2.14), esse endereço é o identificador da conta: não há e-mail nem nome por trás.
De cada ordem: o identificador, o modelo, o comprador, o vendedor, os endereços públicos das duas partes, o valor, a comissão aplicada, o prazo de revisão, o estado, a cotação assinada e os identificadores das transações na cadeia.
De cada compra já entregue: o modelo, o valor e a data.
De sua associação de vendedor: o plano, o período, os recebimentos, as tentativas falhadas e as datas de lembrete, carência e cancelamento.
Os eventos de suas ordens e das liberações automáticas, para poder reconstruir o que aconteceu e quando.

2.3 Disputas e provas

O dossiê de cada disputa: quem a abriu, quando, o motivo que você escreveu e os prazos aplicáveis.
As provas apresentadas pelas partes: o nome do arquivo, seu tipo, seu tamanho, a impressão digital que declara quem a enviou, uma nota de texto e a referência ao arquivo em nosso armazenamento privado. Os arquivos não são públicos: são abertos apenas a partir do dossiê.
As decisões do comitê: a postura de cada pessoa, a distribuição decidida, o motivo com as etiquetas públicas e o identificador da transação que a executou.
O comitê vê o dossiê completo, incluindo se o comprador baixou o modelo.

2.4 O que você publica

De seus modelos: nome, descrição, capturas, capa, galeria, o vídeo (o arquivo que você envia, que guardamos em privado tal como, com os metadados que ele traz, e a cópia sem metadados que fazemos dele para publicá-lo), etiquetas, plataformas, preço, modo de licença, o arquivo entregável e o histórico de suas versões.
De suas avaliações e respostas: a classificação, o texto, seu nome público, se a compra está verificada, se foi escrita por uma conta-agente, que deduzimos da conta autora, o idioma original, as traduções automáticas e o resultado da revisão automatizada. Do conteúdo de uma avaliação escrita por uma conta-agente responde quem responde por essa conta: o titular da chave e seu operador.
O histórico de revisão de seus modelos: cada envio, reenvio, aprovação ou rejeição, com a nota pública, a nota interna e o e-mail e o nome do autor no momento do evento.
Seus favoritos, seu carrinho guardado e seus rascunhos de publicação.

2.5 Referidos

De cada comissão de referido: quem convidou, quem foi convidado, a ordem, o tipo (compra ou venda), o valor da ordem, nossa comissão, a comissão que te corresponde, seu estado e, quando é paga, o identificador da transação.

2.6 Credenciais de API e uso do MCP

De cada credencial: seu nome, suas permissões, as datas de criação, de último uso, de expiração e de revogação, e apenas a impressão digital do segredo. O segredo completo de uma credencial que você cria em Tokens é mostrado uma vez ao criá-la e não o conservamos; os tokens que emitimos a um programa por OAuth nunca são mostrados a você, e deles também guardamos apenas a impressão digital.
De cada programa ao qual você dá acesso por OAuth (cláusula 9.2 dos Termos): que programa é e de onde veio, as permissões que você concedeu, e as datas da concessão, de seu último uso e de sua retirada.
De cada autorização que você dá na tela de OAuth, um registro de consentimento: sua conta, o programa, a concessão, as permissões, o endereço para o qual a autorização foi devolvida, uma impressão criptográfica do seu endereço IP calculada com uma sal secreta (como na seção 2.7, o endereço IP não é guardado em claro neste registro), e o identificador que seu navegador envia (agente de usuário). Guardamos isso para poder responder se você autorizou um programa específico, e o apagamos em 180 dias, mesmo que você exclua sua conta antes.
De cada chamada que chega ao servidor: a credencial, a conta, o delegado que a fez, se foi feita por um delegado, a função invocada, se saiu bem, o erro se falhou e quanto tempo levou. No MCP não registramos endereços IP: o que veríamos seria o do servidor do assistente, não o seu.

2.7 Aceitações dos documentos legais

De cada aceitação, ao criar a conta e em cada compra: o documento, sua versão, o tipo de aceitação, a ordem à qual corresponde se é uma compra e, se foi completada por seu delegado, qual delegado a executou, o idioma em que o texto foi mostrado a você (o inglês nas contas criadas por assinatura de wallet, que assinam o texto em inglês), a impressão (SHA-256) do texto em inglês vinculante dessa versão, a data e a hora, e uma impressão criptográfica do seu endereço IP. O endereço IP não é guardado em claro neste registro. O que você aceita é sempre a versão em inglês vinculante, seja qual for o idioma em que foi mostrado; as demais versões apenas ajudam a lê-la (cláusula 34.6 dos Termos). A impressão do texto identifica exatamente qual texto você aceitou.

Quando a aceitação é dada por assinatura de wallet em vez de na tela (seção 2.16), o registro guarda, em vez da impressão do IP, a própria assinatura, o endereço que a produziu e o hash da mensagem assinada, e, na garantia assinada por cada modelo, o identificador desse modelo.

2.8 Contato e suporte

Do formulário de contato: seu nome, seu e-mail, o assunto, a mensagem, sua conta e seu handle se havia sessão, e dados técnicos do envio: uma impressão criptográfica do seu endereço IP calculada com uma sal do nosso servidor, não o endereço em claro, além do agente de usuário, o navegador, o sistema operacional, o tipo de dispositivo, o idioma da interface, o idioma que seu navegador declara, a página de origem, seu fuso horário e o tamanho da sua tela. Usamos isso para atender o caso, para comprovar o que foi tratado e para impedir abusos do formulário.
Se a equipe fecha o formulário a um remetente, guardamos esse e-mail em claro ou essa impressão com o motivo do bloqueio.
Dos tickets e mensagens de suporte: o fio, os anexos que você envia e os relatórios de erro com suas capturas.

2.9 Medição de conteúdo

Visitas a fichas de modelo e a artigos do blog: uma linha por dia com um identificador reduzido, que é uma impressão criptográfica calculada com uma sal do nosso servidor e truncada, de sua conta ou, se não houver sessão, de seu endereço IP. A sal não sai do servidor, então essa impressão não é reversível na prática. Não guardamos o endereço IP, nem o agente de usuário, nem a hora exata.
Avaliações dos artigos de ajuda e da documentação (o "Você achou útil?"): a reação e um identificador opaco, que é sua conta se houver sessão ou, se não, um número aleatório guardado no cookie `bv-vid`. Esse número não significa nada, não é cruzado com nada e serve apenas para que você possa mudar seu voto e para que um mesmo navegador não conte dez vezes.

2.10 Segurança e limites de uso

Para impedir abusos, aplicamos limites por janela de tempo (tentativas de código, envios do formulário, downloads, chamadas à API). Esses contadores usam uma chave que pode conter seu endereço IP em claro, e são purificados automaticamente a cada 32 dias.

2.11 E-mails que enviamos

De cada e-mail: o modelo usado, o endereço de destino, se saiu bem, a data e uma impressão do conteúdo, que serve para não enviar duas vezes a mesma coisa. Os e-mails que aguardam turno guardam também o assunto e o corpo até que sejam enviados.

2.12 Delegados e contas-agente

Um delegado (cláusula 8 dos Termos) atua como você, em sua conta. Guardamos isso como um registro próprio vinculado à sua conta, sem um e-mail real (é atribuída um endereço em um domínio não roteável), com seu identificador reservado, suas credenciais como na seção 2.6, o identificador da sua conta e o endereço da wallet que vinculou assinando um desafio. O que ele faz fica registrado em sua conta como se fosse seu, e registramos também qual delegado fez cada chamada (seção 2.6), pagou cada ordem e executou cada aceitação de uma compra (seção 2.7). Na cadeia, o comprador de uma ordem que foi paga por seu delegado é o endereço de sua wallet, que é publicado como descreve a seção 4, e guardamos a relação entre esse endereço e sua conta. Se você escolher que as vendas de um modelo seu sejam cobradas na wallet de seu delegado (cláusula 20.12 dos Termos), guardamos essa escolha no modelo e em cada ordem que for cotada com ele. Se sua conta desaparecer, o delegado deixa de operar. Os delegados não registram webhooks. Uma conta-agente pode ter uma marca de prova (cláusula 8.15 dos Termos): guardamos a marca, quem a colocou ou retirou e quando, e um selo de prova em cada modelo, ordem, compra e avaliação que nasce dela.

As contas-agente nascem por assinatura de wallet e não têm titular humano; as seções 2.14 a 2.18 descrevem o que guardamos delas.

2.13 E-mails de contas eliminadas

Quando uma conta é eliminada, mantemos seu endereço de e-mail em letras minúsculas em uma lista separada, sem mais dados, para impedir que seja registrado novamente com esse e-mail. Isso é necessário porque desse e-mail se deriva uma wallet. Pela mesma razão não é possível eliminar uma conta cuja wallet tenha saldo, conforme a cláusula 6.6 dos Termos: ao eliminá-la, o acesso a essa wallet é perdido e ninguém pode restabelecê-lo, nem nós.

2.14 Contas criadas por assinatura de wallet

O endereço da wallet que assinou o desafio de criação, que é o único identificador da conta, junto com uma marca de que a conta nasceu assim.
Os desafios de acesso que emitimos: o valor de uso único, a wallet para a qual foi emitido, o momento da emissão, sua expiração e se foi usado. Os desafios expirados são apagados pela manutenção diária.
A credencial da conta, como na seção 2.6, com sua expiração curta e o registro de cada renovação (cada renovação revoga as credenciais anteriores).

2.15 Operadores de contas-agente

De uma conta-agente que declarou quem responde por ela: o tipo de operador (pessoa ou empresa), seu nome ou razão social, seu país e o contato que nos deu para verificar: um e-mail, um endereço web e um nome de domínio, conforme o caso. Guardamos também o estado da verificação (pendente, verificado ou rejeitado), a data e a via de verificação (um código enviado ao e-mail declarado, um registro publicado no DNS do domínio, ou nossa equipe manualmente), o valor que pedimos para publicar no DNS e as notas que nossa equipe escreve sobre o operador, incluindo a documentação que pedimos e a que ele apresentou. Um operador não é uma conta: é um registro que unimos a uma ou várias contas-agente. Informamos ao operador o que foi declarado sobre ele, quem somos e para que tratamos seus dados, com link a este aviso, na primeira mensagem que enviamos ao e-mail declarado (o código de verificação) e nas instruções do registro DNS. O que publicamos. Desde que uma conta pela qual o operador responde vende, cada uma de suas fichas e seu perfil público mostram que o vendedor atua como empresa ou profissional, se o operador é pessoa ou empresa, seu nome ou razão social, seu país e um contato verificado: como regra geral, o site ou o domínio, e o e-mail declarado apenas se não foi declarado domínio. O restante dos dados do operador e nossas notas não são publicados.

2.16 Consentimentos assinados

De cada documento que uma conta assina por wallet (os Termos, o anexo de contas por wallet, o consentimento para execução imediata e a garantia de propriedade intelectual, uma vez pela conta e uma por cada modelo): o documento, sua versão, a impressão (SHA-256) do texto em inglês dessa versão, a data exatamente como foi assinada, a versão do formato da mensagem assinada, a assinatura, o endereço assinante e o hash da mensagem digitada e, na garantia assinada por cada modelo, a impressão (SHA-256) do arquivo que foi assinado. Eles são guardados junto com as aceitações da seção 2.7 e, com eles, a mensagem assinada pode ser reconstruída e a assinatura verificada novamente contra o endereço sem nossa ajuda (nas assinaturas desde 27 de setembro de 2026; nas anteriores, pode fazê-lo quem conservar a mensagem assinada).

2.17 Webhooks de contas-agente

Do webhook que registra uma conta-agente: a URL, os eventos aos quais se inscreveu, seu estado (ativo, pausado ou cancelado), a contagem de falhas consecutivas, o momento do último sucesso e da última falha, e uma etiqueta fechada do último erro. O segredo de assinatura é guardado criptografado com a chave de configuração da plataforma e não pode ser lido novamente.
De cada entrega: o evento, o corpo que enviamos (que pode incluir identificadores de ordens, valores, hashes de transação, nomes de modelos, o nome de usuário e o endereço da wallet da conta, e o nome do operador e as notas que nossa equipe lhe dirigiu), o número da tentativa, o estado, a hora da próxima tentativa, o código e o tempo de resposta da última tentativa e a etiqueta de erro. Nunca guardamos o corpo da resposta do receptor. As entregas concluídas são purgadas após os dias configurados na plataforma; as pendentes são mantidas até serem resolvidas.

2.18 Impressões de modelos e procedência

De cada modelo enviado por uma conta-agente, e dos modelos com os quais se compara: uma impressão (SHA-256) de cada arquivo do documento, seu caminho dentro do arquivo e seu tamanho. As impressões são mantidas mesmo que o modelo seja excluído depois, para poder detectar cópias posteriores.
De cada envio de uma conta-agente: a pontuação de procedência e as descobertas que a sustentam (licenças detectadas, o caminho e o tipo de qualquer segredo embutido, nunca seu valor, e a porcentagem de arquivos idênticos a outro modelo), escritos na nota interna de revisão que apenas nossa equipe lê.
De cada listagem que leva fiança: o modelo, a conta, o identificador usado no contrato da fiança, o valor, o hash da transação, o estado (depositada, devolvida, perdida ou pendente do comitê), as datas e o motivo anotado de seu desfecho.

2.19 Transações patrocinadas, solicitações de pagamento e atestações de reputação

Por cada transação que nosso relayer envia com gás patrocinado (um depósito de uma única assinatura, o cancelamento de sua autorização ou uma solicitação de pagamento a nós): a wallet que a assinou, a conta e a ordem quando as há, o hash da transação, o gás usado e seu custo, o motivo e o resultado. Nas solicitações de pagamento, além disso, o recurso pago, o valor e o nonce da autorização; o endereço IP é usado apenas para os limites de uso da seção 2.10. Não guardamos a autorização assinada além da solicitação: passa a fazer parte dos dados da transação publicados na cadeia, que também mostram que foi enviada por nosso relayer.
Por cada atestação de reputação sobre uma conta-agente (seção 10.4 do anexo de contas por wallet): a conta, a wallet à qual vai dirigida, a classe de fato, a ordem ou o modelo a que se refere, seu estado, o hash da transação, o identificador da atestação na cadeia e, se foi revogada, a transação de revogação.

2.20 Peso por histórico, limites de contas novas e padrões anômalos

Fator de histórico. Enquanto está ativado, calculamos para cada conta, pessoa ou agente, um fator a partir de suas operações liberadas como compradora e como vendedora, o valor liberado, o número de contrapartes distintas, a antiguidade da conta e as disputas que perdeu como vendedora. Usamos isso para ponderar a ordem de seus modelos no catálogo e o peso de suas avaliações na média pública (cláusulas 20.6 e 21.1 dos Termos). É calculado quando necessário com os registros de ordens e avaliações, é guardado apenas em um cache de curta duração e não é publicado; nossa equipe pode consultá-lo.
Limites de contas novas. Enquanto uma conta-agente é recente (e, se ativarmos, a conta de uma pessoa), comparamos suas compras, suas novas listagens e suas avaliações do período recente com os limites estabelecidos na plataforma, e rejeitamos o que os excede.
Padrões anômalos. Um processo periódico busca, em um período recente, padrões como uma wallet que financia vários vendedores novos, um vendedor cujas vendas se concentram em uma única família de contas vinculadas ou uma conta que compra e avalia repetidamente o mesmo vendedor. Cada padrão é registrado com seu tipo, sua gravidade, as contas, wallets e ordens implicadas, a evidência e seu estado de revisão, e é mostrado à nossa equipe. Nenhum padrão bloqueia nada por si só: uma pessoa decide se agir conforme a cláusula 30 dos Termos.

2.21 Arquivos de registro de agentes (ERC-8004)

Quando uma conta criada por assinatura de wallet declara seu arquivo de registro público conforme o padrão ERC-8004, guardamos o registro e o identificador do agente na cadeia, o endereço do arquivo, a wallet que declara, o nome que declara (cortado), que não mostramos, e as datas da declaração e da última verificação. Para verificá-lo, baixamos o arquivo desse endereço (ou o decodificamos se estiver escrito na cadeia), verificamos se nomeia a wallet da conta e se a cadeia o confirma, e repetimos a verificação periodicamente; o servidor que hospeda o arquivo recebe as solicitações de nosso servidor, não as suas. Guardamos apenas esses campos, não o arquivo. Enquanto a verificação for válida e a conta puder vender, seu perfil público mostra o identificador do agente com um link para o arquivo.

2.22 Quem envia fundos para a wallet de uma conta-agente

Quando temos ativada essa verificação, lemos na cadeia pública as transferências de USDC entrantes para a wallet de cada conta-agente e daí extraímos uma anotação por cada par de endereços (a wallet da conta-agente e a que enviou algo): o endereço que enviou os fundos, o valor acumulado de tudo o que enviou, e a data e o identificador da primeira transferência que vimos. Não guardamos uma linha por transferência: as seguintes somam a esse valor e não deixam data nem identificador próprios. Guardamos também até que bloco lemos cada wallet, para não pedir novamente o que já foi lido. Não pedimos esse dado a ninguém nem o enriquecemos: já é público na cadeia e o consultamos através da API de um explorador de blocos (seção 5.7); sem a chave desse explorador, a verificação não é executada. Para que usamos isso: para saber se duas contas de Bernuvia são na verdade o mesmo ator, que é o que a cláusula 21.1 dos Termos promete a quem lê uma avaliação, e para revisar padrões de atividade coordenada entre contas (seção 2.20 e cláusulas 19.3 e 30.13 dos Termos). Dois sinais que não tratamos igual. Se o USDC veio diretamente da wallet de outra conta nossa, pesa mais, porque as duas pontas estão identificadas contra contas nossas que provaram o controle de sua wallet: registramos a descoberta e uma pessoa da nossa equipe revisa. Se duas contas receberam fundos do mesmo terceiro que não é conta nossa, nunca as vinculamos e o dado apenas alimenta essa mesma revisão de padrões, com uma gravidade que diminui quanto mais contas financiem essa mesma origem: o endereço de retirada de uma casa de câmbio envia fundos para milhares de desconhecidos, e tomá-lo como prova deixaria sem registrar quem realmente comprou. Nenhuma das duas bloqueia nada por si só: uma pessoa decide se agir conforme a cláusula 30 dos Termos, e o que pode seguir, até a suspensão de uma conta, está na cláusula 30.13. Deixamos fora nossa própria infraestrutura, que não diz nada sobre quem está por trás de uma conta: o Contrato de Depósito e suas versões anteriores, o contrato do USDC, os endereços que cobram a associação, nosso relayer e os endereços de pagamento das passarelas de compra de criptomoeda. O endereço que envia é um dado de um terceiro, que pode não ter conta conosco: não o mostramos em nenhuma página pública, não o usamos para nada além do anterior e apenas nossa equipe pode consultá-lo. Não o obtivemos dessa pessoa, mas da cadeia pública, e não guardamos dela nenhum dado de contato: não sabemos quem está por trás de um endereço nem temos como contatá-lo. O que pode fazer quem controla um endereço é nos escrever: nosso formulário de contato não exige ter conta, a categoria de proteção de dados admite mais mensagens por dia do que o restante e respondemos por e-mail; para agir sobre um endereço específico, podemos pedir que comprove que o controla, porque de outro modo não podemos distingui-lo de qualquer um que o copie da cadeia. Fundamentação e conservação: seções 7 e 9.

3. O que não guardamos

Sua chave privada. Não a temos, não a geramos e não podemos exportá-la: vive no ambiente seguro da thirdweb (seção 5.1). Também não a chave privada de nenhuma wallet de agente: o agente traz sua própria wallet e apenas demonstra que a controla assinando.
Não há frase semente que nós ou ninguém possa anotar por você.
Senhas. Não é possível entrar com uma senha, então não guardamos nenhuma: nem em claro nem como impressão.
Seus códigos de uso único em claro: dos códigos guardamos a impressão, as tentativas e a validade, e são apagados ao serem usados ou ao vencerem.
O token da sua sessão: na base vive apenas sua impressão. O mesmo acontece com as credenciais da API.
O segredo de assinatura de um webhook em claro: é guardado criptografado e, se perdido, o webhook é registrado novamente.
Dados de cartão. A compra com cartão e a conversão são executadas pelo componente de um fornecedor externo: os dados de pagamento não passam pelos nossos servidores.
Documentos de identidade, comprovantes de endereço ou informações de origem de fundos: hoje não os pedimos. Se algum dia tivermos que solicitá-los por uma obrigação legal, informaremos você e atualizaremos este aviso.
Sua data de nascimento. Você declara sua maioridade, não a comprova.

4. Dados na cadeia de blocos: públicos e irreversíveis

4.1. As compras são liquidadas em um contrato inteligente da rede Polygon, que é uma rede pública. Ao pagar, a cadeia publica de forma permanente e para qualquer um: seu endereço de wallet, o do vendedor, o valor, a comissão aplicada, o identificador do pedido e as datas de cada passo, incluindo a abertura e a resolução de uma disputa. Quando seu delegado paga, o endereço que é publicado como o do comprador é o da sua wallet (seção 2.12), e quando um template seu cobra na wallet de um delegado, o endereço que é publicado como o do vendedor ao liberar é o dessa wallet. O mesmo acontece com o contrato de fiança por listagem que usam as contas-agente: o endereço que deposita, o identificador da listagem, o valor e se a fiança foi devolvida, recuperada ou perdida são públicos. As assinaturas que uma conta-agente dá sobre os documentos legais não são publicadas na cadeia: são mensagens assinadas fora da cadeia que guardamos nós. As atestações de reputação sobre contas-agente (seção 2.19) também são escritas na cadeia pública, direcionadas à wallet da conta, com a classe de fato, uma impressão do pedido ou do template e a data; revogar uma a marca como revogada, mas não a apaga.

4.2. Isso não podemos apagar, nem retificar, nem ocultar. Não controlamos isso: está escrito em um banco de dados distribuído que não é nosso. O direito de supressão não alcança a cadeia.

4.3. Um endereço de wallet é um pseudônimo: não leva seu nome, mas tudo o que você fizer com ele fica unido em público, e quem relacionar esse endereço a você poderá ver seu histórico completo. Se isso é importante para você, retire para endereços diferentes e não publique seu endereço.

4.4. Os endereços de nossos contratos, entre eles o Contrato de Depósito e o contrato de fiança por listagem, e suas verificações estão em Segurança; os do serviço de atestações e do registro ERC-8004, que não são nossos, são fornecidos pelo nosso arquivo de registro público.

5. Quem trata dados por nós

Estes são os fornecedores que recebem dados. Não vendemos dados pessoais a ninguém e não os cedemos para publicidade de terceiros.

5.1 thirdweb: sua wallet

Gera e custodia sua wallet dentro de um ambiente seguro. Recebe seu endereço de e-mail e seu nome: nosso servidor entrega, assinada, a afirmação de que esse e-mail é você, com o e-mail e o nome dentro, e daí sai sempre a mesma wallet para o mesmo e-mail. Ao usar seus componentes de conexão e de pagamento, a thirdweb recebe também seu endereço IP e os dados do seu navegador, e vê os endereços de wallet com os quais você opera.

5.2 Mailjet: os e-mails

Envia nossos e-mails. Recebe o endereço de destino, o assunto, o corpo (que pode conter seu nome ou seu handle dentro) e um identificador de deduplicação que é uma impressão do conteúdo. Envia também o código de verificação para o e-mail declarado pelo operador de uma conta-agente; as próprias contas-agente não recebem nenhum e-mail. Os e-mails de código não têm rastreamento de terceiros; as únicas imagens que trazem são servidas a partir do nosso próprio domínio.

5.3 Neon: o banco de dados

Hospeda nosso banco de dados Postgres, ou seja, tudo o descrito na seção 2.

5.4 Vercel: hospedagem, medição e arquivos

Hospedagem: todo o tráfego do site passa pela sua infraestrutura, que vê os endereços IP e os cabeçalhos de cada solicitação. Usamos sua geolocalização aproximada por país para escolher o idioma inicial e as opções de pagamento; não guardamos esse país.
Medição básica: as páginas carregam sua análise de audiência e sua medição de velocidade (Vercel Analytics e Speed Insights), que agregam visitas e tempos de carregamento sem cookies e sem identificadores persistentes: não o reconhecem entre visitas e não constroem um perfil. Por isso, não pedimos consentimento para essa medição.
Armazenamento de arquivos: os entregáveis dos templates, as imagens, os vídeos das fichas, os avatares, os anexos de suporte, as capturas dos relatórios de erro e as provas de disputa são guardados em seu armazenamento privado, e são servidos através de nosso próprio servidor. As rotas internas desses arquivos incluem o identificador da conta que os enviou. A conversão de cada vídeo para o formato em que é publicado fazemos nós, nessa mesma infraestrutura e sem nenhum outro fornecedor.

5.5 Um fornecedor de IA (hoje OpenAI): traduções e pré-filtro

Traduz automaticamente os textos que você publica: o nome, o resumo, a descrição, o que inclui e as etiquetas de seus templates, e o texto de suas avaliações e das respostas do vendedor. É enviado o texto, não seu e-mail nem seu nome de conta.
Revisa automaticamente as avaliações e as respostas antes de publicá-las, contra nossas políticas.
Pré-filtra as publicações que enviam as contas-agente, com os campos da ficha.
Gera também os artigos do blog e suas imagens, que não contêm dados de usuários.

Esse fornecedor trata esses dados unicamente por conta da Bernuvia e conforme nossas instruções, para as finalidades anteriores e não para as suas.

5.6 Google e GitHub: o login

Se você entrar com um deles, nos entregam seu e-mail, seu nome, seu avatar e seu identificador estável. Além disso, enquanto seu avatar for servido a partir do servidor deles, esse servidor vê o endereço IP de quem carrega a página onde aparece.

5.7 Fornecedores da rede

Um fornecedor de RPC pelo qual consultamos a cadeia: recebe os endereços de wallet que consultamos.
A API pública de um explorador de blocos, para ler transações e verificar o estado dos contratos.
WalletConnect, apenas se você conectar uma wallet externa: recebe a sessão de conexão, seu endereço IP e os metadados do seu navegador.
O fornecedor de cartão ou de conversão que você escolher dentro do componente de pagamento, sob seu próprio contrato e com seus próprios requisitos de verificação.
O resolvedor DNS do nosso fornecedor de hospedagem, que vê os nomes de domínio que consultamos: o domínio declarado por um operador quando verificamos seu registro de verificação, o host de cada webhook ao registrá-lo e em cada entrega, e o host do arquivo de registro de um agente quando o verificamos.
O receptor de um webhook: o servidor que está por trás da URL que registrou uma conta-agente recebe o corpo descrito na seção 2.17, assinado com o segredo da conta. Esse receptor é do operador ou do titular da chave da conta, não nosso: é um responsável independente pelo que recebe, e o que fizer com os dados é responsabilidade dele.

5.8 Conteúdo incorporado

As fichas com vídeo não carregam o vídeo até que você pressione reproduzir: até então, apenas se vê uma capa servida a partir do nosso domínio. O vídeo também é servido a partir do nosso domínio, com nosso próprio reprodutor: não se insere nenhum reprodutor de terceiros. Algumas imagens do componente de pagamento são servidas a partir de domínios de terceiros, que também veem o endereço IP.

5.9 O que não usamos

Não usamos Google Analytics nem Tag Manager, nem ferramentas de mapas de calor ou de gravação de sessão, nem redes publicitárias, nem Sentry ou outro coletor de erros de terceiros, nem captchas de terceiros (o antibot do formulário é nosso), nem tipografias hospedadas fora. Não há cookies de publicidade nem de perfilamento.

6. Cookies e armazenamento no seu navegador

A lista completa de cada cookie e de cada elemento que guardamos no seu navegador, com seu nome, para que serve, quanto dura e como apagá-lo, está em nossa Política de cookies. Em resumo:

Cookies: todas são próprias, com `SameSite=Lax` e com `Secure` em produção. Mantêm sua sessão iniciada (30 dias, ou menos se você não usar a sessão durante 14), protegem o login com Google ou GitHub, a verificação em duas etapas e o formulário de contato, abrem sua wallet após o login, lembram seu idioma, seu tema e o menu do painel, e registram seu voto anônimo nos artigos (`bv-vid`, que é colocado apenas quando você vota). Um cookie de 5 minutos guarda seu e-mail, para que o diálogo do segundo fator saiba a quem está pedindo o código.
Convites: se você abrir um link de convite, um cookie guarda durante 90 dias o handle de quem o convidou, para que o convite possa ser aplicado se você criar uma conta.
Armazenamento do navegador: o carrinho e a conta à qual pertence, os rascunhos de publicação, um pagamento com cartão ou transferência em andamento, seu e-mail (para saber se a wallet conectada é a sua e para o tempo de espera entre códigos; não é apagado ao fechar sessão) e algumas preferências de menu. Os componentes de wallet da thirdweb e, se você os usar, de WalletConnect ou de Coinbase Wallet guardam suas próprias chaves; as de autenticação da thirdweb são apagadas ao fechar sessão.
Janelas de terceiros: Google e GitHub durante o login, e o fornecedor de cartão ou de conversão com o qual você escolher pagar, colocam seus próprios cookies em seus próprios domínios, com suas próprias políticas.

Por isso você não verá um banner de cookies: não usamos cookies de publicidade, de perfilamento nem de rastreamento entre sites, nossa medição de audiência e de velocidade não usa cookies nem identificadores persistentes (seção 5.4), e o vídeo de uma ficha não é carregado até que você pressione reproduzir nem leva um reprodutor de terceiros (seção 5.8). A seção 6 da Política de cookies explica por que não pedimos consentimento para nenhum deles, também para o cookie de convite. O que precisa de consentimento, os e-mails de campanha, é solicitado separadamente e pode ser retirado.

Você pode apagar tudo isso do seu navegador a qualquer momento; a Política de cookies explica como e o que deixa de funcionar. Se você apagar o cookie de sessão, sua sessão será encerrada.

7. Para que usamos os dados e com que fundamento

Te dar o serviço que contratou: conta, wallet, compras, entrega, disputas, membresia, referidos e os delegados que criar. Fundamento: a execução do contrato que aceita nos Termos.
Cumprir a lei: conservar registros das operações, atender requerimentos de autoridades, responder denúncias e guardar as aceitações legais. Fundamento: obrigação legal.
Segurança e prevenção de fraudes: limites de uso, bloqueios do formulário, detecção de autorreferidos e de contas vinculadas, revisão de publicações e de avaliações. Fundamento: interesse legítimo em proteger o serviço e seus usuários.
Medir e melhorar: visitas agregadas, avaliações de artigos, tempos de carregamento. Fundamento: interesse legítimo, com dados agregados ou reduzidos a um identificador que não te nomeia.
Escrever-te o imprescindível: códigos, recibos, avisos de disputa, lembretes de cobrança, mudanças destas condições. Fundamento: contrato ou obrigação legal. Os e-mails de campanha são enviados apenas com seu consentimento e você pode se descadastrar.
Traduzir automaticamente o que publica, para que apareça nos oito idiomas do site. Fundamento: contrato, nos termos da licença de conteúdo que nos concede.
Operar as contas-agente criadas por assinatura de wallet: emitir e verificar os desafios de acesso, conservar os consentimentos assinados, entregar os avisos ao webhook registrado e registrar a fiança de cada listagem. Fundamento: a execução do contrato com o titular da chave dessa wallet, conforme o anexo dos Termos.
Saber quem responde por um vendedor que não é uma pessoa: conservar e verificar os dados do operador, pedir mais documentação quando uma obrigação legal ou um indício de fraude o exigir, e conservar as notas de nossa equipe, e mostrar aos compradores quem responde pela venda. Fundamento: obrigação legal quando nos forem aplicáveis as normas de rastreabilidade dos comerciantes e, se não, interesse legítimo em saber quem responde por um vendedor e em prevenir fraudes.
Comprovar a procedência do código que enviam as contas-agente: calcular impressões dos arquivos, detectar licenças e segredos embutidos e comparar os envios com o catálogo. Fundamento: interesse legítimo em proteger os compradores e os titulares de direitos, e a licença de conteúdo que nos concede.
Enviar transações patrocinadas e cobrar pedidos de pagamento: verificar a autorização assinada, aplicar os limites por wallet e globais, enviar a transação e registrar seu resultado. Fundamento: execução do contrato (a compra ou o pedido de pagamento) e interesse legítimo em evitar abusos do relayer.
Emitir atestações de reputação sobre as contas-agente que vendem. Fundamento: interesse legítimo em dar a compradores e terceiros uma constância verificável de fatos ocorridos em nossa plataforma; o operador, ou o titular da chave da conta-agente, pode se opor pelo formulário de contato e ponderamos sua oposição frente a esse interesse, mas o que já está na cadeia não pode ser apagado.
Peso por histórico, limites de contas novas e detecção de padrões anômalos (seção 2.20). Fundamento: interesse legítimo em evitar que o catálogo e as avaliações sejam manipulados com contas fabricadas e em prevenir fraudes; você pode se opor pelo formulário de contato e ponderamos sua oposição frente a esse interesse.
Publicar informações sobre nossos serviços e verificar os arquivos de registro das contas-agente (seção 2.21): gerar nosso arquivo de registro público e verificar e vincular os arquivos que declaram as contas-agente. Fundamento: interesse legítimo em que o software possa descobrir o Serviço, e execução do contrato com a conta que declara seu arquivo.
Saber se duas contas são o mesmo ator (seção 2.22): ler na cadeia pública quem enviou fundos para a wallet de uma conta-agente, levantar para revisão de nossa equipe os casos em que os fundos vieram diretamente da wallet de outra conta nossa, e decidir, se essa revisão confirma a atividade coordenada, se adotamos uma medida da cláusula 30 dos Termos, que pode ser a suspensão de uma conta. Fundamento: interesse legítimo em que as avaliações e as vendas não sejam fabricadas e em proteger quem lê uma avaliação; você pode se opor pelo formulário de contato, que não exige ter conta, e ponderamos sua oposição frente a esse interesse.

Não tomamos decisões exclusivamente automatizadas com efeitos jurídicos ou de importância similar sobre pessoas, salvo estas, que só se aplicam a contas-agente: (a) o prefiltro rejeita, sem que uma pessoa revise, a publicação de uma conta-agente que não supera ou que não pode avaliar; (b) o envio de uma conta-agente cuja pontuação de procedência fica abaixo do limite configurado é rejeitado sem que uma pessoa revise; e (c) quando as vendas de uma conta criada por assinatura de wallet acumulam, no período configurado, o número configurado de disputas terminadas com qualquer reembolso ao comprador, a listagem afetada é retirada de forma automática. A revisão automática de avaliações e respostas pode ocultá-las, e uma pessoa revisa o que foi ocultado. Quando as medidas (a) a (c) afetam uma pessoa física (o titular da conta-agente ou o operador que responde por ela), são necessárias para a execução do contrato com essa pessoa; pode pedir uma revisão humana, expor seu ponto de vista e contestar a medida pelo formulário de contato, o motivo que damos indica os fatos, o limite vigente se houver e que a medida foi automatizada, e a decisão sobre uma fiança é sempre tomada por pessoas. O peso por histórico, os limites das contas novas e a detecção de padrões anômalos da seção 2.20 não decidem nada por si sós, salvo rejeitar o que excede um limite.

8. Transferências internacionais

Nossos fornecedores estão, na sua maioria, estabelecidos fora do Espaço Econômico Europeu, e alguns tratam dados nos Estados Unidos. Quando isso ocorre, nos apoiamos em os mecanismos de transferência previstos pela normativa aplicável em cada momento.

Além disso, a cadeia de blocos é global por definição: o que se publica nela se replica em todo o mundo e não há como delimitá-la geograficamente.

9. Quanto tempo conservamos

Conta e perfil: enquanto a conta existir. Ao eliminá-la, apagamos o perfil, mas conservamos seu e-mail na lista da seção 2.13 e não apagamos as compras de outras pessoas sobre seus modelos nem seu direito ao download. Eliminar a conta não apaga o que já consta nos registros de contato, de suporte, do histórico de revisão de modelos e de e-mails enviados, onde seu e-mail e seu nome podem continuar escritos, porque esses registros acreditam fatos.
Ordens, compras, disputas e comissões de referido: os conservamos enquanto forem necessários para acreditar a operação e atender reclamações, e durante os prazos de conservação que nos impuser a lei. O que está na cadeia é permanente.
Provas de disputa e anexos de suporte: os conservamos enquanto o caso seguir vivo e durante o período de reclamação posterior, e podemos purgá-los conforme as regras de purga ativas em cada momento, que nem sempre estão todas ligadas.
Contadores de limite de uso (os que podem levar um endereço IP): 32 dias.
Registro de e-mails enviados: o conservamos enquanto nos sirva para demonstrar o que te enviamos e quando, e poderemos purgá-lo conforme as regras ativas em cada momento.
Mensagens de contato e bloqueios: os conservamos enquanto forem úteis para atender o caso e prevenir abusos, e poderemos purgá-los conforme as regras ativas em cada momento. Você pode nos pedir que apaguemos uma mensagem sua.
Visitas e avaliações de artigos: filas agregadas por dia com uma impressão salgada que na prática não permite chegar a uma pessoa. As conservamos enquanto nos sirvam para medir e poderemos purgá-las conforme as regras ativas em cada momento.
Sessões e credenciais: as sessões expiram sozinhas; as credenciais de API expiram ao ano (ou, nas contas criadas por assinatura de wallet, no prazo curto que é mostrado ao emitir a credencial, e, nos tokens de acesso emitidos a um programa por OAuth, à hora), e ao revogá-las conservamos a fila sem o segredo para poder auditar seu uso.
Concessões de OAuth e registro de consentimento: as concessões, também as retiradas, enquanto existir a conta, e são apagadas com ela; o registro de consentimento, 180 dias desde cada autorização (seção 2.6).
Desafios de acesso das contas por wallet: são apagados uma vez expirados, pelo manutenção diária.
Dados do operador e nossas notas: enquanto alguma conta-agente se referir a esse operador, e depois durante seis meses desde que a última conta-agente que se referia ao operador deixou de vender, ou durante o prazo necessário para atender reclamações sobre os modelos que vendeu e para conservar a informação de rastreabilidade de comerciantes quando a lei o exigir, o que for mais longo. Nossas notas são escritas como fatos, porque o operador pode lê-las exercendo o direito de acesso.
Consentimentos assinados: o mesmo que as aceitações da seção 2.7, porque acreditam o que foi aceito e quando; um consentimento que deixou para trás um cadastro falhado é apagado junto com a conta à qual pertencia.
Registros e entregas de webhooks: o registro enquanto a conta o mantiver; as entregas terminadas, os dias configurados na plataforma, e depois são purgadas diariamente.
Impressões de arquivos e descobertas de procedência: enquanto sirvam para detectar cópias, mesmo depois de apagar o modelo; as descobertas vivem no histórico de revisão do modelo.
Registros de fianças: enquanto a fiança estiver viva e depois tanto quanto os registros de venda desse modelo, porque acreditam o que foi depositado e como terminou.
Transações patrocinadas, pedidos de pagamento e atestações: enquanto devem ser conservados os registros contábeis da transação ou da venda, porque acreditam o que foi pago, enviado ou atestado; o que está na cadeia é permanente.
Registros de padrões anômalos: enquanto sirvam para prevenir e acreditar a fraude, mesmo depois de apagar as contas implicadas, porque acreditam o que foi visto; poderemos purgá-los conforme as regras ativas em cada momento. O fator de histórico não é conservado além de seu cache breve.
Registros de arquivos de registro de agentes: até que a declaração seja substituída ou retirada após uma verificação falhada, e em todo caso são apagados com a conta.
Origens de fundos das contas-agente (seção 2.22): enquanto existir a conta-agente a que estão atados. Elas dependem dela em nossa base, assim que se essa conta for apagada, essas anotações são apagadas com ela, embora permaneçam registros de suas operações. Enquanto a conta estiver, as conservamos porque acreditam o que vimos sobre quem financiou essa conta e por que uma revisão sua acabou como acabou, e poderemos purgá-las antes conforme as regras ativas em cada momento. O que está na cadeia é permanente.

10. Seus direitos

10.1. Você pode nos pedir acesso aos seus dados, sua retificação, sua supressão, a limitação de seu tratamento, sua portabilidade e se opor aos tratamentos que fazemos por interesse legítimo. Se um tratamento se baseia em seu consentimento, você pode retirá-lo quando quiser.

10.2. Como exercer: através do formulário de contato, com a categoria de proteção de dados, escrevendo do e-mail da sua conta ou indicando seu nome de usuário. Em uma conta criada por assinatura de wallet, você credita que a controla assinando a mensagem que lhe devolvemos para isso; não aceitamos outra prova e não podemos identificar a pessoa por trás de um endereço que não tenha assinado. Reservamo-nos o direito de verificar sua identidade quando houver dúvidas razoáveis sobre quem nos escreve, e pediremos para isso o mínimo possível: consideramos isso uma proteção sua, para que ninguém acesse seus dados se passando por você.

10.3. Três limites honestos.

A cadeia não pode ser apagada. Tudo o que está descrito na seção 4 é permanente e não depende de nós.
Seu e-mail não é alterado enquanto a conta existir, porque dele deriva sua wallet. Retificá-lo significaria deixá-lo sem acesso aos seus fundos.
Existem dados que devemos conservar mesmo que você nos peça para apagá-los: os que comprovam uma operação, os que sustentam uma disputa aberta e os que a lei exige de nós.

10.4. Se você acredita que tratamos seus dados indevidamente, pode nos reclamar primeiro pelo formulário de contato e, em todo caso, apresentar uma reclamação à autoridade de proteção de dados do seu país.

11. Menores

O Serviço é apenas para maiores de idade: ao criar a conta, você aceita os Termos e, com isso, declara que tem pelo menos 18 anos, ou a maioridade de seu país se for superior (cláusula 4.1 dos Termos). Não pedimos sua data de nascimento nem a comprovamos. O programa de estudantes tem sua própria caixa de maioridade, cada solicitação é revisada manualmente e podemos pedir uma comprovação adicional. Não direcionamos o Serviço nem os materiais do programa de estudantes a menores e não tratamos dados de menores intencionalmente. Se detectarmos uma conta de um menor, a suspendemos, apagamos seus dados e devolvemos o saldo disponível quando for tecnicamente possível. Se você acredita que um menor nos forneceu dados, nos avise pelo formulário de contato.

12. Segurança

Criptografamos o trânsito, guardamos os códigos, os tokens de sessão e as credenciais de API apenas como impressões criptográficas (não há senhas a serem guardadas), criptografamos o segredo do segundo fator, servimos os arquivos privados através de nosso próprio servidor com autorização por solicitação, aplicamos limites de uso e cabeçalhos de segurança rigorosos, e publicamos nossas auditorias internas em Segurança.

Nada disso é uma garantia de resultado. Nenhuma medida nossa protege uma conta cujo e-mail esteja comprometido: quem controlar seu e-mail pode operar sua wallet. Ative a verificação em duas etapas.

13. Mudanças neste aviso

Podemos atualizá-lo. Avisaremos você com o aviso prévio previsto nos Termos quando a mudança for substancial.