Política de guarda e proteção dos instrumentos de controle de ativos virtuais

1. Objetivo

Estabelecer diretrizes, responsabilidades, processos e salvaguardas adotadas pela Foxbit Serviços Digitais Ltda. e demais empresas do grupo (“Grupo Foxbit” ou “Foxbit”) para garantir a segurança, integridade, disponibilidade, governança e segregação dos instrumentos de controle associados aos ativos virtuais sob sua administração, incluindo chaves privadas, mecanismos criptográficos de autorização e assinatura, credenciais operacionais, políticas de acesso e demais elementos necessários para a execução segura de transações digitais, observadas as características específicas de cada protocolo subjacente, bem como garantir a segregação patrimonial entre ativos próprios e ativos de clientes, em conformidade com a Lei nº 14.478/2022 e com a Resolução BCB nº 520/2025.

2. Abrangência

Esta Política aplica-se a:

• instrumentos de controle utilizados para a custódia, movimentação, autorização e validação de ativos virtuais, incluindo aqueles definidos nativamente por protocolos específicos, como estruturas de múltiplas assinaturas (m-of-n) descritas no BIP-0011;
• carteiras, endereços, estruturas de depósito e saque mantidos em plataformas especializadas, tais como Fireblocks e BitGo, bem como às regras criptográficas inerentes aos protocolos dos ativos suportados;
• colaboradores, administradores, sistemas e integrações que interajam com tais instrumentos, direta ou indiretamente;
• rotinas de criação, gerenciamento, segregação, concessão e revogação de acessos, monitoramento contínuo e resposta a incidentes, considerando as particularidades operacionais e de segurança de cada rede blockchain, inclusive aquelas previstas em padrões técnicos amplamente reconhecidos, como o BIP-0011.

Esta Política abrange exclusivamente instrumentos de controle relacionados a clientes e usuários e está alinhada às capacidades oferecidas pelas plataformas de custódia e infraestrutura tecnológica utilizadas pela Foxbit, bem como às regras nativas de governança e controle definidas pelos protocolos dos ativos virtuais suportados, incluindo, quando aplicável, estruturas de múltiplas assinaturas (multisignature) conforme especificações do Bitcoin Improvement Proposal – BIP-0011, além das operacionalizadas por meio de Fireblocks e BitGo.

3. Leis, normas e regulamentações aplicáveis

Lei nº 14.478/2022 – Dispõe sobre diretrizes a serem observadas na prestação de serviços de ativos virtuais e na regulamentação das prestadoras de serviços de ativos virtuais (Marco Legal dos Ativos Virtuais);

Decreto nº 11.563/2023 – Atribui ao Banco Central do Brasil a competência para regular, autorizar e supervisionar as prestadoras de serviços de ativos virtuais;

Resolução BCB nº 519/2025 – Disciplina os processos de autorização das sociedades prestadoras de serviços de ativos virtuais (SPSAV) e das demais instituições autorizadas a prestar serviços de ativos virtuais;

Resolução BCB nº 520/2025 – Dispõe sobre a constituição e o funcionamento das SPSAV e sobre a prestação de serviços de ativos virtuais, incluindo os requisitos de custódia, de guarda e controle dos instrumentos que asseguram direitos sobre os ativos virtuais e de segregação entre os ativos próprios e os ativos de clientes;

Resolução BCB nº 521/2025 – Altera as Resoluções BCB nº 277, 278 e 279/2022 para incluir as atividades das prestadoras de serviços de ativos virtuais no mercado de câmbio e de capitais internacionais;

Instrução Normativa BCB nº 701/2026 – Estabelece os procedimentos de comunicação e os requisitos mínimos da certificação técnica independente das prestadoras de serviços de ativos virtuais, incluindo a avaliação das políticas de guarda e proteção dos instrumentos de controle, dos mecanismos de monitoramento contínuo e de redundância e da segregação e prova de reservas;

Resolução CMN nº 4.893/2021 e Resolução BCB nº 85/2021 – Dispõem sobre a política de segurança cibernética e sobre os requisitos para a contratação de serviços de processamento e armazenamento de dados e de computação em nuvem;

Lei nº 13.810/2019 – Dispõe sobre o cumprimento de sanções impostas por resoluções do Conselho de Segurança das Nações Unidas, incluindo a indisponibilidade de ativos;

Lei nº 13.709/2018 – Lei Geral de Proteção de Dados Pessoais (LGPD);

ISO/IEC 27001:2022 – Sistema de Gestão de Segurança da Informação (SGSI);

SOC 2 Type II – Controles de segurança, disponibilidade e confidencialidade;

Bitcoin Improvement Proposal – BIP-0011 – Padrão técnico para transações com múltiplas assinaturas (m-of-n) na rede Bitcoin.

4. Termos e definições

Para garantir o entendimento e a interpretação adequados desta Política, os termos abaixo, quando usados com a primeira letra em maiúsculo, terão os significados definidos, tanto no singular quanto no plural.

• Instrumentos de Controle: chaves privadas, fragmentos criptográficos, mecanismos de assinatura e autorização, credenciais e políticas de acesso que permitem movimentar ou assegurar direitos sobre ativos virtuais;
• Chave Privada: informação criptográfica secreta que permite assinar transações e movimentar ativos virtuais associados a um endereço;
• MPC (Multi-Party Computation): técnica criptográfica em que a chave privada é dividida em fragmentos mantidos por partes distintas, permitindo assinar transações sem que a chave seja formada integralmente;
• TSS (Threshold Signature Scheme): esquema de assinatura em que um número mínimo de fragmentos é necessário para gerar uma assinatura válida;
• Multisignature (m-of-n): estrutura que exige “m” assinaturas de um conjunto de “n” chaves autorizadas para movimentar ativos;
• Quórum: número mínimo de assinaturas ou aprovações exigido para executar uma transação;
• HSM / TEE / SGX: módulos e ambientes de hardware seguros e isolados utilizados para gerar, armazenar e utilizar material criptográfico;
• Policy Engine: mecanismo de regras das plataformas de custódia que define fluxos de aprovação, limites, whitelists e restrições de transações;
• Whitelist: lista de endereços ou destinos previamente autorizados para recebimento de transações;
• RBAC (Role-Based Access Control): modelo de controle de acesso baseado em papéis e funções;
• Zero Standing Access: princípio segundo o qual nenhum usuário mantém acesso privilegiado permanente, sendo os acessos concedidos apenas quando necessários;
• Segregação Patrimonial: separação entre os ativos próprios da Foxbit e os ativos de titularidade dos clientes;
• Recovery: procedimento de recuperação segura do acesso aos ativos virtuais em caso de indisponibilidade ou comprometimento de instrumentos de controle.

5. Papéis e responsabilidades

Diretoria

• Aprovar esta Política e suas atualizações;
• Prover os recursos humanos, materiais e financeiros necessários ao seu cumprimento;
• Deliberar sobre casos excepcionais e incidentes relevantes envolvendo instrumentos de controle.

Segurança da Informação

• Gerenciar perfis, acessos, dispositivos e integrações nas plataformas de custódia, observando o princípio do menor privilégio;
• Monitorar continuamente alertas, logs e eventos das plataformas de custódia;
• Coordenar a detecção, contenção e recuperação de comprometimentos de instrumentos de controle.

Financeiro / Tesouraria

• Definir a distribuição de ativos virtuais entre carteiras e os limites operacionais;
• Atuar como operador ou aprovador de transações, conforme os papéis e alçadas definidos nesta Política;
• Conciliar periodicamente os saldos custodiados com as posições de clientes.

Tecnologia

• Manter as integrações com as plataformas de custódia e a gestão segura de chaves de API;
• Apoiar a implementação de controles técnicos, de monitoramento e de redundância.

Compliance

• Acompanhar os requisitos regulatórios aplicáveis à custódia e à segregação patrimonial;
• Manter a documentação atualizada à disposição do Banco Central do Brasil.

Recursos Humanos

• Comunicar tempestivamente desligamentos e mudanças de função, para a imediata revisão ou desativação de acessos.

GRC

• Monitorar o cumprimento desta Política e a efetividade dos controles relacionados;
• Apoiar a certificação técnica independente e as auditorias aplicáveis;
• Revisar esta Política com periodicidade anual, ou sempre que houver necessidade.

Todos os colaboradores

• Cumprir as diretrizes estabelecidas nesta Política e reportar imediatamente qualquer suspeita de comprometimento.

6. Princípios e diretrizes

• Confidencialidade, integridade e disponibilidade dos instrumentos de controle;
• Inexistência de ponto único de falha: nenhuma pessoa, sistema ou dispositivo detém, isoladamente, a capacidade de movimentar ativos;
• Segregação de funções e controle de alçadas: quem inicia uma transação não a aprova;
• Menor privilégio e Zero Standing Access;
• Segregação patrimonial entre ativos próprios e ativos de clientes;
• Rastreabilidade: todos os eventos são registrados, auditáveis e protegidos contra alteração;
• Cumprimento da legislação vigente.

7. Regras principais

7.1 Arquitetura MPC (Multi-Party Computation)

A Foxbit adota Fireblocks e BitGo como infraestrutura primária de depósito e saque, utilizando MPC para criar e operar fragmentos criptográficos:

• A chave privada nunca é formada integralmente em nenhum ponto (Fireblocks MPC-CMP / BitGo TSS).
• Cada fragmento é gerado, armazenado e utilizado em ambientes isolados e protegidos por hardware (HSM/TEE/SGX).
• Nenhum colaborador, administrador ou sistema possui acesso direto a uma chave privada completa.

Referências: Fireblocks MPC-CMP – https://www.fireblocks.com/what-is-mpc; BitGo TSS Wallets – https://www.bitgo.com/resources/blog/bitgo-tss-a-technical-deep-dive/

7.2 Execução de Transações

• Transações são assinadas por múltiplos fragmentos criptográficos distribuídos.
• A execução é controlada por políticas e regras configuradas no “Policy Engine” (Fireblocks) e nas “Spending Limits & Policies” (BitGo).
• Todos os eventos são registrados para auditoria.

7.3 Custódia dos Instrumentos

• A custódia é realizada exclusivamente pelos ambientes MPC, sem exportação de chaves.
• Não há armazenamento de chaves em arquivos, servidores, dispositivos pessoais ou sistemas internos da Foxbit.

7.4 Particularidades do Bitcoin – Modelo Multisignature (BIP-0011)

Para ativos virtuais baseados na rede Bitcoin, a Foxbit adota práticas compatíveis com as características específicas do protocolo, conforme definido no Bitcoin Improvement Proposal – BIP-0011, que estabelece o uso de endereços multisignature (m-of-n) como mecanismo adicional de segurança e governança. No contexto do Bitcoin:

• As transações do endereço “m-of-n” exigem “m” assinaturas de um conjunto de “n” chaves autorizadas previamente definidas, impedindo que uma única entidade ou ponto de falha consiga movimentar os ativos de forma isolada. Sempre é necessário um quórum mínimo de “m” assinaturas.
• O modelo multisignature reforça:
• segregação de funções;
• controle de alçadas;
• mitigação de riscos operacionais e de comprometimento de chaves.

Quando aplicável operacionalmente, os ambientes Fireblocks e BitGo utilizam estruturas que abstraem o modelo multisig tradicional do Bitcoin, integrando-o ao MPC (Multi-Party Computation) ou ao TSS (Threshold Signature Scheme), mantendo equivalência funcional ao conceito m-of-n descrito no BIP-0011, porém com maior eficiência operacional e sem exposição direta das chaves.

7.5 Geração e Governança de Endereços Bitcoin

No caso do Bitcoin:

• Os endereços são derivados de scripts de bloqueio (scriptPubKey) que incorporam regras de múltiplas assinaturas.
• A definição do quórum (ex.: 2-of-3, 3-of-5) é estabelecida conforme:
• criticidade operacional;
• perfil do ativo (custódia de clientes, liquidez ou tesouraria);
• políticas internas de risco.

Essas regras são configuradas e mantidas:

• por meio do Policy Engine (Fireblocks) ou das Wallet Policies (BitGo);
• sem que a Foxbit detenha acesso direto às chaves privadas ou aos fragmentos criptográficos completos.

7.6 Execução de Transações Bitcoin

Para transações na rede Bitcoin:

• A autorização segue o princípio de assinaturas múltiplas obrigatórias, conforme o quórum definido.
• Cada assinatura corresponde à validação criptográfica exigida pelo script multisig, sendo operacionalizada internamente por MPC/TSS.
• Nenhuma transação Bitcoin é transmitida à rede sem:
• cumprimento integral das políticas de aprovação;
• validação do número mínimo de signatários;
• conformidade com whitelists e limites configurados.

Todos os eventos associados à criação, assinatura e transmissão das transações Bitcoin são registrados, auditáveis e protegidos contra alteração.

7.7 Mitigação de Riscos Específicos do Bitcoin

Considerando as características do Bitcoin:

• A exigência de múltiplas assinaturas reduz riscos de:
• comprometimento individual de chaves;
• erro humano;
• acesso indevido.
• Em caso de indisponibilidade de um signatário ou fragmento:
• o modelo m-of-n permite continuidade operacional dentro do quórum definido;
• os procedimentos de recovery das plataformas Fireblocks e BitGo garantem a restauração segura do acesso, sem reconstrução de chaves privadas completas.

7.8 Compatibilidade entre MPC/TSS e Multisignature Bitcoin

A Foxbit reconhece que o multisig tradicional do Bitcoin (BIP-0011) e os modelos MPC/TSS modernos possuem equivalência funcional do ponto de vista de controle, segurança e governança, sendo o MPC/TSS uma evolução tecnológica que:

• preserva o conceito de múltiplos signatários;
• elimina complexidades operacionais;
• reduz riscos de exposição de chaves.

Essa compatibilidade assegura aderência às melhores práticas do ecossistema Bitcoin, sem comprometer eficiência, escalabilidade ou segurança.

7.9 Distribuição de Ativos Virtuais em Carteiras

Os ativos virtuais sob custódia são distribuídos entre carteiras com diferentes níveis de exposição e de exigência de aprovação, observando:

• carteiras operacionais (hot), destinadas ao atendimento de depósitos, saques e liquidez diária, mantidas com saldos limitados ao necessário para a operação;
• carteiras de armazenamento (warm/cold), com regras de aprovação mais restritivas e quórum ampliado, destinadas à guarda dos saldos que excedem a necessidade operacional;
• limites de saldo por carteira definidos pelo Financeiro/Tesouraria em conjunto com Segurança da Informação, considerando volume operacional, demanda de saques e risco;
• recomposição entre carteiras somente mediante aprovação, conforme as alçadas definidas nesta Política;
• revisão periódica dos limites e da distribuição.

7.10 Segregação Patrimonial

Os ativos virtuais de clientes são mantidos segregados dos ativos próprios da Foxbit, por meio de carteiras, contas e registros distintos nas plataformas de custódia, com:

• registro individualizado das posições de cada cliente;
• conciliação periódica entre os saldos custodiados e as posições registradas;
• vedação ao uso de ativos de clientes para finalidades próprias da Foxbit.

7.11 Módulos de Segurança Utilizados

Fireblocks:

• MPC-CMP (assinaturas distribuídas);
• Secure Enclave e SGX;
• Policy Engine (workflow, whitelists, limites);
• Just-in-time access (zero standing privilege);
• Device & identity binding.

Fonte: https://ncw-developers.fireblocks.com/docs/main-capabilities

BitGo:

• TSS wallets (multi-party signing);
• HSM-backed key shares;
• Spending limits, policy rules e whitelists;
• Autenticação forte e MFA.

Fonte: https://www.bitgo.com/resource-center/bitgo-policies/

7.12 Concessão e Desativação dos Instrumentos de Controle

Concessão: o acesso é concedido com base em:

• verificação de identidade;
• perfil RBAC definido (operador, aprovador, administrador de políticas etc.);
• política de menor privilégio;
• liberação específica por gestor responsável;
• aprovação dupla para perfis sensíveis;
• vinculação a dispositivos autenticados (Fireblocks Device Binding).

Nenhum acesso é concedido a chaves privadas – apenas a funções dentro da plataforma.

Desativação: o desligamento segue procedimento imediato:

• remoção de credenciais;
• bloqueio de dispositivo vinculado;
• revogação de tokens de API;
• invalidação de funções e permissões;
• registro automático no log da plataforma.

Ambas as plataformas possuem controle centralizado de usuários e logs auditáveis.

7.13 Mitigação de Comprometimentos

A detecção, contenção e mitigação utilizam recursos nativos Fireblocks e BitGo:

Detecção:

• alertas nativos por comportamento atípico;
• bloqueio automático de transações fora da política;
• logs imutáveis analisados continuamente.

Contenção:

• bloqueio de carteiras no ambiente Fireblocks (“Freeze”) – Fonte: https://developers.fireblocks.com/reference/freezetransaction;
• desativação de políticas ou de usuários em BitGo – Fonte: https://www.bitgo.com/resources/bitgo-policies/;
• bloqueio de chaves de API;
• aumento forçado de quórum ou aprovação manual (Fireblocks Policy Engine).

Recuperação:

• o modelo MPC permite reconstituição segura dos fragmentos por recovery interno Fireblocks/BitGo;
• reconstrução dos módulos de acesso por administradores autorizados;
• revisão pós-incidente e registro em ata.

7.14 Regras de Acesso e Alçadas

Papéis (RBAC):

• Operador: inicia transações, sem poder aprovar;
• Aprovador: valida e aprova operações conforme limites;
• Administrador de Políticas: cria e edita regras e limites;
• Administrador de Plataforma: gerencia usuários, dispositivos e integrações.

Alçadas e limites, configurados conforme:

• limites de valor por transação (Fireblocks Spending Controls);
• whitelists obrigatórias;
• restrições por horário, origem e dispositivo;
• transações críticas exigem múltiplos aprovadores.

Referências: Fireblocks Policy Engine – https://www.fireblocks.com/platforms/governance-and-policies/; BitGo Spending Limits – https://www.bitgo.com/resources/bitgo-policies/

Zero Standing Access: nenhum colaborador tem acesso direto a chaves ou fragmentos.

7.15 Protocolos de Acesso, Armazenamento e Proteção

• autenticação forte (MFA) obrigatória;
• comunicação criptografada;
• armazenamento exclusivo em enclaves MPC;
• distribuição física e lógica dos fragmentos;
• restrições por IP, rede e dispositivo;
• monitoramento contínuo.

Fireblocks e BitGo atendem requisitos de criptografia e isolamento físico/lógico por padrão.

7.16 Monitoramento Contínuo e Redundância

• Os eventos das plataformas de custódia são monitorados continuamente, com alertas tratados conforme o Plano de Resposta a Incidentes;
• Os mecanismos de redundância e de recovery das plataformas são testados periodicamente, com registro dos resultados;
• Os prestadores de serviços de custódia são avaliados periodicamente quanto a certificações, relatórios de auditoria e continuidade de negócios.

8. Penalidades

O descumprimento desta Política e/ou dos demais instrumentos normativos que a complementam constitui falta grave e sujeita o responsável à aplicação de medidas disciplinares, incluindo advertência, suspensão ou desligamento, sem prejuízo das sanções legais e contratuais cabíveis.

Situações de exceção e casos omissos serão avaliados por Segurança da Informação e, quando necessário, submetidos à Diretoria.

9. Documentos de referência

• Política Geral de Segurança da Informação (POL_SI_01);
• Plano de Continuidade de Negócios;
• Plano de Resposta a Incidentes;
• Política de Gestão de Identidades e Acessos (IAM);
• Política de Listagem e Deslistagem de Ativos Virtuais.

10. Anexos

Não há anexos nesta versão.

11. Vigência

A presente política entra em vigor a partir da data da última assinatura do documento e tem validade de até 1 (um) ano ou em prazo inferior, nas hipóteses de alteração da legislação aplicável ou de direcionamento estratégico da Foxbit. Deve ainda ser revisada sempre que houver mudanças tecnológicas nas plataformas Fireblocks/BitGo, novas exigências regulatórias, incidentes relevantes ou ampliação de serviços.