Ejecutar una solicitud de préstamo en una cadena típica puede requerir tres tokens separados: el activo nativo para el gas, un segundo para pagar al servicio de relay que obtiene los datos de crédito del prestatario, y un tercero para compensar a la red de keepers que activa la devolución de llamada una vez que esos datos regresan. Este ejemplo proviene de la documentación de ejecución asíncrona de Rialo, y describe el costo real de operación de algo que la mayoría llamaría una sola transacción. Tres activos que adquirir, mantener, monitorear y recargar. Tres saldos que gestionar. Tres puntos donde el flujo de trabajo se detiene si uno se agota en el momento equivocado. Este impuesto en múltiples tokens rara vez se menciona porque no es una tarifa de protocolo que alguien cobre. Es un costo emergente de externalizar capacidades a redes separadas que cada una necesitaba su propia economía para sobrevivir. Nadie lo diseñó. Se acumuló, una capa de middleware a la vez. En @RialoHQ, el mismo flujo funciona como una sola transacción asíncrona. Los validadores consultan la API externa mediante llamadas web nativas. La ejecución se pausa y reanuda sin que un keeper lo solicite. Un solo token, un solo saldo, una sola cosa que mantener financiada. Las discusiones sobre diseño de tokens suelen girar en torno a calendarios de oferta y curvas de distribución. La pregunta más útil es cuántos tokens diferentes debe tener un desarrollador antes de que su producto funcione en absoluto. Para la mayor parte de esta industria, la respuesta honesta ha sido tres, y nadie nunca incluyó ese número en una presentación comercial.
