Tipos de Carteiras

Toda carteira faz os mesmos dois trabalhos - guardar um keypair e assinar transações com ele - mas diferem enormemente em como esse keypair é armazenado e quem pode disparar uma assinatura. Este tutorial percorre as cinco categorias de carteiras Solana que você vai encontrar, para que serve cada uma e por que um número crescente de equipes adiciona um multisig sobre todas elas.

O Que É uma Carteira Solana?

Uma carteira não é um contêiner para seu SOL. Seu saldo vive on-chain, em uma conta que a rede já conhece. Uma carteira é o software ou hardware que guarda a chave privada dessa conta e a usa para assinar transações em seu nome.

Toda carteira Solana é construída em torno de um keypair - uma chave pública que identifica a conta e uma chave privada que prova propriedade. Se você já leu Keypairs e Endereços, é o mesmo keypair; uma carteira é simplesmente a camada de software que o armazena com segurança e pede sua aprovação antes de assinar.

A maioria das carteiras Solana é não custodial, o que significa que só você guarda a chave privada, e perdê-la significa perder acesso permanentemente - não há reset de senha. Um número menor de carteiras hospedadas em exchanges é custodial, o que significa que a exchange guarda a chave em seu nome e você confia que ela assinará corretamente.

O tipo de carteira que você escolhe é, na verdade, uma decisão sobre onde essa chave privada vive - em um processo de navegador, no seu celular, em um dispositivo físico separado, em um arquivo simples ou distribuída entre vários signatários que precisam concordar. Cada resposta troca conveniência por segurança de forma diferente.

Termos-Chave

Por Que o Tipo de Carteira Importa

Os exemplos públicos em devnet ao longo deste guia usam um único arquivo keypair CLI, porque é a forma mais simples de acompanhar. Uso real parece diferente dependendo de quem assina e do que está em jogo.

Um indivíduo guardando uma pequena quantidade de SOL para testes tem necessidades muito diferentes de uma tesouraria de DAO com milhões de dólares em fundos da comunidade. O primeiro pode razoavelmente priorizar conveniência; o segundo não pode permitir que um único laptop comprometido drene a tesouraria.

Como regra geral, conveniência e segurança se movem em direções opostas. Carteiras de navegador são as mais rápidas de usar e as mais fáceis de comprometer via phishing; carteiras hardware são as mais lentas de usar e as mais difíceis de comprometer remotamente. Multisigs adicionam atrito (toda transação precisa de múltiplas aprovações) especificamente para remover o ponto único de falha que qualquer carteira - quente ou fria - ainda tem por si só.

Principais Tipos de Carteiras Solana (em 2026)

1. Carteiras de Software Quente (Extensões de Navegador / Web / Apps Desktop)

Apps e extensões conectados à internet para uso diário, dApps, trading, NFTs e staking. Convenientes, mas menos seguras para grandes holdings.

Mais populares:

• Phantom - Mais popular no geral, multi-chain, excelente UX, NFTs e integração com dApps.
• Solflare - Forte foco nativo Solana, staking/DeFi avançado, suporte a hardware.
• Backpack - Usuários avançados, xNFTs, ferramentas avançadas.
• Glow - Amigável para iOS, nativo Solana com swaps/staking.
• Outras (ex.: Jupiter Wallet, Exodus) - Focadas em trading ou opções multi-chain.

2. Carteiras Mobile

Apps para iOS/Android, frequentemente sobrepostas com carteiras de software quente, já que muitas também têm extensões de navegador. Ótimas para uso em movimento.

Mais populares:

• Phantom (app mobile)
• Solflare (app mobile)
• Backpack (app mobile)
• Trust Wallet ou Coinbase Wallet (multi-chain com forte suporte Solana)
• Glow ou outras como TokenPocket/FoxWallet.

3. Carteiras Hardware / Cold

Dispositivos físicos para armazenamento offline de chaves. Maior segurança para holdings de longo prazo; geralmente pareadas com software de carteira quente para assinatura.

Mais populares (menos opções dedicadas):

• Ledger (Nano S, Flex, Stax, etc.) - Mais usada, integra com Phantom/Solflare.
• Solflare Shield - Armazenamento cold nativo mobile-first.
• Keystone - Assinatura air-gapped via QR.
• Trezor (Model T/Safe) - Bom suporte multi-chain.
• Tangem ou OneKey - Alternativas estilo cartão ou open-source.

4. Carteiras CLI / Sistema de Arquivos

Ferramentas de linha de comando para desenvolvedores e usuários avançados. Minimalistas, scriptáveis, sem GUI - é o que todo exemplo CLI anterior neste guia usou.

Principais opções (não há muitas "populares" para consumidor):

• Keypair padrão do sistema de arquivos do Solana CLI, ex. ~/.config/solana/id.json.
• Paper wallets, geradas via ferramentas CLI e mantidas totalmente offline.
• Integração com hardware no CLI (ex.: assinar com Ledger nos comandos solana).

5. Carteiras Multisig (Uso em Equipe / DAO / Tesouraria)

Um multisig não é uma carteira em que você entra pessoalmente - é uma conta on-chain controlada por um conjunto de signatários aprovados, cada um dos quais normalmente usa um dos tipos de carteira acima (frequentemente uma carteira hardware) para aprovar ou rejeitar uma transação proposta. Nada executa até signatários suficientes concordarem.

Mais populares:

• Squads (squads.so) - Protocolo multisig/smart-account nativo Solana dominante, usado por muitas DAOs, tesourarias de protocolos e autoridades de upgrade de programas.
• SPL Governance / Realms - Programa de governança on-chain da Solana Foundation; DAOs o usam para controle de tesouraria e votação de propostas, funcionando de forma similar a um multisig com limiar de votação em vez de lista fixa de signatários.
• Multisig nativo SPL Token - Não é um app standalone, mas recurso do próprio programa SPL Token: a autoridade de mint ou freeze de um token pode ser definida diretamente para uma conta multisig M-of-N, independente de qualquer produto de terceiros.

Por que usar multisig? Um único keypair é um ponto único de falha - se aquele dispositivo, seed phrase ou chave for comprometido, tudo que controla se perde. Um multisig remove esse ponto único de falha exigindo, digamos, 2 de 3 ou 3 de 5 signatários aprovados para concordar antes de uma transação executar. Por isso tesourarias de DAO, fundos de empresas e autoridades de upgrade de programas geralmente ficam em multisig em vez da carteira de uma pessoa: nenhum laptop comprometido, signatário phishado ou membro de equipe saindo pode mover fundos ou empurrar um upgrade sozinho.

Notas: A maioria dos usuários individuais fica com carteiras não custodiais de autocustódia das quatro primeiras categorias. Popularidade é impulsionada por base de usuários (Phantom lidera com milhões de usuários), compatibilidade com dApps e recursos nativos Solana. Multisigs importam quando fundos ou autoridade são compartilhados entre mais de uma pessoa - sempre verifique premissas de segurança e use carteiras hardware para os signatários individuais em qualquer coisa com valor significativo. Dados refletem tendências do ecossistema em 2026 e mudam conforme novas carteiras e ferramentas surgem.

Passo a Passo

Passo 1: Escolha uma carteira para desenvolvimento local

Para seguir os exemplos de código neste guia, um keypair CLI no sistema de arquivos basta - é o que solana-keygen já produz.

solana-keygen new --no-bip39-passphrase -o ./dev-keypair.json --force
solana-keygen pubkey ./dev-keypair.json

Este keypair é um arquivo JSON simples. Trate-o como qualquer outro segredo - nunca faça commit e nunca reutilize um arquivo keypair de devnet para fundos em mainnet.

Passo 2: Leia o mesmo keypair a partir do código

Qualquer ferramenta feita para usuários reais deve conseguir carregar o mesmo formato de arquivo que o CLI produz, para você testar localmente com o keypair exato que uma carteira assinaria de outra forma.

import { readFileSync } from "node:fs";
import { createKeyPairSignerFromBytes } from "@solana/kit";
 
const secretKeyBytes = new Uint8Array(
  JSON.parse(readFileSync("./dev-keypair.json", "utf-8"))
);
const signer = await createKeyPairSignerFromBytes(secretKeyBytes);
console.log("Loaded signer:", signer.address);

Passo 3: Adicione uma carteira de navegador para testar dApps

Quando você estiver testando um frontend real, um keypair CLI não pode aprovar um popup de navegador - você precisa de uma carteira de extensão como Phantom ou Solflare instalada e apontada para o mesmo cluster devnet que seu código usa.

// Detect an installed browser wallet before prompting for connection
const provider = (window as any).phantom?.solana;
if (!provider?.isPhantom) {
  throw new Error("Install Phantom or another Solana wallet extension");
}
const { publicKey } = await provider.connect();
console.log("Connected wallet:", publicKey.toString());

Passo 4: Mova fundos significativos para uma carteira hardware

Antes de qualquer valor real estar envolvido, a chave de assinatura deve sair de um processo de navegador e ir para um dispositivo hardware, para que uma máquina comprometida não drene a conta silenciosamente.

# Point the CLI at a Ledger-backed keypair path instead of a JSON file
solana config set --keypair "usb://ledger?key=0"
solana balance

Passo 5: Mova fundos compartilhados ou de alto valor para um multisig

Para qualquer coisa controlada por mais de uma pessoa - fundo de equipe, tesouraria de DAO, autoridade de upgrade de programa - o destino não é uma única carteira hardware, mas uma conta multisig que vários signatários com carteiras hardware controlam juntos.

# Conceptual - actual commands depend on the multisig tooling (e.g. Squads CLI/SDK)
# 1. Create a multisig with a signer list and threshold (e.g. 2-of-3)
# 2. Set the multisig's vault address as the program's upgrade authority
#    or as the recipient of treasury funds
solana program set-upgrade-authority <PROGRAM_ID> --new-upgrade-authority <MULTISIG_VAULT_ADDRESS>

Juntando Tudo

// wallet-selection.ts - Solana Kit 7.0.0
import { readFileSync } from "node:fs";
import { createKeyPairSignerFromBytes, address } from "@solana/kit";
 
// Local dev: load a CLI file system keypair directly
async function loadDevSigner(path: string) {
  const bytes = new Uint8Array(JSON.parse(readFileSync(path, "utf-8")));
  return createKeyPairSignerFromBytes(bytes);
}
 
// Production reads: never assume a single signer - a treasury address
// may resolve to a multisig vault rather than a personal wallet
async function describeAuthority(authority: string) {
  const knownMultisigVault = address("REPLACE_WITH_YOUR_SQUADS_VAULT");
  const isMultisig = address(authority) === knownMultisigVault;
  console.log(
    isMultisig
      ? "Authority is a multisig vault - expect multiple approvals before changes land"
      : "Authority is a single keypair - one signature is sufficient"
  );
}
 
const devSigner = await loadDevSigner("./dev-keypair.json");
console.log("Dev signer:", devSigner.address);
await describeAuthority(devSigner.address);

Esta é a forma na qual a maioria dos projetos reais converge: um keypair simples no sistema de arquivos para desenvolvimento local, uma carteira de navegador ou hardware para qualquer coisa que um humano assina diretamente, e um endereço de vault multisig - não uma chave pessoal - para qualquer coisa que a equipe ou uma DAO controla junto. Seu código de aplicativo basicamente só precisa saber com que tipo de endereço está lidando, já que um vault multisig assina da mesma forma que qualquer outra conta do ponto de vista da rede.

Erros Comuns de Iniciantes

• Manter fundos significativos em carteira quente de navegador por longo prazo - extensões de navegador são o alvo de phishing mais comum no ecossistema. Correção: trate carteiras quentes como dinheiro de gasto e mova qualquer coisa que você ficaria chateado em perder para uma carteira hardware.
• Perder a seed phrase ou armazená-la digitalmente - um screenshot ou nota na nuvem de uma seed phrase está a um vazamento de dados de uma carteira totalmente comprometida. Correção: anote fisicamente, guarde offline e nunca digite em um site.
• Assumir que carteira hardware sozinha basta para fundo de equipe - uma carteira hardware ainda é um ponto único de falha se aquela pessoa sair, perder o dispositivo ou for comprometida. Correção: use multisig quando mais de uma pessoa precisa de controle, não apenas uma carteira única "melhor".
• Tratar multisig como substituto de boa higiene de chaves por signatário - um multisig 2-of-3 em que os três signatários guardam chaves da mesma forma insegura não é muito mais seguro que uma carteira. Correção: cada signatário individual ainda deve seguir práticas de nível carteira hardware.
• Reutilizar keypair CLI de devnet como signatário de mainnet "só desta vez" - o keypair funciona em ambos, então é fácil fazer por acidente. Correção: mantenha arquivos keypair separados por cluster, conforme orientação em Clusters e Redes.
• Aprovar transação multisig sem ler independentemente o que ela faz - aprovar propostas no automático anula o propósito de exigir múltiplos signatários. Correção: todo signatário deve decodificar e verificar uma proposta antes de aprovar, não apenas confiar que alguém verificou.

FAQs

Related

• Carteiras e Exploradores - fluxo devnet, faucets e leitura do Solana Explorer
• Keypairs e Endereços - como o keypair que todo tipo de carteira envolve realmente funciona
• Clusters e Redes - alinhar seleção de rede da carteira ao cluster certo
• Provedores RPC - o endpoint que sua carteira ou app usa quando lê ou envia em seu nome

Stack versions: This page was written for Agave 4.1.1, Solana CLI 3.0.10, @solana/kit 7.0.0, and Squads V4 (multisig program).