P12-L04 · P12 · P12-M01
Mapear fases de lançamento e condições de falha da migração
Pré-requisitos: P12-L03
Objetivos de aprendizagem
- Mapear fases de lançamento e condições de falha da migração
- Especificar fases de migração com verificações de invariantes, limites de reversão e estados de falha explícitos.
Por que importa
Um diagrama de migração pode sugerir liquidez garantida embora custódia, conversão de alocação ou criação do pool possam falhar. O mapa de fases deve expor essas dependências antes de uma ação real.
Explicação
Descreva uma sequência finita: rascunho de requisitos, alocação aceite, elegibilidade para migração, construção do pool e reconciliação posterior. Cada transição exige pré-requisitos, autoridade, provas e destino de falha. Uma etiqueta launchpad ou curva de ligação não estabelece fórmula do contrato, comportamento das reservas nem permissões de migração. Não pressuponha que atingir um limiar apresentado garante um pool negociável.
Mantenha invariantes através do limite proposto: identidade exata do ativo, unidades brutas compatíveis, contabilidade da oferta, custódia das reservas e controlos do destino. Migrar pode converter direitos ou mover saldos; a conceção deve indicar quem autoriza e como inspecionar o estado resultante. Se uma falha deixar fundos inacessíveis, indique-o explicitamente em vez de desenhar uma seta reversível que a implementação pode não suportar.
Todas as fases são hipotéticas. Não se financia reserva, assina carteira nem cria implementação ou pool. Uma conceção transparente continua conceção, não lançamento observado nem promessa de preço e liquidez.
Terminologia
Critério de transição: provas necessárias para passar entre estados.
Invariante: condição que deve permanecer verdadeira através de uma transição.
Estado de falha: resultado definido quando falham pré-requisitos ou execução.
Limite de reversão: o que não pode ser revertido automaticamente.
Exemplo histórico
ILLUSTRATIVE Cedar usa rascunho S0, elegibilidade S1 num limiar estipulado no papel, pool proposto S2 e reconciliado S3. S1→S2 exige identidade exata do token, contabilidade das reservas e revisão das permissões do destino. Se a criação falhar, F conserva obrigação documentada de custódia por resolver. Não existem saldos nem observações reais do limiar.
Especificações visuais
Especificação de curva de ligação/migração com estados hipotéticos S0–S3, setas condicionadas e via visível de falha F. Não desenhe curva real de preço inventada; anote fórmula e reservas como pressupostos não implementados.
Legenda: Conceção fictícia de migração condicional; nenhum pool nem reembolso garantido.
SPECIFICATION_ONLY — o visual renderizado não foi produzido nem revisto independentemente.
O que a evidência demonstra
A máquina fictícia de estados expõe pré-requisitos e ramo de falha. Permite rever o fluxo proposto sem o executar.
O que a evidência não demonstra
Não prova fórmula de launchpad implementada, migração bem-sucedida, reservas financiadas, reembolso automático, reversão executável nem disponibilidade futura do pool.
Erros comuns
Omitir reconciliação após criação; desenhar reembolsos garantidos sem mecanismo; equiparar limiar atingido e migração concluída; ocultar custódia durante a falha.
Exercício prático
Escreva transições S1→S2 e S2→S3. Adicione um ramo de falha e três invariantes. Reformule «migração automática e liquidez garantida».
Mostrar correção detalhada
S1→S2: a autoridade hipotética designada só avança após provas de identidade/reservas/controlos do destino; falha de criação leva a F com custódia por resolver divulgada. S2→S3: verificar identidade do pool resultante, saldos reais e controlos LP/retirada antes de aprovar reconciliação. Invariantes: ativo exato, unidades compatíveis e custódia das reservas com responsabilização. Afirmação revista: «A migração ilustrativa depende de critérios declarados; nenhuma execução, via de reembolso nem liquidez disponível está verificada». Reverter exige um mecanismo especificado separadamente e não se infere de uma seta.
Lista de verificação
- Nomear fases e controlos responsáveis.
- Associar provas de aceitação a cada transição.
- Mostrar custódia na falha e limites de reversão.
- Reconciliar identidade do destino e controlos de retirada.
Resumo
Um plano de migração só é inspecionável se condições de transição, invariantes e custódia na falha permanecerem visíveis.
Resumo
- Limiares não provam migração concluída.
- Ramos de falha devem preservar obrigações de custódia.
- Reverter é uma afirmação de implementação, não convenção do diagrama.
Próxima lição
P12-L05
Ferramentas
Utilize a ferramenta BlockAssay indicada apenas como contexto de leitura de evidências. Esta lição não cria resultados de ferramenta, sessões de conta nem direitos de acesso. Exercício offline; não assine, implemente, aprove nem financie nada.
Fontes e limites das afirmações
- POOL: Pools Uniswap v2 — Os tokens LP representam participação no pool; o mecanismo de retirada é distinto da motivação ou fraude. Limite: Apenas documentação do mecanismo; os valores ilustrativos originais são estipulados, não são observações. Os registos históricos têm proveniência congelada separadamente e lacunas de recolha explícitas.
- ERC20: Norma ERC-20 — Interface do token e semântica das autorizações; a norma não estabelece identidade do emissor nem permissões seguras. Limite: Apenas documentação do mecanismo; os valores ilustrativos originais são estipulados, não são observações. Os registos históricos têm proveniência congelada separadamente e lacunas de recolha explícitas.
Classificações de evidência
ILLUSTRATIVE — entradas offline inteiramente fictícias; nenhuma observação atual.
Data de observação
null — nenhuma observação real
Versão do conteúdo
1
Data de revisão
null
Estado de revisão
needs_review
Especificações visuais
P12-L04-V01
Mapear fases de lançamento e condições de falha da migração
Conceção fictícia de migração condicional; nenhum pool nem reembolso garantido.
Especificação de curva de ligação/migração com estados hipotéticos S0–S3, setas condicionadas e via visível de falha F. Não desenhe curva real de preço inventada; anote fórmula e reservas como pressupostos não implementados.
Especificação de curva de ligação/migração com estados hipotéticos S0–S3, setas condicionadas e via visível de falha F. Não desenhe curva real de preço inventada; anote fórmula e reservas como pressupostos não implementados.
A 390 px, empilhe observações, pressupostos, lacunas e conclusão; mantenha os IDs completos e um equivalente textual integral. As tabelas largas deslocam-se localmente.
A prosa pode seguir RTL; os IDs, quantidades e eixos temporais permanecem LTR. Preserve o sentido das dependências.
P12-L04-ILLUSTRATIVE-v1
Fontes e limites das afirmações
POOL · PRIMARY_DOCUMENTATION
Pools Uniswap v2
- Afirmação sustentada
- Os tokens LP representam participação no pool; o mecanismo de retirada é distinto da motivação ou fraude.
- Limite de verificação
- Apenas documentação do mecanismo; os valores ilustrativos originais são estipulados, não são observações. Os registos históricos têm proveniência congelada separadamente e lacunas de recolha explícitas.
- Data de verificação
- 2026-10-02
https://developers.uniswap.org/docs/protocols/v2/concepts/pools
ERC20 · PRIMARY_DOCUMENTATION
Norma ERC-20
- Afirmação sustentada
- Interface do token e semântica das autorizações; a norma não estabelece identidade do emissor nem permissões seguras.
- Limite de verificação
- Apenas documentação do mecanismo; os valores ilustrativos originais são estipulados, não são observações. Os registos históricos têm proveniência congelada separadamente e lacunas de recolha explícitas.
- Data de verificação
- 2026-10-02
https://eips.ethereum.org/EIPS/eip-20
Proveniência dos dados
id: P12-L04-ILLUSTRATIVE-v1
dataStatus: ILLUSTRATIVE
observedAt: null
source: Original offline scenario in realOrHistoricalExample
scope: Fictional stipulated labels and values. No wallet, deployment, transaction, token launch or production observation.