Para todos / Reparto de comisiones
Reparto de ingresos de las aplicaciones
Una aplicación que quiera el apoyo del ecosistema liquida una parte publicada de su propio ingreso protocolario, nunca el dinero de sus usuarios, a través de un enrutador público en cadena. Escrito para ser discutido y no admirado.
La idea
En la mayoría de las cadenas, la cadena gana solo sus comisiones, mientras los negocios construidos sobre ella se quedan con todo lo que ganan y cada uno lanza su propia moneda. La idea de Pickle es que un negocio que quiera el apoyo de la cadena paga una parte pequeña y publicada de sus propias ganancias hacia PKL, por una tubería pública que cualquiera puede vigilar. No el dinero de los clientes, solo la parte del negocio. Los negocios pequeños no pagan nada; los grandes pagan un poco más; nadie paga más del 18 por ciento de nada.
Una cadena de propósito general captura valor solo del gas. Los negocios construidos sobre ella, exchanges, mercados de préstamos, mercados, juegos, se quedan con todo su ingreso, y cada uno lanza su propio token para monetizar, lo que fragmenta la atención y la liquidez por todo el ecosistema en el que se asienta. Pickle invierte eso. Una aplicación que quiera el apoyo del ecosistema liquida una parte publicada de su ingreso protocolario a través de un enrutador en cadena, y esa parte alimenta el único activo del ecosistema. La afirmación no es que esto sea generoso; es que el ingreso de las aplicaciones en Pickle es verificable en cadena en lugar de estimado por terceros.
Cuatro componentes: un registro gobernado y con bloqueo temporal que anota el tramo de cada aplicación, su escala de tasas publicada, su adaptador de categoría, su fianza y su estado de suspensión; un enrutador que recibe el ingreso protocolario, separa la retención del builder de la parte del ecosistema y emite un evento de ingreso; una bóveda multiactivo que acumula y asigna la parte del ecosistema por época; y adaptadores de categoría que definen la base de ingreso por tipo de aplicación. Las tasas son una escala publicada por tramo y nunca se negocian por aplicación. Para un creador de mercado automatizado, la integración consiste en apuntar el receptor de comisiones del pool al enrutador.
Qué cuenta como ingreso protocolario, y qué nunca
El ingreso protocolario es el ingreso propio de la aplicación. Nunca es nada de lo siguiente, en ningún tramo, de forma permanente:
| Nunca en ninguna base de ingreso | Por qué |
|---|---|
| Comisiones de los proveedores de liquidez, intereses de los prestamistas | remuneración del capital |
| Regalías de los creadores | pago a los creadores |
| Recompensas de liquidadores; pagos a keepers, solvers, oráculos y relayers | remuneración de proveedores de servicios |
| Principal de los usuarios, ganancias y pérdidas de los traders, margen, pagos de funding, ingresos de los vendedores, colateral | dinero de la contraparte, no ingreso |
| Costes de infraestructura repercutidos | costes |
Una cadena que grava su propia liquidez no tiene liquidez que gravar. La aritmética detrás de la regla, más que el sentimiento: gravar la comisión total de un creador de mercado automatizado en lugar de su ingreso protocolario recortaría los rendimientos de los proveedores en aproximadamente un 40 a 48 por ciento, y el capital compara rendimientos entre cadenas en cuestión de días. Esta lista de exclusiones es uno de los parámetros que ningún voto simple de tokens puede cambiar.
Cómo funciona
| Componente | Responsabilidad |
|---|---|
| AppRegistry | tramo, escala de tasas publicada, adaptador de categoría, fianza, suspensióngobernado y con bloqueo temporal |
| FeeRouter | recibe el ingreso protocolario, separa la retención del builder de la parte del ecosistemaemite un evento público de ingreso por liquidación |
| RevenueVault | acumulación y asignación multiactivopor época |
| Adaptadores de categoría | definen la base de ingreso por categoríaexchange, perpetuos, préstamos, mercado, juego, nombres, suscripción, genérico |
Cada liquidación y asignación emite un evento público, así que cualquier panel de ingresos es una lectura sobre esos eventos y no una hoja de cálculo que alguien mantiene. La integración es deliberadamente pequeña: para un creador de mercado automatizado es una línea, apuntar el receptor de comisiones del pool al enrutador.
La escala
| Ingreso protocolario anual | Parte del ecosistema marginal |
|---|---|
| Primeros 100.000 $ | 0 %el builder conserva el 100 % |
| De 100.000 $ a 500.000 $ | 6 %el builder conserva el 94 % de esta banda |
| De 500.000 $ a 1.000.000 $ | 12 %el builder conserva el 88 % de esta banda |
| Por encima de 1.000.000 $ | 18 %el builder conserva el 82 % de esta banda, y al menos el 82 % a cualquier escala |
Los tramos son marginales y se aplican solo al ingreso que cae dentro de ellos. Las tasas con cliff se rechazaron deliberadamente: una tasa que saltara sobre toda la base en un umbral premiaría a una aplicación por mantener su ingreso declarado justo por debajo de uno. Parte del ecosistema acumulada en los bordes de los tramos: nada en 100.000 $, 4,8 por ciento en 500.000 $, y 8,4 por ciento en 1.000.000 $.
El builder conserva al menos el 82 por ciento a cualquier escala, y todo lo que queda por debajo de 100.000 $ está libre. Las tasas cambian solo por un voto gobernado y con bloqueo temporal sobre todo el tramo, nunca por aplicación, porque la negociación por aplicación es la forma en que los ecosistemas acaban capturados.
Tasas efectivas
| Ingreso protocolario anual | Tasa efectiva |
|---|---|
| 50.000 $ | 0 %todo el importe cae en el tramo gratuito; el builder lo conserva íntegro |
| 250.000 $ | 3,6 %9.000 $ de parte del ecosistema |
| 500.000 $ | 4,8 %24.000 $ de parte del ecosistema |
| 1.000.000 $ | 8,4 %84.000 $ de parte del ecosistema |
| 5.000.000 $ | 16,08 %804.000 $ de parte del ecosistema |
| 20.000.000 $ | 17,52 %3.504.000 $ de parte del ecosistema; todavía por debajo del tramo máximo del 18 % |
Como los tramos son marginales, la tasa efectiva está siempre por debajo de la tasa marginal máxima y se le acerca solo lentamente. Con veinte millones de dólares de ingreso anual es del 17,52 por ciento, todavía por debajo del tramo máximo del 18 por ciento, y nunca lo alcanza a ninguna escala.
Un ejemplo resuelto
Un exchange con diez millones de dólares de volumen diario y una comisión de swap del 0,30 por ciento, repartida 0,25 por ciento a los proveedores de liquidez y 0,05 por ciento al protocolo. La parte de los proveedores nunca se toca. El flujo diario, a la tasa marginal máxima:
30.000 $/dia de comisiones totales
|- 25.000 $ -> proveedores de liquidez, dentro del pool (nunca se toca)
`- 5.000 $ -> ingreso protocolario, a traves del FeeRouter
|- 4.100 $ -> la tesoreria de la aplicacion (82 %)
`- 900 $ -> parte del ecosistema:
540 $ recompra / 180 $ tesoreria
90 $ seguridad / 90 $ incentivosLa misma disciplina se aplica en todas las categorías. En una plataforma de perpetuos, las ganancias y pérdidas de los traders, el margen, los pagos de funding, la parte de la bóveda de liquidez y la recompensa del liquidador nunca están en la base, y la parte de liquidación del protocolo se mide como realmente transferida, nunca como una proporción supuesta. En un mercado de préstamos, los intereses de los prestamistas no son ingreso; solo lo son el devengo de reservas y la parte de liquidación del protocolo. En un mercado, los ingresos de los vendedores y la regalía del creador no son ingreso. Los niveles de comisión difieren entre categorías porque las aplicaciones fijan sus propias comisiones: Pickle define solo qué cuenta como ingreso protocolario por categoría, nunca lo que una aplicación puede cobrar.
Esa recompra reduce la oferta total de PKL. No es una reducción de la oferta en circulación durante los años de adquisición (vesting), y la página de recompra da la aritmética.
Lo que esto no hace cumplir
El cumplimiento es económico, no físico
El despliegue es sin permisos, y un impuesto a nivel del secuenciador se rechaza deliberadamente. En una EVM de propósito general, los patrones de transferencia que tal impuesto tendría que interceptar son indistinguibles de la liquidación por abstracción de cuentas, los pagos de un mercado y los retiros de una bóveda, y cambiar la semántica de los tokens para atraparlos invalidaría todas las auditorías de la cadena.
Lo que Pickle ofrece en su lugar es condicional: la verificación, las subvenciones, el apoyo a la liquidez, los incentivos y la visibilidad dependen todos de enrutar el ingreso. Un mecanismo de fianza y desafío pone precio a declarar de menos: una aplicación registrada deposita una fianza en PKL, y un desafío exitoso que muestre ingreso protocolario no enrutado la hace perder. Las plataformas propias hacen transparente la actividad principal porque sus propios libros están en cadena.
Una aplicación puede negarse a registrarse y conservarlo todo. Entonces renuncia al apoyo del ecosistema, y esa es toda la consecuencia. El ingreso basado en spread y el ingreso fuera de cadena siguen siendo indetectables. Esta capa hace que compartir ingresos con honestidad sea barato, verificable y recompensado; no hace imposible compartirlos con deshonestidad.
Tokens de aplicación
Las aplicaciones de cualquier tramo pueden lanzar su propio token y pueden distribuir la parte que retienen entre sus titulares. Pickle es agnóstico sobre lo que un builder hace con la parte del builder. La única regla es el orden de liquidación: la parte del ecosistema se liquida en el enrutador, sobre el ingreso protocolario bruto tal como lo define el adaptador de categoría, antes de que la tesorería de la aplicación reciba o distribuya nada. Nunca se calcula sobre un beneficio declarado por la aplicación después de sus propias distribuciones.
Y la marca de verificado significa ingreso verificado a través del enrutador, no token respaldado. Esa distinción se enuncia en el explorador además de aquí, porque es la que un lector tiene más probabilidades de confundir.