Ciclo de vida de Token
Siga a criação de fornecimento fixo, emissão de curva e migração externa para entender permissões, propriedade de ativos e transições de estado em cada etapa.
BigShortProtocol-EVM divide o ciclo de vida de um Token em criação, negociação na curva, migração atómica, negociação externa e posições curtas. A oferta e a configuração de emissão são fixadas na criação; a última compra na curva cria simultaneamente a pool externa e inicializa o Short Engine, sem uma etapa habitual de «graduação» que as operações tenham de ativar manualmente.
1. Oferta fixa e distribuição inicial
Cada Token emite toda a sua oferta de uma só vez durante a construção; a quantidade da curva e a reserva de empréstimos são ativos destinados a utilizações diferentes.
| Componente | Quantidade de Token | Titular inicial | Utilização |
|---|---|---|---|
| Quantidade vendável na curva | 793,100,000 | Factory | Venda a compradores da curva; as vendas de volta repõem o saldo vendável |
| Reserva para migração externa | 206,900,000 | Factory | Incorporação de uma só vez no Pair principal ao concluir a curva |
| Reserva de empréstimos | 199,861,071 | Endereço pré-calculado do Short Engine independente | Capital em Token para posições curtas após a migração |
| Oferta total | 1,199,861,071 | As duas categorias de endereços de contratos acima | Emitida de uma só vez na criação |
A base da oferta da curva é:
A oferta total é:
O modelo de capitalização utiliza a base de oferta da curva de 1,000,000,000 Token, não a oferta total ERC-20 de 1,199,861,071. É uma convenção de avaliação do protocolo e não deve ser confundida com a capitalização em circulação nem com a avaliação da oferta total completa.
O criador não recebe automaticamente uma atribuição de Token por iniciar a criação. Se pretender possuir Token vendáveis, também tem de os adquirir através de operações. A reserva de empréstimos também não é emitida adicionalmente durante a migração: os Token já são transferidos para o endereço pré-calculado do Engine na criação, embora nesse momento o código do contrato Engine ainda não tenha sido implementado nesse endereço.
2. Configuração funcional fixada na criação
| Configuração | Restrição e significado |
|---|---|
Nome name | Não vazio, máximo 64 bytes |
Símbolo symbol | Não vazio, máximo 16 bytes |
Metadados uri | Máximo 512 bytes; podem estar vazios |
Criador creator | Endereço não nulo; pode diferir do remetente da transação |
Estes comprimentos são medidos em bytes UTF-8, não em caracteres chineses. O nome, o símbolo e outros dados intervêm no cálculo determinístico do endereço de implementação; diferentes remetentes e números de criação têm espaços de nomes de implementação diferentes.
Ordem de execução da criação
- Validar metadados, criador e configuração de taxas.
- Ler o Launch Profile predefinido atual e fixar as quatro versões: Token, curva, Engine e local de negociação.
- Calcular os endereços previstos do Token e do Short Engine independente.
- Implementar o Token e emitir de uma só vez a oferta da curva e a reserva de empréstimos. No modo com taxas, implementar também o Tax Processor exclusivo desse Token.
- Criar ou reutilizar o Pair Token/USDC designado, validar a sua identidade e código e associá-lo como
mainPair. - Definir a curva como
Bonding, registar reservas iniciais, metadados, taxas e registo de configuração, e emitir o evento de criação.
Cada Token conserva o seu próprio Launch Profile. Selecionar posteriormente outro Profile predefinido não muda automaticamente os Token existentes para uma nova curva ou um novo local de negociação. As permissões de atualização do proxy de Factory são um aspeto distinto deste mecanismo de registos de configuração; consulte o capítulo de permissões.
3. Máquina de estados e ações disponíveis para o utilizador
| Estado | Significado funcional | Ações habituais disponíveis |
|---|---|---|
None | Ainda não criado em Factory | Criar Token |
Bonding | Saldo vendável da curva superior a 0 | Comprar e vender na curva; transferências entre carteiras normais |
Complete | A última compra reduziu a zero o saldo vendável | Entra imediatamente em migração na mesma transação; não é uma fase de espera independente |
Migrating | Validação do Pair, aporte à pool e implementação do Engine na mesma transação | Não existe uma entrada de migração independente para utilizadores |
Migrated | A pool externa e o Engine estão prontos | Negociação externa, posições curtas e gestão de posições sujeitas a condições; as entradas da curva deixam de aceitar operações |
A transição de fases de uma transação normal bem-sucedida é:
None → Bonding → Complete → Migrating → Migrated
As três últimas fases podem aparecer durante a execução da mesma compra final. O novo estado em cadeia e os registos só são conservados se toda a transação tiver sucesso.
Único critério quantitativo de conclusão da curva
Sejam
Aqui
A condição de conclusão é
4. Limites de negociação durante a fase da curva
A curva apresenta cotações com as reservas virtuais registadas por Factory e liquida com reservas reais. As três entradas respondem a necessidades diferentes:
O comprador pode designar o destinatário dos Token, mas não o Pair principal. Os reembolsos são sempre enviados ao remetente da transação, não ao destinatário dos Token. Para vender, o titular tem de autorizar previamente Factory a gastar Token.
O Pair principal ainda não está aberto
- Os titulares normais podem transferir entre carteiras.
- Antes de abrir o mercado externo, as transferências de Token não nulas com
mainPairsão restringidas; Factory é a exceção de controlo reservada para a migração. - Não é possível enviar Token diretamente ao Pair através de uma compra na curva.
- O endereço do Pair pode existir antecipadamente, mas «Pair criado» não equivale a «mercado externo aberto».
Esta restrição aplica-se ao mainPair associado pelo protocolo e não deve ser promovida como um bloqueio global de todos os endereços de terceiros ou mercados criados por conta própria.
5. Atomicidade da compra final e da migração
A compra final é liquidada primeiro segundo as regras da curva e depois conclui, por ordem, o aporte à pool externa, a implementação e inicialização do Engine e a abertura do mercado externo. Se falhar qualquer passo obrigatório,toda a compra final é revertida Transferências de token, atualizações de curva-reserva, reembolsos e logs nesta transação são revertidos. As transações previamente concluídas não são afetadas.
A compra final exige mais recursos de execução do que uma compra normal; o cliente não deve reutilizar um gas limit fixo de compras normais. Os fundos de migração, o destino dos LP e o tratamento da precisão são detalhados em Migração e AMM externo.
6. Funções de cada módulo após a migração
| Módulo | Função após a migração |
|---|---|
| Token | Transferências ERC-20, reconhecimento de taxas de compra e venda com o Pair principal, ativação do processamento de taxas |
| Pair principal | Manter liquidez real Token/USDC e executar trocas de produto constante |
| Short Engine | Gerir o inventário independente de empréstimos desse Token, a margem, Funding, os fechos e as liquidações |
| Risk Oracle | Fornecer ao Engine restrições de risco ponderadas no tempo relacionadas com a capacidade |
| Factory | Conservar registos de emissão e migração, gerir configurações e aspetos relacionados com receitas do protocolo |
| Quoter | Fornecer cotações apenas de leitura e pré-visualizações de capacidade executável; não executar operações pelo utilizador |
A migração não incorpora a reserva de empréstimos no AMM nem distribui os LP iniciais ao criador ou ao comprador final. O preço de negociação depende das reservas reais do Pair após migrar, e as posições curtas têm de continuar a cumprir simultaneamente os requisitos de capacidade de risco, inventário de empréstimos e margem.