Esta es una versión traducida y adaptada del texto “Progressive Decentralization: A Playbook for Building Crypto Applications” publicado por Jesse Walden el 9 de enero de 2020 en el blog de Andreessen Horowitz.

Los fundadores de cripto tienen un gran desafío por delante. Además de construir un producto que la gente quiera, tienen que considerar cómo ese producto puede funcionar exitosamente de manera descentralizada. Es decir, como un protocolo donde una comunidad de usuarios tenga la propiedad y la operación.

Este es un desafío difícil, porque lo que se necesita para construir un producto exitoso al comienzo (liderazgo de producto, iteración rápida, una salida al mercado gestionada) se encuentra en conflicto con la propiedad en manos de la comunidad y el compliance regulatorio, que son objetivos clave en el largo plazo.

He tenido largas conversaciones con fundadores de proyectos de crippto buscando resolver esta tensión.

Como resultado de estas conversaciones, aquí propongo un proceso de tres pasos que puede servir como guía para una descentralización progresiva: un proceso en el que el equipo fundador va cediendo el control de la aplicación a lo largo de una serie de pasos.

Este proceso gradual permite al equipo desarrollar un camino hacia el compliance regulatorio, incluyendo la emisión de tokens que, con suerte, no encontrarán problemas regulatorios.

El proceso está principalmente concebido para startups que construyen aplicaciones en plataformas de smart contracts. Es menos útil para plataformas de computación de blockchain en sí mismas ya que, para ser útiles, estas necesitan una mayor descentralización desde el comienzo.

Dado que el marco regulatorio es aún incierto, las etapas finales de esta guía sólo intentan apuntar hacia soluciones potenciales más que identificar estrategias de éxito probado.

Cualquier aplicación exitosa que corra en sobre una plataforma de computación de blockchain tendrá los siguientes tres componentes:

1- Product/market fit.

2- Participación de la comunidad.

3- Suficiente descentralización (propiedad de la comunidad).

La necesidad de product/market fit es obvia. Sin un producto que la gente quiera, no hay usuarios ni negocio, y es imposible sostener una comunidad en el largo plazo.

La participación de la comunidad y el control descentralizado son menos aplicables a las startups tradicionales, pero son cruciales para las startups de cripto. ¿Por qué son tan importantes?

La respuesta es que la participación y el control por parte de la comunidad resultan en una reducción del riesgo de plataforma: el riesgo de que las reglas de una plataforma cambien contra la voluntad de sus usuarios.

Las aplicaciones de la Web 2.0 han demostrado los riesgos de este tipo de desalineamiento, por ejemplo, matando ecosistemas innovadores de apps construidos sobre sus APIs, u obteniendo beneficios a expensas de la privacidad o bienestar de sus usuarios.

En contraste, las redes propiedad de los usuarios tienen un modelo económico cooperativo que ayuda a asegurar que sus servicios se mantengan mejor alineados con los intereses de sus usuarios, incluso cuando escalan.

Otra razón importante para alcanzar un control descentralizado de la comunidad es el compliance regulatorio. Muchos tokens de cripto pueden considerarse activos financieros bajo el Howey Test, un marco regulatorio utilizado por la Comisión de Bolsa y Valores de Estados Unidos (SEC).

Administrar la distribución de activos financieros a una amplia comunidad de usuarios es desafiante y costoso para una startup (incluso Airbnb y Uber aún no saben bien cómo hacerlo). Pero el análisis de los comentarios y las acciones recientes de la SEC sugiere que, si el equipo es capaz de descentralizar suficientemente las operaciones y eliminar las asimetrías de información, un token podría convertirse de “activo financiero” en “no activo financiero”.

Una prueba clave para evaluar si una inversión podría ser considerada un activo financiero es si los inversores están confiando en los esfuerzos de otros con la expectativa de obtener beneficios.

Como escribió Scott Kupor, socio en Andreessen Horowitz:

“En la etapa previa al lanzamiento de la red, los tokens generalmente se caracterizan como activos financieros a la luz del elemento del Howey Test de ‘confiar en los esfuerzos de otros’. Sin embargo, después del lanzamiento (suponiendo que la red esté lo suficientemente descentralizada) la naturaleza del token puede cambiar de activo financiero a no-activo financiero, debiéndose al hecho de que el tenedor del token ya no depende de los esfuerzos de otros”.

Entonces, con estas razones para la descentralización en mente, veamos un marco para abordarla como un proceso con el objetivo de construir un producto sostenible, de cumplimiento regulatorio y controlado por la comunidad.

La primera etapa de la construcción de una aplicación de cripto tiene todos los elementos de una startup tradicional: un gran equipo, un desarrollo eficiente, buena ejecución y aprendizaje rápido. Durante esta etapa, lo único que importa es el product/market fit.

Para encontrarlo rápidamente, hay que evitar el diseño por comité (¡o comunidad!). El proceso de desarrollo de producto necesita opiniones fuertes por parte del equipo para testear hipótesis y actualizar rápidamente los supuestos. En la práctica, esto podría significar que el equipo tenga privilegios sobre los smart contracts incluyendo control sobre las actualizaciones, la posibilidad de fijar parámetros de manera unilateral o hasta de apagar la red.

En esta etapa, no debería haber ilusión de descentralización. El core team debe tomar las decisiones de producto que sean necesarias con el fin de alcanzar el product/market fit.

No es recomendable lanzar un token en esta fase ya que esto podría generar problemas de compliance regulatorio. Depender de los esfuerzos del equipo fundador es una forma en la que un token podría ser considerado un activo financiero bajo el Test de Howey. En esta etapa, esto podría ser una distracción respecto de la prioridad, que es el desarrollo de producto.

La idea de que el equipo fundador controle todos los aspectos de un proyecto podría ser mal vista por algunos miembros de la comunidad. Pero esto no debería ser una preocupación para los fundadores. Si los usuarios se quejan de tu alto grado de control, ¡esto es un excelente problema! Significa que a alguien le importa lo que estás construyendo.

Dicho esto, es importante comunicar claramente qué grado de control existe. Simular descentralización es una forma de socavar la confianza. La transparencia es una forma de construirla.

Tras los primeros signos de tracción temprana (una base de usuarios en crecimiento, un ecosistema de desarrolladores y efectos de red), es momento de empezar a destinar más tiempo a aumentar la armonía entre los usuarios pasivos, los contribuyentes activos y el equipo fundador.

Para empezar, los fundadores deberían invertir más tiempo en implementar mejores prácticas para dirigir el desarrollo de producto como un proyecto open source: buena documentación; desarrollo abierto; ofrecer recompensas, becas y otros incentivos para desarrollos hechos por terceros; contratar líderes de comunidad para ayudar a fomentar el desarrollo abierto e introducir herramientas de consenso en la toma de decisiones.

Como un primer paso, puede ser útil empezar a reducir los riesgos de plataforma a través de restricciones técnicas autoimpuestas.

Por ejemplo, en Compound v2.2, las actualizaciones toman efecto 48 horas después de realizadas, lo que da suficiente tiempo a los usuarios abandonar el protocolo, o revisar los cambios y expresar su disconformidad. Urbit implementó la práctica de “versiones de Kelvin” donde los números de versiones van bajando hasta 0, y una vez que se alcanza este punto, ya no se hacen más actualizaciones.

Para el equipo fundador, ceder el control implica empezar a transferir la responsabilidad a la comunidad. Pero a medida que vas involucrando a los miembros de la comunidad, es importante volver a revisar los incentivos. ¿Por qué los miembros de la comunidad irían a contribuir al producto de manera regular?

Los incentivos económicos son una manera de lograr contribuciones de la comunidad. Un modelo de negocio pragmático y familiar para los servicios de cripto es cobrar un “fee por call”, similar a un microservicio de API como Twilio o Stripe. Distribuir este flujo de comisiones entre los colaboradores activos puede alinear a la comunidad alrededor del éxito del proyecto.

Dicho esto, las comisiones no siempre tienen sentido al comienzo del proyecto. Dado que los servicios de cripto son de código abierto, cobrar comisiones sólo empieza a tener sentido cuando ya se alcanzaron fuertes efectos de red, y la plataforma ya alcanzó defensividad a través de switching costs (el costo que enfrentarían los usuarios de cambiarse a un competidor).

El exchange descentralizado Uniswap es un ejemplo de cómo una aplicación de cripto que cobra una comisión puede estar protegida de la competencia gracias a sus efectos de red.

En Uniswap, mientras más usuarios contribuyan con liquidez, mejor es el precio para los traders. Para ofrecer el mismo precio en un fork sin comisiones, tendrías que coordinar a todos los proveedores de liquidez y a los servicios de terceras partes integrados con el original a que se muevan al fork. Toda esta coordinación impone un elevado switching cost.

Aunque los costos de cambiarse de plataforma son más bajos en cripto ya que los datos son abiertos, estos todavía existen. En cripto, sin embargo, los protocolos deben mantenerse mínimamente extractivos (en otras palabras, cubrir los costos relevantes en lugar de buscar maximizar los beneficios) para incentivar las contribuciones de la comunidad.

Los tokens son un instrumento para distribuir efectivamente el valor de un proyecto, incluyendo un flujo de comisiones. Mientras que la distribución de tokens puede fomentar la participación y ayudar a construir defensividad, es importante evaluar cómo realizar una distribución que sea tanto justa como efectiva.

Muchas ICOs y airdrops terminaron creando comunidades sin involucramiento y atrajeron la atención de los reguladores. Las aplicaciones de cripto que ya alcanzaron el product/market fit tienen una oportunidad de hacerlo mejor ya que distribuyen los tokens a una comunidad que ya está activa.

Para empezar, el equipo puede testear la distribución con un pequeño grupo de miembros. Algunos equipos asignaron una parte de los tokens futuros a miembros de la comunidad que realizar una contribución en etapa temprana. Un sistema de distribución de tokens que recompense a los usuarios que hacen una contribución ayuda a reducir la dependencia de la comunidad respecto de los esfuerzos del equipo fundador.

Luego, es necesario planificar cómo se van a distribuir los tokens restantes de manera justa en proporción a las contribuciones pasadas y de manera efectiva como incentivo para una participación futura.

El diseño de la distribución debe considerar al equipo fundador que construyó el producto y a los usuarios que hacen que sea útil. Hacerlo bien es difícil, y el proceso siempre será específico a la aplicación en cuestión. Algunas preguntas para plantearse son las siguientes:

• ¿Qué porcentaje de los tokens debería asignarse al equipo inicial?

• ¿Cómo recompensar a los diferentes tipos de personas que realicen una contribución al producto, tanto en el pasado como en el futuro?

• ¿Cómo se va a recompensar el liderazgo tecnológico en el futuro?

Responder a estas preguntas requiere de una serie de workshops para entender las expectativas y el comportamiento de los miembros de la comunidad.

Si eres un fundador de cripto y estás listos para esta etapa, significa que has alcanzado el product/market fit, que has construido una comunidad robusta e identificado un modelo que brinda los incentivos correctos para operaciones sustentables.

Ahora llega la última escala en el viaje a la descentralización: una amplia distribución de tokens.

En la práctica, los equipos tendrán un “exit to the community” (salida a la comunidad) realizando un airdrop de tokens a usuarios y miembros de la comunidad identificados en el objetivo anterior. Esto podría hacerse con una llamada a un smart contract para crear y distribuir los tokens.

Idealmente, cuando esta función es llamada, ya ha ocurrido una serie de cosas:

• El equipo fundador cedió la propiedad de la aplicación (comisiones y control) y mitigó el riesgo de plataforma asegurándose de que el producto esté bajo el control y la operación de la comunidad.

• El token ya se convirtió en un “no activo financiero”, dado que el servicio ahora está lo suficientemente descentralizado - esto es, independiente de los esfuerzos de una única entidad que podría tener información asimétrica.

• La compañía es sustentable y retuvo una cantidad de tokens suficiente para beneficiarse de las comisiones y el crecimiento de la red.

• Los usuarios/dueños obtienen rendimientos crecientes de escala a medida que la economía cooperativa del servicio permite un mejor alineamiento y un valor creciente para sus usuarios.

El espíritu de este objetivo es marcar un momento específico en que un proyecto de cripto completa su viaje desde un equipo de producto tradicional a una red bajo la propiedad y el control de sus usuarios. (Realizar una distribución de tokens siempre requiere un análisis legal cuidadoso, y hay poco precedente de lo que estoy describiendo. Así que primero consulta a un abogado).

Muchos equipos quedan empantanados por abordar estos objetivos en el orden equivocado, “simulando” descentralización o intentando hacer todo al mismo tiempo.

Por ejemplo, los equipos que, en un primer momento, persiguen la propiedad de la comunidad (empezando con una amplia distribución de tokens) corren el riesgo de crear una comunidad de especuladores en lugar de verdaderos usuarios.

Sin un producto que funcione, la propiedad de la red no vale nada y los usuarios no se quedarán mucho tiempo. Muchos equipos que han tomado este camino no lograron alcanzar el product/market fit y, en consecuencia, tienen dificultades en alcanzar una participación significativa de la comunidad.

Otro riesgo es avanzar directo desde los primeros signos de product/market fit a descentralizar la propiedad en la comunidad (saltando la etapa 2 de participación de la comunidad).

Si se falla en formalizar una real participación de la comunidad, un resultado común es que el proyecto termine en un “teatro de descentralización”. Un síntoma de esto es tener una comunidad apática con una alta dependencia del equipo fundador. En esta situación, para construir confianza, puede ser mejor formalizar el control (por ejemplo, a través de la delegación). Esconderse bajo una simulación de descentralización puede ser una forma rápida de socavar la confianza.

Otra forma de quedarse empantanado es tratar de hacer las tres cosas a la vez. La falta de foco es la causa de muerte de la mayoría de las startups, y lo mismo vale para las aplicaciones de cripto. Cada uno de estos objetivos se solapa uno con otro y debe considerarse de manera holística, como parte de una idea mayor, pero la ejecución debe hacerse de manera secuencial y con prioridades, y no intentar todo al mismo tiempo.

Finalmente, vale la pena notar que, mientras das los pasos en orden, una vez que pasas a la propiedad en manos de la comunidad, estás en territorio inexplorado en términos de gobernanza de la aplicación.

Escalar de manera efectiva los procesos de toma de decisiones de la comunidad es desafiante, pero si las comunidades de Internet pueden lograr objetivos impresionantes como Wikipedia, soy optimista de que la experimentación y el “skin-in-the-game” (a través de la propiedad de la red) pueden conducir a una toma de decisiones cooperativas sin precedentes.

Hasta el momento, todavía no hemos visto una aplicación de cripto que ejecute cada uno de estos objetivos de manera secuencial. Pero los equipos más prometedores con los que hablé han estado haciendo su camino por esta guía.

A través de estas conversaciones, he llegado a creer que la descentralización progresiva ofrece a los equipos el camino más auspicioso para encontrar product/market fit, sustentabilidad financiera, una comunidad participativa y compliance regulatorio — en ese orden.

Gracias a Robert Leshner, Hayden Adams, Alexis Gouba, Dan Robinson, Ali Yahya, Denis Nazarov y Toby Shorin por conversaciones que me ayudaron a pensar en estas ideas.