Regras de curva do LaunchLab

Esta página foi traduzida automaticamente por IA. A versão em inglês é a fonte oficial.Ver versão em inglês →

Uma regra de curva é a resposta de uma plataforma para “quais lançamentos estou disposto a hospedar?”. GlobalConfig define o piso do protocolo — pelo menos 10M de supply, pelo menos 20% da supply vendida na curva, e assim por diante — e esses pisos são deliberadamente amplos para que todo tipo de plataforma se encaixe neles. Uma regra de curva é onde sua plataforma os estreita para a forma que seu produto realmente suporta.As regras vivem em sua própria conta PlatformCurveRule, uma por par (plataforma, GlobalConfig). Elas só podem estreitar o que a config já permite; uma regra nunca pode ampliar um limite do protocolo.

O modelo mental

Três níveis, de fora para dentro:

GlobalConfig       piso do protocolo      "supply >= 10M, taxa de venda >= 20%, ..."
  └─ PlatformCurveRule   sua regra     "e na minha plataforma: uma destas formas"
       └─ grupo de verificação    uma forma     "supply = 1B E arrecadação em [80, 90] SOL"
            └─ restrição uma verificação    "(Supply, Eq, 1_000_000_000)"

Os dois níveis de aninhamento são o que torna isso expressivo:

Restrições dentro de um grupo são ANDadas. Todas elas devem ser válidas.
Grupos dentro de uma regra são ORados. Um lançamento é permitido assim que satisfaz qualquer grupo único.

Então um grupo é uma forma permitida, e a regra é o menu de formas que você oferece. Uma regra comporta até 10 grupos, e um grupo até 25 restrições. Dois casos extremos valem a pena memorizar:

Estado	Significado
Nenhuma conta de regra, ou uma regra com zero grupos	A plataforma não restringe parâmetros de lançamento para essa config.
Um grupo com zero restrições	Esse grupo corresponde a todo lançamento, então a regra inteira permite tudo.

Uma regra entra em vigor apenas enquanto PlatformConfig.restrict_curve_param é 1. Em 0 o programa não lê regras, que é também o switch que você usa para desativar uma regra e para revertê-la.

Restrições

Uma restrição é uma tripla (campo, operador, valor). Nada mais — sem expressões, sem aninhamento.

pub struct ParamConstraint {
    pub field: u8,    // qual parâmetro de lançamento, veja a tabela abaixo
    pub op:    u8,    // 0 Eq, 1 Gte (mín), 2 Lte (máx), 3 Neq
    pub value: u128,
}

Um intervalo são duas restrições no mesmo campo dentro de um grupo: um Gte para o piso e um Lte para o teto. O mesmo par (campo, operador) não pode aparecer duas vezes em um grupo, o que impede que você escreva dois mínimos contraditórios.

Campos

Os ids de campo são permanentes. Novos campos são apenas adicionados, então um id nunca muda de significado uma vez que uma conta de regra o contém.

id	Campo	Unidade	Notas
0	`CurveType`	enum	0 produto constante, 1 preço fixo, 2 preço linear
1	`MigrateType`	enum	Novos lançamentos devem ser `1` (CPMM) de qualquer forma
2	`MigrateCpmmFeeOn`	enum	0 apenas quote, 1 ambos os tokens
3	`Supply`	unidades base	A supply total de tokens
4	`TotalSellA`	unidades base	Vendida na curva. Apenas configs de produto constante — veja Restrições de tipo de curva
5	`TotalFundRaisingB`	unidades quote	A meta de graduação
6	`TotalLockedAmount`	unidades base	Orçamento de vesting
7	`CliffPeriod`	segundos	Espera antes do desbloqueio começar
8	`UnlockPeriod`	segundos	Duração do desbloqueio
9	`BaseTokenProgram`	enum	0 SPL Token, 1 Token-2022
10	`TransferFeeEnabled`	bool	1 quando o mint base carrega `TransferFeeConfig`
11	`TransferFeeBasisPoints`	1/10 000	0 sem a extensão
12	`TransferFeeMaximumFee`	unidades base	0 sem a extensão
13	`SellRateA`	1/1 000 000	Derivado: `TotalSellA / Supply`. Apenas produto constante
14	`LockRate`	1/1 000 000	Derivado: `TotalLockedAmount / Supply`
15	`MigrateAmountA`	unidades base	Derivado: `Supply − TotalSellA − TotalLockedAmount`. Apenas produto constante
16	`MigrateRateA`	1/1 000 000	Derivado: `MigrateAmountA / Supply`. Apenas produto constante
17	`FundRaisingRateB`	1/1 000 000	Derivado: `TotalFundRaisingB / Supply`
18	`UnixTimestamp`	segundos	Tempo de bloco do lançamento

Os campos derivados são os que tornam as regras portáveis. Fixar Supply e TotalFundRaisingB em números exatos fixa uma forma de lançamento; restringir FundRaisingRateB fixa a relação entre eles e permite que um criador escolha qualquer supply que a mantenha.

Campos de taxa são apenas comparáveis dentro de uma GlobalConfig, porque seus denominadores dependem do mint quote dessa config e de seus decimais. Isso não é uma limitação na prática: uma regra é escopo de uma config por construção.

Os nove playbooks

Cada playbook abaixo é uma regra. Restrições são escritas como (campo, operador, valor).

1. Um tier padrão

A regra mais simples, e o comportamento exato que a lista branca de parâmetros de curva aposentada oferecia: uma forma, fixada.

Grupo	Restrições
0	`(Supply, Eq, 1_000_000_000e6)`, `(TotalSellA, Eq, 800_000_000e6)`, `(TotalFundRaisingB, Eq, 85e9)`

Qualquer lançamento que desvie em qualquer um dos três é rejeitado com CurveParamNotMatchPlatformRule.

2. Uma banda em vez de um número

A razão pela qual bandas existem: um criador escolhe uma meta de arrecadação com a qual você se sente confortável, sem você enumerar cada valor.

Grupo	Restrições
0	`(Supply, Eq, 1_000_000_000e6)`, `(TotalFundRaisingB, Gte, 50e9)`, `(TotalFundRaisingB, Lte, 200e9)`

Um grupo, quatro restrições, e o criador tem um corredor de 50–200 SOL. Sob a lista branca antiga isso precisava de uma entrada por valor permitido, e o cap de dez entradas tornava impossível.

3. Tiers lado a lado

Grupos são ORados, então cada tier é um grupo.

Grupo	Restrições	Tier
0	`(Supply, Eq, 1_000_000_000e6)`, `(TotalFundRaisingB, Eq, 85e9)`	Padrão
1	`(Supply, Eq, 100_000_000e6)`, `(TotalFundRaisingB, Eq, 30e9)`	Pequeno
2	`(Supply, Eq, 10_000_000_000e6)`, `(TotalFundRaisingB, Gte, 500e9)`	Whale

A ordem importa para computação, não para semântica: a avaliação para no primeiro grupo que corresponde, então coloque seu tier mais usado primeiro.

4. Uma banda de avaliação de graduação

FundRaisingRateB é TotalFundRaisingB / Supply em milionésimos. Restringi-lo limita o quão ricamente um token pode se graduar independentemente da supply que o criador escolheu.

Grupo	Restrições
0	`(FundRaisingRateB, Gte, 60_000)`, `(FundRaisingRateB, Lte, 120_000)`

Com uma supply de 1e12 e um mint quote de 9 decimais, 85e9 / 1e12 × 1e6 = 85_000 fica dentro dessa banda. Um criador que dobra a supply deve aproximadamente dobrar a meta para ficar nela — que é o ponto. Duas restrições substituem o que seria uma tabela de pares (supply, target).

5. Um piso de migração

MigrateRateA é a fração da supply que realmente chega ao pool CPMM na graduação: Supply − TotalSellA − TotalLockedAmount, sobre supply. É a profundidade do pool graduado, e é o único knob do protocolo sem equivalente no lado da plataforma antes das regras existirem.

Grupo	Restrições
0	`(MigrateRateA, Gte, 150_000)`

Pelo menos 15% da supply chega ao pool. Um criador não pode vender 95% na curva e deixar um livro raso para trás.

Se os parâmetros não somam — uma quantidade bloqueada maior do que o que resta após a venda da curva — o valor derivado não pode ser computado e a restrição falha fechada, então o lançamento é rejeitado em vez de silenciosamente permitido.

6. Vesting que você realmente impõe

GlobalConfig.max_lock_rate limita vesting de cima. Uma regra pode colocar um piso sob ele, e exigir um cliff real.

Grupo	Restrições
0	`(LockRate, Gte, 50_000)`, `(LockRate, Lte, 200_000)`, `(CliffPeriod, Gte, 2_592_000)`

Entre 5% e 20% da supply bloqueada, com pelo menos um cliff de 30 dias. Útil para uma plataforma cuja proposta é “sem lançamentos com desbloqueio instantâneo”.

7. Gating por tipo de token

BaseTokenProgram e TransferFeeEnabled são independentes, o que importa: um mint Token-2022 sem TransferFeeConfig relata TransferFeeEnabled = 0 assim como um mint SPL Token faz.

Intenção	Grupo	Restrições
Apenas SPL Token	0	`(BaseTokenProgram, Eq, 0)`
Apenas Token-2022	0	`(BaseTokenProgram, Eq, 1)`
Token-2022, sem taxa de transferência	0	`(BaseTokenProgram, Eq, 1)`, `(TransferFeeEnabled, Eq, 0)`
Sem taxa de transferência, qualquer programa	0	`(TransferFeeEnabled, Eq, 0)`

8. Um cap de taxa de transferência condicional

Não há operador “if”, e nenhum é necessário — dois grupos expressam a condição.

Grupo	Restrições	Lê-se como
0	`(TransferFeeEnabled, Eq, 0)`	Sem taxa de transferência: tudo bem
1	`(TransferFeeEnabled, Eq, 1)`, `(TransferFeeBasisPoints, Lte, 100)`, `(TransferFeeMaximumFee, Gte, 1_000)`	Com uma taxa: no máximo 1%, e uma taxa máxima que é realmente definida

Uma TransferFeeConfig de taxa zero não passa pelo grupo 0: a extensão está presente, então TransferFeeEnabled é 1 e apenas o grupo 1 pode aceitá-la. UnixTimestamp é o tempo de bloco do lançamento, então um grupo pode carregar sua própria janela de validade. Você escreve ambos os grupos hoje e a mudança acontece por conta própria.

Grupo	Restrições	Janela
0	`(UnixTimestamp, Lte, 1_767_225_600)`, `(TotalFundRaisingB, Gte, 30e9)`	Período de promo: mínimo 30 SOL
1	`(UnixTimestamp, Gte, 1_767_225_601)`, `(TotalFundRaisingB, Gte, 80e9)`	Depois: mínimo 80 SOL

Nenhuma transação é necessária no limite. O custo é dois slots de grupo em vez de um.

Restrições de tipo de curva

Quatro campos leem TotalSellA: TotalSellA, SellRateA, MigrateAmountA, e MigrateRateA. Em uma config de produto constante o criador fornece esse número. Em uma config de preço fixo ou preço linear a curva o deriva em vez disso, e o valor que o programa compara é 0, o que rejeitaria todo lançamento. Em vez de deixar você escrever uma regra que silenciosamente bloqueia sua própria config, o programa recusa esses quatro campos no tempo de escrita em uma config não-produto-constante, com CurveRuleFieldNotSupportedByCurve. Apenas configs de produto constante existem hoje, então na prática você não encontrará esse erro.

Verifique antes de enviar

Ambas as direções da verificação on-chain estão disponíveis off-chain, então nem um criador nem uma plataforma precisa aprender uma regra observando transações reverterem.

Banner de versão.

SDK: @raydium-io/raydium-sdk-v2@0.2.42-alpha é a versão que todo outro demo de código neste site é fixado. Os dois helpers abaixo chegam com a versão do SDK que envia suporte a regra de curva; até então, porte-os do platform_curve_rule.rs do programa ou chame o programa e leia o código de erro.
Cluster: teste no devnet do Solana primeiro — veja Teste no devnet primeiro.
ID do programa: veja reference/program-addresses

Ambos os helpers são funções puras. Eles não tocam RPC, então são seguros para executar em cada keystroke em um formulário.

Antes de um lançamento: esses parâmetros passarão?

checkLaunchAgainstCurveRule espelha a verificação de tempo de lançamento do programa exatamente, incluindo seu comportamento de falha fechada. Execute-o em seu formulário de lançamento e você pode desabilitar o botão de envio com um motivo em vez de deixar o criador pagar por uma transação revertida.

import {
  checkLaunchAgainstCurveRule,
  getPdaPlatformCurveRule,
  LaunchpadCurveRuleBaseTokenProgram,
  LaunchpadCurveRuleField,
  PlatformCurveRule,
} from "@raydium-io/raydium-sdk-v2";
import BN from "bn.js";

const platformConfig = await raydium.launchpad.getPlatformConfig(platformConfigId);

// em 0 o programa não lê regras, então não há nada para verificar
if (platformConfig.restrictCurveParam !== 0) {
  const ruleId = getPdaPlatformCurveRule(programId, platformConfigId, configId).publicKey;
  const ruleAccount = await connection.getAccountInfo(ruleId);

  const result = checkLaunchAgainstCurveRule({
    // undefined quando a conta não existe — a plataforma não escreveu regra para essa config
    rule: ruleAccount === null ? undefined : PlatformCurveRule.decode(ruleAccount.data),
    context: {
      curveType: globalConfig.curveType,
      migrateType: 1,
      migrateCpmmFeeOn: 0,
      supply: new BN("1000000000000000"),
      totalSellA: new BN("793100000000000"),
      totalFundRaisingB: new BN("85000000000"),
      totalLockedAmount: new BN(0),
      cliffPeriod: new BN(0),
      unlockPeriod: new BN(0),
      baseTokenProgram: LaunchpadCurveRuleBaseTokenProgram.SplToken,
      // omita transferFee inteiramente quando o mint base não carrega extensão de taxa de transferência
      unixTimestamp: new BN(Math.floor(Date.now() / 1000)),
    },
  });

  if (!result.ok) {
    // todo grupo rejeitou o lançamento; cada entrada lista todas as restrições falhando daquele grupo
    for (const group of result.groupFailures) {
      for (const c of group.unsatisfied) {
        console.log(
          `grupo ${group.groupId}: ${LaunchpadCurveRuleField[c.field]} é ${c.actual ?? "não computável"},`,
          `regra quer op ${c.op} ${c.value.toString()}`,
        );
      }
    }
  }
}

Três coisas que o helper reproduz em vez de aproximar:

Uma conta de regra ausente, e uma regra sem grupo, ambas passam. Assim como um grupo sem restrições. Passe rule: undefined para uma conta inexistente; não a trate como uma rejeição.
Valores não computáveis falham fechado. Uma supply zero não tem taxas, e uma quantidade bloqueada maior do que o que a venda da curva deixa não tem quantidade de migração. actual volta undefined e a restrição conta como insatisfeita, exatamente como on-chain.
Todas as restrições falhando são relatadas, não apenas a primeira. O programa faz short-circuit porque só precisa de um veredicto; o helper coleta tudo para que seu formulário possa listar cada problema de uma vez.

A única coisa que ele não pode saber é o tempo de bloco em que sua transação realmente chegará. Se uma regra usa UnixTimestamp perto de um limite, trate uma aprovação como provisória.

Antes de escrever uma regra: esse grupo é válido?

checkCurveRuleGroupWritable espelha a validação de tempo de escrita de UpdatePlatformCurveRule — ids de restrição, a regra de (campo, operador) duplicado, ambos os limites de contagem, e a restrição de tipo de curva. Execute-o em sua ferramenta de admin de plataforma antes de assinar.

import {
  checkCurveRuleGroupWritable,
  LaunchpadCurveRuleField,
  LaunchpadCurveRuleOp,
} from "@raydium-io/raydium-sdk-v2";

const constraints = [
  { field: LaunchpadCurveRuleField.Supply, op: LaunchpadCurveRuleOp.Eq, value: new BN("1000000000000000") },
  { field: LaunchpadCurveRuleField.TotalFundRaisingB, op: LaunchpadCurveRuleOp.Gte, value: new BN("50000000000") },
  { field: LaunchpadCurveRuleField.TotalFundRaisingB, op: LaunchpadCurveRuleOp.Lte, value: new BN("200000000000") },
];

const writable = checkCurveRuleGroupWritable({
  groupId: 0,
  constraints,
  curveType: globalConfig.curveType,
  // os ids que a regra já contém, então substituir um grupo não é confundido com adicionar um
  existingGroupIds: existingRule?.groups.map((g) => g.groupId) ?? [],
});

// cada erro carrega o código de erro do programa que a transação teria falhado com
if (!writable.ok) console.log(writable.errors);

Passar nessa verificação significa que a transação não será rejeitada por ser malformada. Isso não diz nada sobre se a regra é o que você quis — um grupo pode ser perfeitamente válido e ainda rejeitar todo lançamento que sua UI pode produzir. É para isso que a verificação do lado do lançamento acima serve: depois de escrever um grupo, execute cada forma que seu produto oferece através de checkLaunchAgainstCurveRule e confirme que cada uma ainda encontra um grupo.

Teste no devnet primeiro

Habilitar restrict_curve_param na mainnet muda o que seus criadores podem fazer, imediatamente, para todo lançamento. Ensaie a sequência inteira no devnet antes de tocar na mainnet:

Crie uma config de plataforma e uma regra no devnet, e escreva os mesmos grupos que você pretende enviar.
Execute cada forma de lançamento que sua UI pode produzir através de checkLaunchAgainstCurveRule, e confirme que os veredictos são os que você espera — tanto as formas que devem passar quanto as formas que devem ser rejeitadas.
Habilite restrict_curve_param, então realmente lance um token que deveria passar e um que deveria ser rejeitado. O segundo deveria falhar com CurveParamNotMatchPlatformRule (6025), não com NotEnoughRemainingAccounts (6018) — o último significa que seu builder não está adicionando o PDA de regra e a verificação não está sendo realmente exercida.
Apenas então repita na mainnet, na mesma ordem.

Aponte o SDK para devnet com cluster: "devnet" quando você o carrega, e pegue o ID do programa devnet de reference/program-addresses. O passo 3 é o que vale a pena insistir. O helper off-chain e o programa on-chain são duas implementações das mesmas regras, e um lançamento devnet é o que prova que eles concordam para sua regra — incluindo que seu builder de lançamento passa a conta.

Operando uma regra

O gerenciador delegado

Editar regras é trabalho rotineiro; uma chave de admin de plataforma é geralmente um multisig. PlatformConfig.curve_rule_manager existe exatamente para isso: defina-o uma vez através de UpdatePlatformConfig::CurveRuleManager, e essa carteira quente pode então criar, atualizar, remover e fechar contas de regra por conta própria. O admin de plataforma retém o mesmo poder em paralelo, então uma chave de gerenciador perdida é recuperável — rotacione-a com outra chamada de admin. Escopo de uma chave de gerenciador comprometida: ela pode afrouxar ou deletar suas regras de parâmetro, e pode reclamar o aluguel de uma conta de regra. Ela não pode tocar em carteiras de taxa, vesting, a config CPMM, não pode virar restrict_curve_param, e não pode quebrar um limite de GlobalConfig. Trate-a como uma chave de configuração, não uma chave de tesouro.

Aluguel segue o conteúdo

Uma conta de regra é criada sem grupo e redimensionada em cada mudança, então você paga pelas regras que realmente escreveu. Remover um grupo reembolsa a diferença para o signatário.

Conteúdo da regra	Tamanho da conta	Aluguel
Vazio (apenas criado)	150 bytes	~0.0019 SOL
1 grupo, 2 restrições	200 bytes	~0.0023 SOL
3 grupos, 4 restrições cada	408 bytes	~0.0037 SOL
10 grupos, 25 restrições cada	4 790 bytes	~0.034 SOL

Ordem de lançamento

Ensaie a sequência inteira no devnet — veja Teste no devnet primeiro.
Crie a conta de regra e escreva seus grupos. Nada muda ainda — com restrict_curve_param ainda em 0 o programa não as lê.
Verifique a regra off-chain com checkLaunchAgainstCurveRule: para cada forma de lançamento que sua UI pode produzir, confirme que algum grupo a aceita.
Defina restrict_curve_param para 1. A partir desse momento os lançamentos de seus criadores são verificados.
Para reverter, defina-o para 0 novamente. A conta de regra é deixada intacta.

Seu builder de lançamento deve adicionar o PDA de regra a remaining_accounts enquanto restrict_curve_param é 1. O programa requer que a conta esteja presente mesmo quando ela não existe ainda, para que um criador não possa pular a verificação omitindo-a — uma conta ausente é NotEnoughRemainingAccounts, não uma aprovação. A derivação é [b"platform_curve_rule", platform_config, global_config].

Custo no tempo de lançamento

A verificação executa em todo lançamento enquanto está habilitada, então seu custo de computação é um imposto por lançamento. Medido de ponta a ponta — derivação de PDA, a varredura de remaining_accounts, desserialização e avaliação:

Conteúdo da regra	Campos baratos	Campos derivados
Habilitado, sem conta de regra	1 936	—
1 grupo, 2 restrições	2 576	2 926
3 grupos, 4 restrições cada	3 624	5 724
10 grupos, 25 restrições cada	24 344	68 094

“Barato” é uma leitura de campo direto como Supply; “derivado” é um computado como MigrateRateA, que custa cerca de 223 CU por restrição contra cerca de 48. Mesmo uma regra totalmente carregada de restrições derivadas fica dentro de um terço do orçamento padrão de 200 000 CU por instrução, e uma regra realista de três grupos fica sob 6 000. Grupos são avaliados até um corresponder, então ordenar seu tier comum primeiro é economia gratuita.

Para onde ir a seguir

products/launchlab/platform-config — os campos de PlatformConfig que portão e delegam regras.
products/launchlab/global-config — os pisos do protocolo que uma regra estreita.
products/launchlab/instructions — as quatro instruções de regra e suas contas.
products/launchlab/accounts — PlatformCurveRule no inventário de contas.
sdk-api/typescript-sdk — a superfície do SDK onde os dois helpers de verificação vivem.
reference/changelog/2026-08-31-launchlab-platform-curve-rules — o que substituiu a lista branca de parâmetros de curva, e o que decodificadores devem mudar.

Fontes:

raydium-launch/programs/launchpad/src/states/platform_curve_rule.rs — PlatformCurveRule, CurveRuleGroup, ParamConstraint, os espaços de id de campo e operador, e CurveRuleContext::value_of.
raydium-launch/programs/launchpad/src/utils/platform_curve_rule.rs — a verificação de tempo de lançamento.
raydium-launch/programs/launchpad/src/instructions/platform/ — create, update, remove, e close_platform_curve_rule.

LaunchLab

Token launch flow

Tips & Gotchas

Regras de curva do LaunchLab

O modelo mental

Restrições

Campos

Os nove playbooks

1. Um tier padrão

2. Uma banda em vez de um número

3. Tiers lado a lado

4. Uma banda de avaliação de graduação

5. Um piso de migração

6. Vesting que você realmente impõe

7. Gating por tipo de token

8. Um cap de taxa de transferência condicional

Restrições de tipo de curva

Verifique antes de enviar

Antes de um lançamento: esses parâmetros passarão?

Antes de escrever uma regra: esse grupo é válido?

Teste no devnet primeiro

Operando uma regra

O gerenciador delegado

Aluguel segue o conteúdo

Ordem de lançamento

Custo no tempo de lançamento

Para onde ir a seguir

​O modelo mental

​Restrições

​Campos

​Os nove playbooks

​1. Um tier padrão

​2. Uma banda em vez de um número

​3. Tiers lado a lado

​4. Uma banda de avaliação de graduação

​5. Um piso de migração

​6. Vesting que você realmente impõe

​7. Gating por tipo de token

​8. Um cap de taxa de transferência condicional

​9. Uma promo com prazo, agendada antecipadamente

​Restrições de tipo de curva

​Verifique antes de enviar

​Antes de um lançamento: esses parâmetros passarão?

​Antes de escrever uma regra: esse grupo é válido?

​Teste no devnet primeiro

​Operando uma regra

​O gerenciador delegado

​Aluguel segue o conteúdo

​Ordem de lançamento

​Custo no tempo de lançamento

​Para onde ir a seguir

O modelo mental

Restrições

Campos

Os nove playbooks

1. Um tier padrão

2. Uma banda em vez de um número

3. Tiers lado a lado

4. Uma banda de avaliação de graduação

5. Um piso de migração

6. Vesting que você realmente impõe

7. Gating por tipo de token

8. Um cap de taxa de transferência condicional

9. Uma promo com prazo, agendada antecipadamente

Restrições de tipo de curva

Verifique antes de enviar

Antes de um lançamento: esses parâmetros passarão?

Antes de escrever uma regra: esse grupo é válido?

Teste no devnet primeiro

Operando uma regra

O gerenciador delegado

Aluguel segue o conteúdo

Ordem de lançamento

Custo no tempo de lançamento

Para onde ir a seguir