Recompensar la lealtad: Airdrop automático para todos los titulares
Por DeHub Team — 2021-07-03
Cuando se encontró una vulnerabilidad en el contrato v1, pausamos las interacciones con él, lo parcheamos y lo redesplegamos. La parte que importaba a los titulares era lo que sucedía a continuación: una instantánea de cada saldo antes de que el nuevo contrato entrara en vigor, y un lanzamiento automático 1:1 a cada uno de ellos.
Nadie tenía que reclamar. Nadie tenía que firmar nada. A nadie se le escapó una ventana.
Por qué automático, y por qué importa
La forma normal de manejar esto es una página de reclamaciones. Es mucho más barato, y es práctica estándar, y no lo hicimos —porque una página de reclamaciones transfiere silenciosamente el costo de tu error a las personas contra las que se hizo.
Los mecanismos de reclamación fallan por razones ordinarias. La gente está viajando. La gente se pierde el anuncio. Las personas han perdido el acceso al monedero que tenían guardado, o no entienden qué es una reclamación, o ven un enlace que les pide que conecten un monedero después de un incidente de seguridad y deciden correctamente no confiar en él. Cada uno de ellos produce un titular que no hizo nada malo y termina sin nada, y cada saldo no reclamado termina de nuevo con el proyecto.
El incidente fue nuestro. La remediación no debería haber tenido un requisito de participación.
Qué implica realmente lo automático
Es más trabajo, y vale la pena ser claro sobre cuál es el trabajo:
- La instantánea tiene que ser defendible. Un bloque, tomado antes de la implementación, publicado para que cualquiera pueda verificar su propio saldo.
- La distribución cuesta dinero real. Miles de transferencias individuales a tarifas de red, pagadas por el proyecto, sin compensar el resto no reclamado.
- Los casos Edge deben decidirse por adelantado y en público. Saldos mantenidos en grupos, en contratos, transferencia intermedia en el bloque de instantáneas: cada uno de ellos necesita una regla establecida, aplicado consistentemente, antes de que alguien pueda acusarte de elegir ganadores después del hecho.
El precedente que estableció
Esta es la primera vez que DeHub lanza desde el aire sus soportes, y desde entonces ha establecido el patrón para todo. Los airdrop han sido parte del modelo de utilidad desde el primer documento técnico en 2021, y los que siguieron, el airdrop de socio para el tenedor fan.site, y más tarde las distribuciones de Last Chad Standing, heredaron los mismos supuestos. Instantánea publicada, reglas establecidas por adelantado, soportes que no es necesario realizar para ser incluidos.
También estableció un estándar interno al que nos hemos apegado desde entonces: cuando rompemos algo, la corrección no se termina cuando se corrige el código. Se termina cuando las personas afectadas están enteras. Ese principio se probó mucho más en el cuarto trimestre de 2022, cuando un mal funcionamiento del activador de impuestos congeló el token y el grupo de liquidez y obligó a un relanzamiento completo de v2 con más de 25 000 titulares a migrar. El enfoque no cambió. Se acaba de poner considerablemente más caro.
La cosa que nadie tiene en cuenta
Hacerlo de esta manera en 2021 es la razón por la que la migración de 2022 funcionó.
A finales de 2022, estábamos pidiendo a 25 000 personas que realizaran una acción inusual con sus billeteras, inmediatamente después de un fallo que habíamos causado, en un entorno lleno de personas que se hacían pasar por nosotros y esperaban que alguien hiciera clic en el enlace equivocado. El único activo real que tuvimos en esa conversación fue un ejemplo previo de cómo nos comportamos cuando rompemos algo.
Manejar el primer incidente adecuadamente no era lo correcto en ese momento. Era el crédito que gastamos un año después, cuando lo necesitábamos y no podíamos haberlo ganado retroactivamente.