Solana Mobile em Profundidade

Solana Mobile não é um ledger separado nem um RPC especial. É uma stack de cliente e distribuição para apps Solana Android-first: carteiras e dApps conversam por um protocolo mobile padronizado, chaves podem viver em armazenamento com respaldo em hardware em dispositivos suportados, e descoberta pode rodar por uma loja construída para apps crypto em vez de somente extensões de navegador.

Desktop e mobile web ainda importam, mas fluxos nativos de telefone mudam a superfície de integração. Não há window.solana. Usuários saem do seu processo para um app de carteira e retornam por intents. Assinatura pode ser limitada por biometria e secure element. Envio frequentemente mira a Solana Mobile dApp Store além de (ou em vez de) somente Google Play.

Esta página é o guarda-chuva da seção para essa stack e o caminho de build React Native com @solana/kit 7.0.0. Páginas irmãs aprofundam cada ramo.

Resumo

• Solana Mobile é uma stack de produto centrada em Android onde dApps autorizam e assinam via Mobile Wallet Adapter, opcionalmente respaldados por Seed Vault em hardware em dispositivos classe Seeker, retornam via deep links e tokens de sessão, e distribuem pela dApp Store (e canais Android padrão) enquanto constroem transações com o mesmo modelo kit/RPC que clientes web.
• Por que Importa: Tratar mobile como "web responsiva com botão de carteira" produz fluxos authorize quebrados, sessões perdidas após saltos de carteira, armazenamento local inseguro de chaves e revisões de loja falhas. Um mapa compartilhado de sessões MWA, fronteiras de confiança Seed Vault e restrições de release/distribuição previne essas classes de bugs.
• Conceitos Chave: Solana Mobile Stack (SMS), Mobile Wallet Adapter (MWA), transact / authorize / reauthorize / deauthorize`, Seed Vault, secure element, deep link / intent filter, auth token, dApp Store, Seeker / Saga, Expo dev client, @solana/kit.
• Quando Usar: Primeira orientação antes de scaffoldar dApp mobile; escolher MWA vs custódia embutida; projetar UX connect/sign/return; planejar segurança alvo Seeker e submissão de loja.
• Limitações / Trade-offs: Android e maturidade MWA lideram iOS; Seed Vault depende de dispositivo/carteira; Expo Go não basta para módulos nativos MWA; alcance dApp Store é crypto-native, não escala mass-market Play; programas on-chain e consenso Agave são inalterados.
• Tópicos Relacionados: Noções básicas Solana Mobile, MWA, construir dApp mobile, deep links e sessões, segurança Seed Vault e dApp Store.

Fundamentos

Solana Mobile Stack é o nome do produto para três peças cooperantes:

1. Mobile Wallet Adapter - protocolo e SDKs que permitem dApp solicitar autorização e assinaturas de app de carteira sem embutir chaves privadas.
2. Seed Vault - armazenamento de seed e chaves com respaldo em hardware em dispositivos Solana Mobile suportados, exposto por carteiras que implementam o caminho seguro.
3. dApp Store - canal de distribuição e descoberta para apps mobile Solana, especialmente os que miram Seeker (e Saga anterior).

Marcas de hardware (Saga, Seeker) são dispositivos e ecossistemas, não novas máquinas virtuais. Transações ainda atingem os mesmos clusters pela mesma superfície RPC que web. Agave 4.1.1, Anchor 0.32.1 e @solana/kit 7.0.0 permanecem a stack voltada à chain; mobile muda como usuários assinam e como você envia o cliente.

Mobile Wallet Adapter é o contrato de integração. Seu app apresenta uma identity (name, URI, icon), solicita authorize para um cluster, recebe accounts e um auth token, depois pede à carteira para assinar transações ou mensagens dentro de sessão delimitada (comumente o helper transact). A UI da carteira possui folhas de aprovação e prompts biométricos; seu app possui bytes de transação serializados e sendTransaction / confirmação pós-sign contra RPC.

Seed Vault é a fronteira de confiança para chaves em hardware suportado. O material de seed fica fora do bundle React Native e fora de armazenamento comum do app. Quando carteira roteia assinatura por Seed Vault, chaves privadas nunca se tornam memória legível do app. Seu trabalho de segurança é mais estreito e mais rígido: não invente mnemonics locais, proteja auth tokens e trate bytes wire de transação e logs como sensíveis o suficiente para não despejar por inteiro em produção.

Deep links e sessões são a cola do ciclo de vida. Authorize e sign frequentemente trocam para outra activity Android (a carteira). Intent filters corretos, schemes de retorno e reauthorize com token armazenado decidem se usuários reentram experiência conectada ou batem em beco sem saída após aprovação. Cold start (processo do app morto enquanto usuário está na carteira) é caso de primeira classe, não edge case.

dApp Store é como muitos usuários Solana Mobile encontram e instalam apps. Submissão precisa artefatos de release assinados, política de privacidade, reivindicações honestas de rede e caminho MWA funcional em hardware de revisão. É política de distribuição e empacotamento, não segunda blockchain.

Construir um dApp mobile geralmente significa React Native (frequentemente Expo com dev client customizado para módulos nativos MWA carregarem), construção RPC e transação baseada em kit, e MWA para connect/sign. Monorepos podem compartilhar clientes kit gerados com web; somente a camada de anexo de carteira diverge.

  User on Seeker / Android
       |
       v
  Your dApp (React Native + @solana/kit)
       |  build unsigned tx bytes / messages
       |  transact() -> authorize / sign
       v
  Wallet app  ---- optional ----> Seed Vault (secure element)
       |  approve + signatures
       |  intent / deep link return
       v
  Your dApp resumes session (auth token)
       |  sendTransaction + wait commitment
       v
  RPC -> Agave cluster (same as web)

Mecânica e Interações

Ciclo de vida de sessão MWA

Sequência mental produtiva para toda tela que precisa de carteira:

1. Authorize (ou reauthorize com token em cache) com metadata identity completa e string cluster correta para seu RPC.
2. Leia accounts do resultado; armazene endereço público para UI e seleção de fee-payer; armazene auth token em armazenamento seguro, não logs simples.
3. Construa mensagens de transação com @solana/kit 7.0.0 como faria na web: instruções, metas de conta, blockhash, fee payer.
4. Entre em transact, sign dentro do callback, saia da sessão rapidamente (UIs de carteira fazem timeout em trabalho longo).
5. Submeta assinaturas por RPC HTTPS, depois espere confirmed ou finalized conforme risco do produto.
6. Deauthorize e limpe token no logout ou quando reauthorize falhar e você forçar authorize completo novamente.

Mismatch de cluster é a falha silenciosa clássica: authorize para devnet enquanto RPC aponta mainnet-beta (ou o inverso). Trate cluster como um objeto de config compartilhado por MWA, RPC kit e links de explorer.

Deep links, intents e resume

Android move o usuário entre pacotes. Intent filters Expo app.json / prebuild e scheme customizado estável (ou app links verificados) são requisitos de produto, não polimento.

Trate warm resume (processo vivo; restaura UI pendente), cold start (processo morto; restaura token, reauthorize, reidrata navegação), cancelamento do usuário (rejeite limpo; ofereça retry) e token obsoleto (fallback para authorize completo). Prefira secure store da plataforma para auth tokens em vez de AsyncStorage simples.

Seed Vault e segurança no lado do app

MWA já mantém assinatura fora do seu processo quando usuário usa carteira externa. Seed Vault fortalece isso em dispositivos suportados vinculando chaves a hardware seguro e biometria mediada pela carteira.

Regras no lado do app: nunca envie seed phrases em bundles JS ou armazenamento do app; minimize dumps completos de transação em logs; mantenha keypairs de servidor fora do dispositivo; endurecimento opcional inclui flags de screenshot e detecção de root para produtos de alto valor.

Build e envio

# Scaffold (see current create-solana-dapp mobile options)
npx create-solana-dapp@latest --mobile
 
# Expo: custom dev client required for native MWA modules
npx expo start --dev-client
 
# Release artifact for store submission
eas build --platform android --profile production

Teste MWA em dispositivos físicos cedo; emuladores representam mal handoff de intent. Lógica on-chain ainda usa CLI, Surfpool e LiteSVM como web; mock MWA em testes unitários mobile. Submissão dApp Store precisa assinatura de produção, bumps versionCode, URLs de privacidade e suporte, e build que completa authorize/sign em hardware de referência. Dual-track Play Store para alcance em massa; dApp Store para descoberta Solana Mobile.

Considerações Avançadas e Aplicações

Clientes monorepo compartilhados. Compartilhe builders de instrução, tipos IDL e helpers RPC entre Next.js e React Native; isole MWA, deep links e armazenamento seguro no app mobile para upgrades Anchor 0.32.1 permanecerem alinhados.

UX de sessão e identidade. Reauthorize para baixa fricção; force authorize completo após mudanças de privilégio ou sessões falhas. Name, URI e icon estáveis de identity reduzem confusão de phishing e devem corresponder a assets de listagem da loja. Reconexão silenciosa é ok para UX de leitura; sign de alto valor deve sempre parecer deliberado.

iOS, redes e risco de programa. Android-first é o padrão honesto até sua matriz de carteiras cobrir iOS; mobile web pode fazer ponte para usuários interim. Projete retries RPC e esperas de commitment para celular instável; assinatura local não é liquidação. PDAs, metas de conta e regras CU são idênticas à web - mobile é preocupação de cliente; auditorias on-chain ainda dominam risco de protocolo.

Equívocos Comuns

• "Solana Mobile é chain ou runtime diferente." É protocolo de cliente, armazenamento de chaves em hardware e distribuição. Programas e contas são o mesmo modelo Solana em clusters Agave.
• "Posso usar Expo Go como qualquer demo RN." MWA precisa módulos nativos e dev client customizado (ou bare workflow). Expo Go sozinho não é caminho de produção.
• "MWA é só window.solana no Android." Não há inject de extensão. Sessões, intents, metadata identity e auth tokens são o contrato.
• "Armazenar mnemonic no app é ok se criptografado com PIN." Prefira carteira externa + Seed Vault. Seeds mantidos no app expandem modos de breach e falha de backup.
• "Se authorize passou uma vez, deep links não importam." Todo sign pode sair do seu processo. Caminhos de retorno e resume cold-start decidem se usuários terminam o fluxo.
• "dApp Store substitui higiene de release de engenharia." Você ainda precisa builds release assinados, versionamento, política de privacidade e QA em dispositivo.
• "@solana/web3.js v1 é obrigatório para mobile." Prefira @solana/kit 7.0.0 para trabalho novo com pacotes MWA que aceitam formatos wire kit.

FAQs

Relacionados

• Noções Básicas de Solana Mobile - visão do stack e primeiros exemplos mobile
• Mobile Wallet Adapter (MWA) - authorize, sign e API de sessão
• Construindo um dApp Mobile - React Native, Expo e integração kit
• Deep Links e Tratamento de Sessão - intents, caminhos de retorno, auth tokens
• Seed Vault e Segurança - chaves com respaldo em hardware e modelo de ameaça do app
• A dApp Store - empacotamento, metadata e distribuição

Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0.