Blueprint de Tokenomics
Tokenomics na Solana é o circuito fechado que precifica segurança, inclusão e mudança de protocolo: emissão e diluição, stake que reivindica recompensas, taxas e gorjetas para espaço de bloco, e governança que atualiza as regras. Uma vez que você veja essas peças como uma única máquina, a UX de staking, integrações de LST, lances de taxa e design ciente de SIMD param de parecer domínios separados.
Noções Básicas de Economia é a entrada de taxas prática; Inflação e Recompensas de Stake, Stake e Delegação, Liquid Staking e LSTs, Mercados de Taxas de Prioridade, MEV na Solana, Governança e SIMDs, e Realms e Governança On-Chain cada um foca em um mecanismo. Esta página fica abaixo: como o sistema econômico se encaixa para desenvolvedores.
Resumo
- A economia nativa da Solana acopla recompensas de stake financiadas por inflação, delegação a validadores, mercados de taxas de transação, caminhos de gorjetas de MEV e governança para que capital, segurança e espaço de bloco sejam liquidados sob regras compartilhadas.
- Por que Importa: Decisões de produto, DeFi e infraestrutura repousam sobre os mesmos fluxos: onde o SOL é emitido, quem o ganha, o que os usuários pagam para pousar, e como os parâmetros mudam.
- Conceitos Chave: inflação / emissão, stake ativo e comissão, contas de stake e épocas, liquid staking tokens (LSTs), taxa base vs taxa de prioridade, gorjetas / pacotes de MEV, SIMDs, DAOs de Realms.
- Quando Usar: Projetando UX de staking ou LST, dimensionando estratégia de taxas sob carga, modelando SOL do tesouro, lendo governança que muda recompensas ou taxas, ou integrando engenheiros que conhecem o runtime, mas não os fluxos de capital.
- Limitações / Trade-offs: Cronogramas e taxas são parâmetros do protocolo que a governança pode mudar; LSTs adicionam risco de smart contract e liquidez; caminhos de taxas e MEV não são um único controle; o APR exato depende da participação, comissão e resultados da época.
- Tópicos Relacionados: noções básicas de economia, inflação e recompensas de stake, stake e delegação, liquid staking, taxas de prioridade, MEV, SIMDs, Realms.
Fundamentos
A Solana não executa um "subsistema de tokenomics" separado ao lado do runtime. A mesma unidade nativa (SOL, em lamports) paga taxas, financia depósitos isentos de aluguel, garante stake e frequentemente carrega peso de governança.
A segurança é comprada com capital em stake que reivindica emissão. A inclusão é comprada com taxas e frequentemente gorjetas. Regras de mercado de longa duração são atualizadas através da governança, não apenas chaves de administrador de aplicativo.
Pense em quatro loops acoplados:
Emissão (inflação)
|
v
Recompensas de stake <---- stake ativo / desempenho do validador
|
+----> mais capital em stake ou encapsulado como LSTs
|
Usuários / apps ---- taxas + gorjetas ----> líderes / validadores / pipelines de MEV
|
Governança (SIMDs, Realms) ---- atualiza parâmetros, programas, tesourariasEmissão aumenta o suprimento de SOL em um cronograma de inflação on-chain que diminui ao longo do tempo em direção a um piso de longo prazo. As taxas exatas residem nos parâmetros do cluster e podem mudar com a governança; prefira modelos estruturais em vez de um APR de blog. Novo SOL vai principalmente para o caminho de recompensa de stake para que o capital de segurança seja compensado em relação ao capital ocioso.
Staking não é "enviar SOL para uma carteira de validador". É bloquear SOL em contas de stake, delegar para uma conta de voto, e esperar através da ativação com limite de época antes que o stake seja totalmente elegível para recompensa. A desativação é escalonada; o unstaking não é uma transferência instantânea.
Taxas pagam pela execução e competem por capacidade escassa. Uma pequena taxa base se anexa às assinaturas; taxas de prioridade aumentam o preço da unidade de computação sob contenda. Uma grande parte das taxas é tipicamente queimada, compensando parcialmente a emissão (trate a parte queimada como sensível a parâmetros).
MEV é valor de ordenação, inclusão e arbitragem. Frequentemente surge como gorjetas e pacotes fora do campo de taxa de prioridade simples. Taxas e gorjetas compram inclusão, mas não são o mesmo caminho de ledger.
Governança abrange a evolução do protocolo (SIMDs) e DAOs de aplicativos (Realms). Política de taxas, parâmetros de inflação, portões de recursos e atualizações podem remodelar a economia do produto sem seu próximo deploy.
Mecânicas e Interações
Inflação se torna recompensas de stake
A cada época, o protocolo emite SOL de acordo com o cronograma de inflação e distribui recompensas para o stake ativo em validadores votantes. A comissão de um validador é retirada antes que o restante seja creditado aos delegadores.
emissão de inflação (época)
|
v
recompensas para validadores performáticos
|
+-- comissão --> operador do validador
|
+-- restante --> contas de stake (delegadores)O rendimento realizado não é "a taxa de inflação principal". Depende da participação do stake, desempenho do validador (uptime, créditos de voto, não inadimplência), comissão, e quanto tempo o stake esteve ativo. SOL não em stake é diluído: o suprimento cresceu sem uma reivindicação de recompensa compensatória.
Para matemática de produto, use recompensa ≈ f(inflação, proporção_de_stake, comissão, desempenho) e leituras RPC ao vivo em vez de um APR fixo de marketing.
Delegação é estado da conta ao longo do tempo
Uma conta de stake contém lamports e estado de stake. A delegação aponta esses lamports para uma conta de voto. A ativação e desativação se movem através dos limites da época.
SOL da Carteira
|
v
Conta de stake --delegar--> Conta de voto (validador)
| |
| +--> votos / ganha créditos
v
ativando -> ativo -> desativando -> inativo (sacável sob regras)A UX de staking deve expor aquecimento/resfriamento, conta de voto errada (zero recompensas), mesclar/dividir, e autoridade de saque vs autoridade de stake. Leia getEpochInfo em vez de assumir o comprimento da época em tempo de relógio.
LSTs encapsulam a mesma reivindicação econômica
Um token de liquid staking (LST) é geralmente um token SPL que representa uma reivindicação sobre SOL em stake através de um pool ou protocolo (exemplos incluem mSOL, jitoSOL e outros; a liquidez frequentemente envolve roteamento estilo Sanctum). Os usuários depositam SOL, o protocolo faz o stake, e os usuários recebem um token transferível utilizável em DeFi.
A reivindicação ainda é "SOL em stake ganhando recompensas", com composabilidade e frequentemente saída de mercado mais rápida, além de risco de smart contract, liquidez, paridade e governança do provedor.
| Dimensão | Stake nativo | LST |
|---|---|---|
| Forma do ativo | Estado da conta de stake | Token SPL fungível |
| Liquidez | Desfazer stake + cooldown | Negociar LST se mercados profundos |
| Caminho de recompensas | Acumula no stake / reivindicações | Crescimento da taxa de câmbio ou rebalanceamento |
| Controle | Escolher validador (ou regras do pool) | Aceitar conjunto de provedor e taxas |
| Custo de integração | Programa de stake + UX de época | Contas de token, CPI de pool, casos de desparidade |
| Melhor ajuste | Participação direta na segurança | Colateral DeFi, loops, liquidez instantânea |
Se seu aplicativo detém SOL produtivo do usuário, decida se você precisa de stake nativo, um LST, ou um recibo de pool de stake, e documente os modos de falha.
Taxas de prioridade limpam mercados locais de espaço de bloco
Sob carga, nem todas as transações válidas pousam. Clientes definem um limite de unidade de computação e preço da unidade de computação via instruções do Compute Budget para que os líderes possam classificar o trabalho por intensidade de taxa.
A taxa base é o custo de assinatura e inclusão de linha de base. A taxa de prioridade é o lance competitivo quando remetentes querem os mesmos slots escassos ou contas quentes.
Dinâmicas de queima importam para a intuição de suprimento mais do que lógica por transação. Clientes de envio precisam de simulação, estimativa de taxa sob carga, hashes de bloco frescos na retentativa, e não confundir preço de CU com uma gorjeta de MEV.
Gorjetas de MEV são um caminho de inclusão paralelo
Pesquisadores podem pagar gorjetas a validadores ou motores de bloco para inclusão e ordenação de pacotes. Esse pagamento pode usar programas e contas que nunca se parecem com uma taxa de prioridade do Compute Budget.
Caminho A: tx + preço da unidade de computação --> agendador do líder / banco
Caminho B: pacote + contas de gorjeta --> motor de bloco / leilão --> líderTaxas de prioridade são a alavanca padrão do mercado de taxas públicas. Pipelines de MEV importam quando você integra pesquisadores, protege usuários de fluxo tóxico, ou faz stake com validadores que compartilham gorjetas (incluindo alguns produtos LST). Veja Mercados de Taxas de Prioridade e MEV na Solana.
Governança liga parâmetros a política e programas
SIMDs (Documentos de Melhoria da Solana) propõem mudanças em nível de protocolo: parâmetros econômicos, recursos e política do cluster. Processos ponderados por stake e lançamentos de clientes determinam o que é ativado.
Realms é a pilha on-chain comum para DAOs e tesourarias: propostas, votação e execução para atualizações ou gastos. A governança de aplicativos não é política de inflação do cluster, mas ambas podem mover a economia do produto.
Prefira autoridades explícitas: autoridade de atualização de programa, tesourarias controladas por DAO, e contas de parâmetros que a governança pode mudar sem reescrever todas as suposições do cliente.
Como as peças interagem para um desenvolvedor
Um produto que usa SOL produtivamente frequentemente toca múltiplos loops:
- O usuário deposita SOL.
- O aplicativo cria/delega stake, emite um LST, ou roteia para um pool.
- Ao longo das épocas, as recompensas de inflação acumulam para o stake ativo (menos comissão / taxas do pool).
- As transações do usuário ainda pagam taxas base e de prioridade; algum valor é queimado.
- Sob mercados de MEV intensos, a inclusão pode depender de gorjetas ou roteamento de validador, não apenas do preço de CU.
- Um SIMD ou voto de DAO pode mudar taxas de recompensa, tratamento de taxas, ou programas que seu CPI assume.
O blueprint está completo quando você pode nomear em qual loop cada decisão de produto se encaixa.
Considerações Avançadas e Aplicações
Sistemas de produção misturam stake nativo, LSTs, lances de taxa e governança. Falhas vêm de misturá-los sem um modelo de propriedade claro.
| Caminho | O que você paga ou bloqueia | O que você obtém | Modo de falha para projetar |
|---|---|---|---|
| Stake nativo | SOL em contas de stake + custo de oportunidade | Recompensas do protocolo, escolha do validador | Cooldown, validador ruim, erros de autoridade |
| LST | SOL (ou liquidez LST) + taxas de protocolo | Recibo líquido + exposição a rendimento | Bug de contrato, desparidade, pausa / filas |
| Taxa de prioridade | Lamports extras via preço de CU | Maior chance de pousar sob carga | Pagar demais quando calmo; ainda cair se contas quentes |
| Gorjeta / pacote de MEV | Gorjeta para motor ou contas | Garantias de ordenação / inclusão | APIs diferentes, confiança no relé, griefing de gorjeta |
| Participação na governança | Peso de voto / lockups (varia) | Influência em parâmetros e tesouraria | Baixa participação, propostas ruins, atraso na atualização |
Tesourarias devem separar SOL operacional (taxas, aluguel, lances de CU) de stake estratégico ou LST e não assumir rendimento real fixo. Carteiras devem explicar diluição vs staking sem prometer APR. DeFi que aceita LSTs herda risco de oráculo e liquidez. Infra sente mercados de taxas como picos de carga muito antes da matemática de inflação.
Economia de validadores acopla comissão, desempenho de voto, política de compartilhamento de MEV e concentração de stake. Auto-delegadores devem documentar a escolha do validador e o tratamento de inadimplência.
Sensibilidade a parâmetros significa ler informações de inflação e época do cluster, tratar SIMDs como risco de produto, e versionar suposições da mesma forma que você fixa Agave e Anchor.
Para revisões de design: onde o SOL está, quem ganha emissão, quem paga taxas e gorjetas, qual caminho de saída existe, e qual processo de governança pode mudar essas respostas sem seu próximo deploy.
Equívocos Comuns
- "Taxa de inflação é meu APR de staking." A emissão é compartilhada entre o stake ativo e cortada por comissão e desempenho; participação e qualidade do validador dominam o rendimento realizado.
- "Staking é transferir SOL para o validador." Contas de stake permanecem sob autoridades de stake/saque que você controla; a delegação atribui peso de voto, não custódia de carteira quente.
- "Desfazer stake é instantâneo como uma transferência de token." A desativação é escalonada por época; mercados LST podem ser mais rápidos, mas não são a conclusão do cooldown nativo.
- "LSTs são SOL em stake sem risco." Eles adicionam risco de smart contract, operador, liquidez e frequentemente política de MEV além do risco de stake base.
- "Taxa de prioridade e gorjeta Jito são o mesmo campo." O preço de CU é um mercado de Compute Budget; gorjetas e pacotes usam pipelines de inclusão separados.
- "Taxas vão todas para validadores como renda pura." A política de taxas inclui componentes de queima e divisões em evolução; verifique as regras atuais antes de modelar a receita.
- "Governança é apenas para DAOs, não para a economia do protocolo." SIMDs e ativação de clientes podem mudar inflação, taxas e recursos que cada aplicativo herda.
- "Tokenomics é apenas para equipes de lançamento de tokens." Se você move SOL, pousa sob carga, integra LSTs, ou detém autoridade de atualização, você já está dentro deste blueprint.
FAQs
Qual é a ideia mais importante em tokenomics da Solana?
O SOL une segurança, inclusão e governança: a emissão paga o stake, taxas e gorjetas limpam o espaço de bloco, e a governança atualiza os parâmetros de ambos.
Quem recebe recompensas de inflação?
As recompensas fluem para o stake ativo vinculado a validadores performáticos, com comissão para o operador e o restante creditado aos delegadores por peso de stake e contabilidade de época.
Por que não-stakers se importam com a inflação?
Novo SOL aumenta o suprimento. Stakers recebem recompensas compensatórias; carteiras que detêm SOL ocioso não recebem, então elas experimentam diluição em relação ao capital em stake.
O que é uma conta de stake em uma frase?
É uma conta de propriedade de programa que bloqueia SOL, rastreia o estado do stake e pode ser delegada a uma conta de voto de validador sob autoridades explícitas de stake e saque.
Como as épocas afetam a UX de staking?
Os limites de ativação, desativação e recompensa são baseados em épocas, então os clientes devem mostrar o estado pendente e evitar prometer liquidez no mesmo slot para unstake nativo.
Quando um produto deve usar um LST em vez de stake nativo?
Use um LST quando os usuários precisam de uma reivindicação fungível e composável em DeFi sobre SOL em stake e aceitam risco de protocolo e liquidez; use stake nativo quando a escolha do validador, contas de stake diretas, ou superfície mínima de smart contract importam mais.
LSTs incluem automaticamente recompensas de MEV?
Somente se os validadores e pipelines do provedor LST capturarem e compartilharem esse valor por design. Rendimento aprimorado por MEV é política de produto, não uma propriedade de ser liquidamente em stake.
Qual é a diferença entre taxa base e taxa de prioridade?
A taxa base é o custo de assinatura e inclusão de linha de base; a taxa de prioridade é o lance de preço de unidade de computação que compete por execução escassa sob contenda.
Por que uma taxa de prioridade alta ainda pode falhar em pousar?
Líderes, bloqueios de conta, limites de CU, hashes de bloco expirados e demanda concorrente ainda podem descartar ou atrasar o trabalho; a taxa ajuda sob contenda, não é uma garantia.
Como o MEV é diferente do mercado de taxas de prioridade?
Taxas de prioridade são um leilão geral de preço de CU no caminho de taxas públicas; MEV frequentemente usa gorjetas e pacotes voltados para ordenação e inclusão especializada, às vezes através de pipelines laterais com líderes.
O que os desenvolvedores devem ler do RPC para economia?
Comece com getEpochInfo, APIs de taxa/cronograma de inflação, getVoteAccounts, getStakeActivation, getInflationReward, e endpoints de suprimento, depois adicione estado de pool ou LST.
O que é um SIMD?
Um Documento de Melhoria da Solana é uma proposta estruturada para mudança de protocolo ou cluster, transformando debates econômicos e técnicos em trabalho implementável no cliente.
Como Realms se relaciona com a inflação do protocolo?
Realms geralmente governa DAOs de aplicativos, tesourarias e autoridades de programa. A inflação do protocolo se move através de processos SIMD e de validador, não de todas as instâncias de Realms.
A governança pode mudar recompensas de stake depois que eu lanço?
Sim. Cronogramas de emissão e tratamento de taxas são controlados por parâmetros e recursos. Fixe suposições, monitore SIMDs e evite codificar constantes frágeis em promessas do usuário.
Qual é uma lista de verificação prática de tokenomics antes do lançamento?
Mapeie cada saldo de SOL (pagador de taxa, cofre, stake, LST), defina a UX de saída e cooldown, escolha a estratégia de taxas e gorjetas sob carga, documente o risco do validador ou LST, e nomeie quais autoridades podem mudar esses fluxos.
Relacionados
- Noções Básicas de Economia - taxas base, taxas de prioridade e para onde vão as taxas
- Inflação e Recompensas de Stake - cronograma de emissão e distribuição de recompensas
- Stake e Delegação - contas de stake, delegação, aquecimento e resfriamento
- Liquid Staking e LSTs - mSOL, jitoSOL, Sanctum e o espaço de design de LST
- Mercados de Taxas de Prioridade - mercados de taxas locais e dinâmicas de queima de taxas
- MEV na Solana - Jito, gorjetas e distribuição de MEV
- Governança e SIMDs - documentos de melhoria e mudança ponderada por validador
- Realms e Governança On-Chain - padrões de governança de DAO e tesouraria
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.