Asignación de oferta y vesting

Un gráfico de asignación puede sumar 100% mientras oculta control inmediato del equipo o un calendario de vesting que empieza antes de depositar fondos.

Especifique oferta bruta total, precisión decimal y denominador de asignación antes de mostrar porcentajes. Cada asignación necesita propósito, etiqueta de destinatario/autoridad, importe, disponibilidad inmediata y condiciones de liberación. No confunda calendario previsto con contrato desplegado que lo aplica. La documentación describe un mecanismo de vesting; el ejercicio define su propio calendario hipotético.

Para vesting lineal, indique inicio, duración, período inicial de bloqueo si existe, asignación total y cantidad ya liberada. Calcule el derecho adquirido por separado de lo actualmente reclamable: liberaciones previas reducen lo restante reclamable. Si llegan depósitos tras el inicio, la implementación puede hacer una parte inmediatamente liberable; declare esa dependencia en vez de suponer un nuevo bloqueo por depósito. También importan transferencia del beneficiario y vías administrativas.

Una declaración de asignación no verifica independientemente todas las carteras ni impide otra vía de emisión. El diseño de oferta total debe reconciliarse con pruebas reales de oferta/autoridad antes de afirmar algo sobre un activo real. Aquí importes y destinatarios siguen ficticios, sin despliegue ni financiación de contrato.

Denominador de asignación: total declarado utilizado para porcentajes.

Derecho adquirido: importe adquirido según el calendario estipulado.

Reclamable: adquirido menos lo ya liberado.

Vesting aplicado: calendario ejecutado por controles inspeccionables, no promesa escrita.

ILLUSTRATIVE oferta Cedar=1,000,000 equivalentes de unidades enteras: comunidad 500,000; tesorería 250,000; equipo 200,000; reserva de pruebas 50,000. Calendario del equipo lineal estipulado de24 meses desde mes 0, sin período inicial de bloqueo; en mes 6,20,000 ya se liberaron. Es un calendario en papel, no depósito en garantía real.

Distribución de titulares y cronología de desbloqueo: cuotas50/25/20/5; equipo mes 6 adquirido 50,000, liberado 20,000, reclamable 30,000, no adquirido 150,000. Etiquete cada cifra como ilustrativa y distinga calendario de aplicación.

Leyenda: Asignación ficticia y calendario en papel de desbloqueo; ningún activo depositado ni bloqueado.

SPECIFICATION_ONLY — el visual renderizado no se ha producido ni revisado de forma independiente.

Las asignaciones ficticias suman 1,000,000 y 100%. En mes 6 el derecho estipulado del equipo es50,000; lo reclamable es30,000 tras la liberación previa indicada.

No prueba fondos bloqueados, custodia real, independencia de beneficiarios, aplicación del límite ni ejecución futura. Un gráfico de asignación al100% no establece que100% de la oferta esté realmente controlada por esas etiquetas.

Mostrar adquirido como reclamable; omitir liberaciones previas; llamar bloqueo a una promesa en papel; ignorar depósitos tardíos o transferencia del beneficiario.

Calcule todos los porcentajes, derecho del equipo en mes 6 y saldo reclamable. Redacte una declaración que explique la diferencia entre este calendario y una implementación de vesting verificada.

• Reconciliar unidades y asignación total.
• Indicar inicio, duración, período inicial de bloqueo y liberaciones previas.
• Separar cantidades adquiridas, reclamables y no adquiridas.
• No etiquetar un calendario en papel como bloqueo aplicado.

La aritmética de asignación es reproducible con denominador y supuestos de liberación explícitos; la aplicación requiere registros separados.

• Adquirido no equivale a reclamable.
• Un calendario prometido no es un bloqueo observado.
• Pruebas de oferta y autoridad deben acompañar afirmaciones de asignación real.

P12-L03

Utilice la herramienta BlockAssay indicada solo como contexto de lectura de evidencia. Esta lección no crea ninguna salida de herramienta, sesión de cuenta ni derecho de acceso. Ejercicio sin conexión; no firme, despliegue, apruebe ni financie nada.

• ERC20: Estándar ERC-20 — Interfaz del token y semántica de autorizaciones; el estándar no establece identidad del emisor ni permisos seguros. Límite: Solo documentación del mecanismo; los valores ilustrativos originales están estipulados, no son observaciones. Los registros históricos tienen procedencia congelada por separado y lagunas de recopilación explícitas.
• VEST: OpenZeppelin Contracts 5.x — finanzas — Mecanismo VestingWallet; el calendario real y el control del beneficiario requieren pruebas específicas de implementación. Límite: Solo documentación del mecanismo; los valores ilustrativos originales están estipulados, no son observaciones. Los registros históricos tienen procedencia congelada por separado y lagunas de recopilación explícitas.

ILLUSTRATIVE — entradas sin conexión totalmente ficticias; ninguna observación actual.

null — ninguna observación real

1

null

needs_review