Allocazione dell’offerta e vesting

Un grafico a torta delle allocazioni può sommare al 100% nascondendo controllo immediato del team o un calendario di vesting che inizia prima del deposito dei fondi.

Specifica offerta totale in unità grezze, precisione decimale e denominatore dell’allocazione prima di mostrare percentuali. Ogni allocazione necessita di scopo, etichetta del destinatario/autorità, importo, disponibilità immediata e condizioni di rilascio. Non confondere un calendario pianificato con un contratto distribuito che lo imponga. La documentazione della fonte descrive un meccanismo di vesting; l’esercizio seguente definisce il proprio calendario ipotetico.

Per il vesting lineare, dichiara inizio, durata, eventuale cliff, allocazione totale e rilasci effettuati fino a oggi. Calcola separatamente diritto maturato e importo attualmente riscuotibile: i rilasci precedenti riducono ciò che rimane riscuotibile. Se i depositi possono arrivare dopo l’inizio del calendario, l’implementazione può rendere una parte immediatamente rilasciabile; dichiara tale dipendenza anziché presumere un nuovo blocco per ogni deposito. Contano anche trasferimento del beneficiario e percorsi amministrativi.

Una dichiarazione di allocazione non verifica indipendentemente tutti i wallet né impedisce un altro percorso di mint. Un progetto dell’offerta totale deve essere riconciliato con evidenze effettive di offerta/autorità prima di un’affermazione reale. Qui tutti gli importi e destinatari rimangono fittizi, senza distribuzione del contratto o finanziamento.

Denominatore dell’allocazione: totale dichiarato usato nei calcoli percentuali.

Diritto maturato: importo maturato secondo il calendario stipulato.

Riscuotibile: maturato meno già rilasciato.

Vesting imposto: calendario implementato da controlli ispezionabili, non promessa in prosa.

ILLUSTRATIVE offerta Cedar=1,000,000 equivalenti di unità intere: comunità 500,000; tesoreria 250,000; team 200,000; riserva di test 50,000. Il calendario del team è stipulato lineare su24 mesi dal mese 0, senza cliff; al mese 6,20,000 sono già stati rilasciati. È un calendario su carta, non una custodia vincolata reale.

Distribuzione dei detentori e cronologia degli sblocchi:50/25/20/5 quote di allocazione; team al mese 6 maturato 50,000, rilasciato 20,000, riscuotibile 30,000, non maturato 150,000. Etichetta ogni cifra come illustrativa e distingui calendario e imposizione.

Didascalia: Allocazione fittizia e calendario di sblocco su carta; nessun asset depositato o bloccato.

SPECIFICATION_ONLY — la visualizzazione non è stata prodotta né sottoposta a revisione indipendente.

Le allocazioni fittizie sommano a 1,000,000 e 100%. Al mese 6 il diritto stipulato del team è50,000; l’importo riscuotibile è30,000 dopo il rilascio precedente dichiarato.

Non prova fondi bloccati, custodia reale, indipendenza dei beneficiari, imposizione del limite o esecuzione futura. Un grafico di allocazione del100% non può stabilire che100% dell’offerta sia effettivamente controllato da queste etichette.

Mostrare il maturato come riscuotibile; omettere rilasci precedenti; chiamare blocco una promessa su carta; ignorare comportamento dei depositi tardivi o trasferimento del beneficiario.

Calcola tutte le percentuali, diritto del team al mese 6 e saldo riscuotibile. Scrivi una dichiarazione che spieghi la differenza tra questo calendario e un’implementazione verificata di vesting.

• Riconcilia unità e allocazione totale.
• Dichiara inizio, durata, cliff e rilasci precedenti.
• Separa importi maturati, riscuotibili e non maturati.
• Non etichettare un calendario su carta come blocco imposto.

L’aritmetica dell’allocazione è riproducibile quando denominatore e ipotesi di rilascio rimangono espliciti; l’imposizione richiede dati separati.

• Maturato non equivale a riscuotibile.
• Una promessa di calendario non è un blocco osservato.
• Evidenze di offerta e autorità devono accompagnare affermazioni reali sull’allocazione.

P12-L03

Usa lo strumento BlockAssay indicato soltanto come contesto per leggere le evidenze. Questa lezione non crea output dello strumento, sessioni di account o diritti di accesso. Esercizio offline; non firmare, distribuire, approvare o finanziare nulla.

• ERC20: Standard ERC-20 — Interfaccia dei token e semantica delle autorizzazioni di spesa; lo standard non stabilisce identità dell’emittente o sicurezza dei permessi. Limite: Soltanto documentazione del meccanismo; i valori illustrativi originali sono stipulati, non osservazioni. I dati storici hanno provenienza congelata separatamente e lacune esplicite nella raccolta.
• VEST: OpenZeppelin Contracts 5.x — finanza — Meccanismo VestingWallet; calendario effettivo e controllo del beneficiario richiedono evidenze dell’implementazione specifica. Limite: Soltanto documentazione del meccanismo; i valori illustrativi originali sono stipulati, non osservazioni. I dati storici hanno provenienza congelata separatamente e lacune esplicite nella raccolta.

ILLUSTRATIVE — input offline interamente fittizi; nessuna osservazione attuale.

null — nessuna osservazione reale

1

null

needs_review