Partilha de receita das aplicações

A ideia

O que conta como receita protocolar, e o que nunca conta

A receita protocolar é a receita própria da aplicação. Ela nunca é nenhum dos itens a seguir, em nenhum nível, permanentemente:

Uma cadeia que tributa a própria liquidez não tem liquidez para tributar. A aritmética por trás da regra, e não o sentimento: tributar a taxa total de um formador de mercado automatizado em vez da sua receita protocolar cortaria os retornos dos provedores em cerca de 40 a 48 por cento, e o capital compara retornos entre cadeias em questão de dias. Esta lista de exclusões é um dos parâmetros que nenhum voto simples de tokens pode mudar.

Como funciona

Toda liquidação e toda alocação emite um evento público, então qualquer painel de receita é uma leitura desses eventos e não uma planilha que alguém mantém. A integração é deliberadamente pequena: para um formador de mercado automatizado é uma linha, apontar o destinatário das taxas do pool para o roteador.

A tabela

As faixas são marginais e se aplicam apenas à receita que cai dentro delas. Taxas em degrau foram rejeitadas deliberadamente: uma taxa que saltasse sobre toda a base num limiar recompensaria uma aplicação por manter a receita declarada logo abaixo dele. Parcela acumulada do ecossistema nas bordas das faixas: nada em US$ 100.000, 4,8 por cento em US$ 500.000, e 8,4 por cento em US$ 1.000.000.

Taxas efetivas

Como as faixas são marginais, a taxa efetiva está sempre abaixo da taxa marginal máxima e só se aproxima dela lentamente. Em vinte milhões de dólares de receita anual ela é de 17,52 por cento, ainda abaixo da faixa máxima de 18 por cento, e nunca a alcança em nenhuma escala.

Um exemplo numérico

Uma exchange com dez milhões de dólares de volume diário a uma taxa de swap de 0,30 por cento, dividida em 0,25 por cento para os provedores de liquidez e 0,05 por cento para o protocolo. A parte dos provedores nunca é tocada. O fluxo diário, à taxa marginal máxima:

US$ 30.000/dia de taxas totais
|- US$ 25.000  ->  provedores de liquidez, dentro do pool   (nunca tocado)
`-  US$ 5.000  ->  receita protocolar, pelo FeeRouter
        |- US$ 4.100  ->  a tesouraria da aplicacao  (82%)
        `-   US$ 900  ->  parcela do ecossistema:
                          US$ 540 recompra / US$ 180 tesouraria
                          US$ 90 seguranca / US$ 90 incentivos

A mesma disciplina se aplica em toda categoria. Numa plataforma de perpétuos, os ganhos e perdas dos traders, a margem, os pagamentos de funding, a parte do cofre de liquidez e o prêmio do liquidante nunca estão na base, e a parte do protocolo na liquidação forçada é medida tal como efetivamente transferida, nunca como uma proporção presumida. Num mercado de empréstimo, os juros dos fornecedores não são receita; apenas a acumulação de reserva e a parte do protocolo na liquidação forçada o são. Num marketplace, o produto das vendas e o royalty do criador não são receita. Os níveis de taxa diferem entre categorias porque as aplicações fixam as próprias taxas: a Pickle define apenas o que conta como receita protocolar por categoria, nunca o que uma aplicação pode cobrar.

Essa recompra reduz a oferta total de PKL. Não é uma redução da oferta em circulação durante os anos de aquisição (vesting), e a página da recompra dá a aritmética.

O que isto não impõe

O que a Pickle oferece em vez disso é condicional: verificação, subvenções, apoio à liquidez, incentivos e destaque dependem todos de rotear a receita. Um mecanismo de caução e contestação põe um preço na subdeclaração: uma aplicação registrada deposita uma caução em PKL, e uma contestação bem-sucedida que mostre receita protocolar não roteada a faz perder. As plataformas de primeira parte tornam a atividade principal transparente porque a sua própria contabilidade está on-chain.

Uma aplicação pode recusar o registro e ficar com tudo. Ela então renuncia ao apoio do ecossistema, e essa é toda a consequência. A receita por spread e a receita fora da cadeia permanecem indetectáveis. Esta camada torna a partilha honesta de receita barata, verificável e recompensada; ela não torna a partilha desonesta impossível.

Os tokens das aplicações

Aplicações de qualquer nível podem lançar o próprio token e distribuir a parte retida aos seus detentores. A Pickle é agnóstica quanto ao que um builder faz com a parte do builder. A única regra é a ordem de liquidação: a parcela do ecossistema é liquidada no roteador, sobre a receita protocolar bruta tal como definida pelo adaptador de categoria, antes que a tesouraria da aplicação receba ou distribua qualquer coisa. Ela nunca é calculada sobre um lucro declarado pela aplicação depois das suas próprias distribuições.

E a marca de verificado significa receita verificada pelo roteador, não token endossado. Essa distinção é enunciada no explorador assim como aqui, porque é a que um leitor tem mais probabilidade de confundir.