Für Infrastruktur-Token - die einem Layer 1-Netzwerk entsprechen (oder einem angrenzenden Teil des Rechenstapels wie Layer 2) - sind die Wirtschaftsmodelle gut entwickelt und verstanden, verwurzelt im Angebot und der Nachfrage nach Blockraum. Aber für Anwendungstoken - Smart Contract-Protokolle, die Dienste auf Blockchains bereitstellen und Rechte in "vertieften Unternehmen" übertragen - werden Wirtschaftsmodelle noch immer gelöst.

App-Token-Geschäftsmodelle sollten genauso ausdrucksstark sein wie ihre zugrunde liegende Software. Zu diesem Zweck führen wir Cashflows für App-Token ein - ein Ansatz, der es Anwendungen ermöglicht, großzügige, flexible Modelle zu erstellen und Benutzern die Möglichkeit gibt, auszuwählen, wie sie für den von ihnen bereitgestellten Wert belohnt werden. Diese Methode schafft Gebühren aus legitimen Aktivitäten, die den regulatorischen Anforderungen verschiedener Gerichtsbarkeiten entsprechen, und fördert eine größere Einhaltung. Sie maximiert auch den Wert, der dem Protokoll zukommt, und ermutigt zu Governance-Minimierung.

Die Prinzipien, die wir hier teilen, gelten für alle Web3-Anwendungen — von DeFi bis hin zu dezentralen sozialen Apps, DePIN-Netzwerken und überall dazwischen.

Herausforderungen für Token-Modelle

Infrastruktur-Token unterliegen eingebettetem Angebot und Nachfrage: Wenn die Nachfrage steigt, nimmt das Angebot ab und die Märkte passen sich entsprechend an. Diese natürliche wirtschaftliche Grundlage für viele Infrastruktur-Token wurde durch den Ethereum Improvement Proposal 1559 beschleunigt (EIP-1559), die eine Grundgebühr für alle Ethereum-Transaktionen eingeführt hat, die verbrannt werden soll. Aber trotz vereinzelter Versuche mit Buy-and-Burn-Modellen gibt es für Anwendungstoken keine Parallele zu EIP-1559.

Anwendungen sind Benutzer, nicht Anbieter, von Blockraum, daher können sie sich nicht auf die Erhebung von Gasgebühren von anderen verlassen, die ihren Blockraum nutzen. Deshalb müssen sie ihre eigenen Wirtschaftsmodelle entwickeln.

Hier gibt es auch einige rechtliche Herausforderungen: Die wirtschaftlichen Modelle für Infrastruktur-Token sind stärker vor rechtlichen Risiken geschützt, aufgrund der generischen Natur typischer Blockchain-Transaktionen und der programmierten Mechanismen, die sie verwenden. Doch bei den wirtschaftlichen Modellen für Anwendungstoken könnten die beteiligten Anwendungen von der Erleichterung regulierter Aktivitäten abhängen und eine Vermittlung durch Governance-Token-Inhaber erfordern – was die Wirtschaftsmodelle komplizierter macht. Eine dezentralisierte Börse, die den Handel mit Derivaten ermöglicht, einer stark regulierten Aktivität in den USA, ist radikal anders als beispielsweise Ethereum.

Die Kombination dieser intrinsischen und extrinsischen Herausforderungen bedeutet, dass Anwendungstoken ein anderes wirtschaftliches Modell erfordern. In diesem Sinne präsentieren wir eine mögliche Lösung: eine Methode zur Gestaltung von Protokollen, die App-Token-Inhaber für ihre Dienste entschädigen und gleichzeitig den Protokollerlös maximieren, die regulatorische Compliance fördern und ...Governance-MinimierungUnser Ziel ist einfach: Anwendungstoken die gleiche wirtschaftliche Grundlage zu geben, durch Cashflows, die viele Infrastruktur-Token bereits haben.

Unsere Lösung konzentriert sich auf die Lösung von drei Problemen, mit denen Anwendungstoken in Bezug auf stehen:

1. Herausforderungen bei der Governance
2. Herausforderungen bei der Werteverteilung
3. Herausforderungen bei regulierten Aktivitäten

1. Herausforderungen bei der Governance

Anwendungstoken haben in der Regel Governance-Rechte, und das Vorhandensein einer dezentralisierten autonomen Organisation (DAO) kann dazu führen, dassUnsicherheitdass Infrastruktur-Token nicht haben. Für DAOs mit erheblichen Geschäftstätigkeiten in den USA können Risiken entstehen, wenn das DAO die Kontrolle über die Protokolleinnahmen hat oder die wirtschaftliche Aktivität des Protokolls vermittelt und eine solche Aktivität programmatisch gestaltet. Um diese Risiken zu vermeiden, können Projekte die Kontrolle eines DAO minimieren, indem sie die Governance minimieren. Für DAOs, wo dies nicht möglich ist, bietet das neue Gesetz von Wyoming...Dezentraler nicht eingetragener gemeinnütziger Verein (DUNA)bieteteinedezentrale Rechtseinheit, die dazu beitragen kann, diese Risiken zu mindern und geltende Steuergesetze einzuhalten.

2. Herausforderungen bei der Werteverteilung

Anwendungen müssen auch Vorsicht walten lassen bei der Gestaltung des Mechanismus, der den Wert an Tokeninhaber verteilt. Kombination von Abstimmungs- und Wirtschaftsrechtekönnte Bedenken nach US-Wertpapiergesetzen hervorrufen, insbesondere bei einfachen und direkten Mechanismen wie pro-rata-Verteilungen und Token-Käufen und -Verbrennungen. Diese Mechanismen ähneln Dividenden und Aktienrückkäufen und können die Argumentation untergraben, dass Tokens einen anderen regulatorischen Rahmen als Eigenkapital verdienen.

Projekte sollten stattdessen den stakeholder-Kapitalismus erforschen und Tokeninhaber für ihre Beiträge zum Projekt auf eine Weise belohnen, die dem Projekt zugute kommt. Viele Projekte haben eine positive Beteiligung gefördert, einschließlich des Betriebs eines Frontends (Likör), Teilnahme am Protokoll (Stieglitz), und als Teil eines Sicherheitsmoduls Sicherheiten zu hinterlegen (Aave). Der Gestaltungsspielraum hier ist weit offen, aber ein guter Ausgangspunkt ist die Kartierung aller Interessengruppen in einem Projekt, die Bestimmung, welche Verhaltensweisen von jedem von ihnen gefördert werden sollten, und die Entscheidung, welchen übergreifenden Wert das Protokoll durch diese Anreize schaffen kann.

Aus Gründen der Einfachheit gehen wir in diesem Beitrag davon aus, dass ein einfaches Entschädigungsmodell angenommen wird, das Tokeninhaber für ihre Beteiligung an der Governance belohnt, obwohl andere Modelle existieren.

3. Herausforderungen bei regulierten Aktivitäten

Anwendungen, die regulierte Aktivitäten erleichtern, müssen auch vorsichtig sein, wenn sie Mechanismen zur Wertsteigerung für Tokeninhaber entwerfen. Wenn solche Mechanismen Wertsteigerung aus Frontends oder APIs generieren, die nicht in Übereinstimmung mit geltendem Recht betrieben werden, könnten Tokeninhaber von illegalen Aktivitäten profitieren.

Die meisten vorgeschlagenen Lösungen für dieses Problem konzentrieren sich darauf, den Wertzuwachs auf Aktivitäten zu begrenzen, die in den USA zulässig sind - zum Beispiel nur Protokollgebühren für Liquiditätspools, die bestimmte Vermögenswerte betreffen, einzuschalten. Dadurch werden Projekte auf den niedrigsten gemeinsamen Nenner der regulatorischen Ansätze reduziert und der Mehrwert globaler autonomer Softwareprotokolle untergraben. Es untergräbt auch direkt die Bemühungen zur Minimierung der Governance. Die Bestimmung der geeigneten Gebührenstrategie aus Sicht der regulatorischen Konformität ist keine angemessene Aufgabe für DAOs.

In einer idealen Welt könnten Projekte Gebühren aus Aktivitäten in jeder Gerichtsbarkeit erheben, in der solche Aktivitäten zulässig sind, ohne sich auf DAOs verlassen zu müssen, um zu bestimmen, was zulässig ist. Die Lösungbesteht nicht darin, auf Protokollebene regulatorische Konformität zu verlangen, sondern sicherzustellen, dass protokollgenerierte Gebühren nur weitergegeben werden, wenn die Frontend- oder API, die sie generiert hat, den geltenden Gesetzen und Vorschriften des Standorts des Frontends entspricht. Wenn es den USA untersagt wäre, Gebühren für einen bestimmten Transaktionstyp zu erheben, die von einer Anwendung erleichtert wurden, könnte dies dazu führen, dass der wirtschaftliche Wert des Tokens dieser App auf null sinkt, auch wenn die Aktivität in jedem anderen Land der Welt völlig zulässig wäre. Flexibilität bei der Gebührenakkumulation und -verteilung bedeutet letztendlich Widerstandsfähigkeit angesichts regulatorischer Drucke.

Ein zentrales Problem: Verfolgung von Gebühren

Die Rückverfolgbarkeit von Gebühren ist entscheidend, um die potenziellen Risiken durch nicht konforme Frontends ohne Einführung eines Zensurrisikos oder einer Berechtigung des Protokolls zu lösen. Mit Rückverfolgbarkeit könnte eine Anwendung sicherstellen, dass alle Gebühren, die an Tokeninhaber anfallen, nur von Frontends stammen, die in der Gerichtsbarkeit des Tokeninhabers rechtlich konform sind. Wenn Gebühren nicht rückverfolgbar sind, gäbe es keine Möglichkeit, Tokeninhaber vor der Wertsteigerung durch nicht konforme Frontends (d.h. Gebühren, die von nicht konformen Frontends erhoben werden) zu schützen, was Tokeninhaber einem Risiko aussetzen könnte.

Um Gebühren nachverfolgbar zu machen, könnte ein Protokoll ein Zweischritt-App-Token-Staking-Systemdesign verwenden.

Schritt 1: Identifizierung, welches Frontend die Gebühren verursacht hat, und

Schritt 2: Routing der Gebühren zu verschiedenen Pools basierend auf benutzerdefinierter Logik.

Mapping-Frontends

Die Rückverfolgbarkeit von Gebühren erfordert eine Eins-zu-Eins-Zuordnung von einer Domain zu einem öffentlichen/privaten Schlüsselpaar. Ohne diese Zuordnung könnte ein böswilliges Frontend Transaktionen fälschen und so tun, als wären sie von einer ehrlichen Domäne übermittelt worden. Kryptografie ermöglicht es uns, Frontends zu "registrieren", indem wir die Domain unveränderlich aufzeichnen und mit dem öffentlichen Schlüssel verknüpfen, beweisen, dass die Domain diesen öffentlichen Schlüssel tatsächlich kontrolliert, und Transaktionen mit diesem privaten Schlüssel signieren. Dies gibt uns die Möglichkeit, Transaktionen und damit Gebühren einer bestimmten Domain zuzuordnen.

Routing-Gebühren

Sobald die Quelle der Gebühren nachverfolgbar ist, kann das Protokoll bestimmen, wie diese Gebühren auf eine Weise verteilt werden, die Tokeninhaber vor dem Empfang von Gebühren aus illegalen Transaktionen schützt, gleichzeitig aber auch die dezentralisierte Verwaltungsbelastung des DAO nicht erhöht. Um diesen Punkt zu veranschaulichen, denken Sie an das Spektrum möglicher Designs für das Staking von App-Token, von einem Staking-Pool für jede Frontend-Plattform bis hin zu einem Staking-Pool für alle Frontend-Plattformen.

In seinem einfachsten Aufbau könnten die Gebühren jedes Frontends an ein separates frontend-spezifisches Staking-Modul geroutet werden. Durch die Auswahl der Frontends, an die gestakt werden soll, könnte ein Tokeninhaber entscheiden, welche Gebühren er erhält und Gebühren vermeiden, die den Tokeninhaber in rechtliche Schwierigkeiten bringen. Ein Tokeninhaber könnte beispielsweise nur an das Modul staken, das mit einem Frontend verbunden ist, das alle regulatorischen Genehmigungen in Europa erhalten hat. Obwohl dieses Design einfach klingt, ist es tatsächlich ziemlich kompliziert. Es könnte 50 Staking-Pools für 50 verschiedene Frontends geben und die Verwässerung der Gebühren könnte sich negativ auf den Tokenwert auswirken.

Auf der anderen Seite könnten die Gebühren von jedem Front-End zusammengelegt werden - aber dies widerspricht dem Zweck der Gebührennachverfolgung. Wenn alle Gebühren zusammengelegt werden, gibt es keine Möglichkeit, Gebühren von konformen Frontends von nicht konformen zu unterscheiden - ein faules Ei würde das Fass verderben. Tokeninhaber würden gezwungen sein, zwischen dem Nichterhalt von Gebühren oder Anteilen an einem Pool zu wählen, in dem sie von illegalen Aktivitäten nicht konformer Frontends in ihrer Gerichtsbarkeit profitieren würden - eine Option, die viele Tokeninhaber davon abhalten könnte, teilzunehmen oder das System auf aktuelle suboptimale Entwürfe zurückzuführen, bei denen eine DAO beurteilen muss, wo Gebühren angewendet werden können.

Die Nachvollziehbarkeit von Adressierungsgebühren durch Kuratierung

Diese Komplexitäten könnten durch Kuratierung gelöst werden. Betrachten Sie eine Erlaubnisloses Smart-Vertragsprotokoll-Anwendung, die eine Gebühr und einen Token hat. Jeder kann eine Benutzeroberfläche für die Anwendung erstellen, und jede Benutzeroberfläche kann ihr eigenes Staking-Modul haben. Nennen wir eine Benutzeroberfläche für diese Protokoll-App.xyz.

App.xyz könnte spezifische Compliance-Regeln für die Gerichtsbarkeit, in der es sich befindet, befolgen. Anwendungsaktivitäten, die von app.xyz ausgehen, generieren Protokollgebühren. App.xyz verfügt über ein eigenes Staking-Modul, und Tokeninhaber können ihre Token entweder direkt an dieses Modul oder an einen Kurator staken, der individuell einen Korb von Frontends auswählen kann, die er für konform hält. Diese Token-Staker würden eine Rendite in Form von Gebühren aus dem Set von Frontends verdienen, zu dem sie staken. Wenn ein Frontend 100 US-Dollar an Gebühren generiert und 100 Einheiten jeweils 1 Token staken, dann hat jede Einheit Anspruch auf 1 US-Dollar. Kuratoren könnten anfangs eine Gebühr für ihre Dienstleistungen verlangen. In Zukunft könnten Regierungen Onchain-Atteste darüber ausstellen, dass Frontends in ihrer Gerichtsbarkeit konform sind, um Verbraucher zu schützen, wobei der Nebeneffekt die Automatisierung der Kuratierung wäre.

Ein potenzielles Risiko in diesem Modell besteht darin, dass nicht konforme Front-Ends kostengünstiger zu betreiben sind, da ihnen der administrative Aufwand von konformen Front-Ends fehlt. Sie könnten auch Modelle entwickeln, um Frontend-Gebühren an Händler zu recyceln, um weitere Anreize für ihre Problemumgehung zu schaffen. Zwei Faktoren mindern dieses Risiko. Erstens möchten die meisten Benutzer tatsächlich, dass konforme Frontends ihren lokalen Gesetzen und Vorschriften entsprechen. Dies gilt insbesondere für große, regulierte Institute. Zweitens könnte Governance eine wichtige Rolle als letzter Ausweg oder "Veto-Instanz" bei nicht konformen Frontends spielen, die wiederholt gegen die Regeln verstoßen und die Lebensfähigkeit der App gefährden, indem sie schlechtes Verhalten verhindern.

Schließlich würden alle Gebühren von Transaktionen, die nicht über eine registrierte Benutzeroberfläche initiiert werden, in einem einzigen universellen Staking-Modul hinterlegt, wodurch das Protokoll Einnahmen aus Transaktionen erfassen kann, die von Bots und anderen direkten Interaktionen mit den Smart Contracts des Protokolls initiiert wurden.

Von der Theorie zur Umsetzung: Die Methode in die Praxis umsetzen

Lassen Sie uns den App-Token-Stack genauer betrachten. Damit ein Protokoll Frontend-Staking erleichtern kann, müsste es einen Registrierungs-Smart-Vertrag festlegen, mit dem sich Frontends registrieren müssten.

1. Jedes Frontend oder API kann einen speziellen TXT-Eintrag zum DNS-Eintrag ihrer Domain hinzufügen wie das ENS DNS-Integration. Dieser TXT-Eintrag enthält den öffentlichen Schlüssel eines Schlüsselpaars, das der Frontend einmal generiert, das Zertifikat genannt wird.

1. Der Frontend-Client kann dann eine register()-Funktion aufrufen und nachweisen, dass er im Besitz seines Domainnamens ist. Eine Zuordnung der Domäne zum öffentlichen Zertifikatsschlüssel und umgekehrt wird gespeichert.
2. Wenn Transaktionen durch den Client erstellt werden, signiert er auch die Transaktionsnutzlast mit seinem Zertifikatöffentlichen Schlüssel. Diese werden an die Smart Contracts der Anwendung im Paket übergeben.
3. Die Smart Contracts der Anwendung validieren das Zertifikat, überprüfen, ob es dem richtigen Transaktionskörper entspricht, und ob es registriert wurde. Wenn ja, wird die Transaktion verarbeitet. Die durch die Transaktion generierten Gebühren werden dann zusammen mit dem Domainnamen (aus dem Register) an einen Gebührensammler-Vertrag gesendet.
4. Der FeeCollector ermöglicht Kuratoren, Benutzern, Validatoren und anderen, Tokens direkt an eine Domain oder eine Gruppe von Domains zu setzen. Diese Verträge müssen die Menge der auf jeder Domain gesetzten Tokens, den Anteil jeder Adresse an diesem Einsatz und die Zeit, für die sie eingesetzt wurden, verfolgen. Beliebte Implementierungen des Liquiditäts-Minings können als Ausgangspunkt für diese Vertragslogik verwendet werden.
5. Benutzer, die an Kuratoren gestaket haben (oder direkt an die Gebührenverwaltungsverträge selbst), können dann den anteiligen Anteil der Gebühr entsprechend der Menge des an die Domain gestaketten App-Tokens abheben. Die Architektur könnte ähnlich sein wie MetaMorpho/Morpho Blau.

Dies könnte eingeführt werden, ohne die Governance-Belastung einer Anwendung DAO zu erhöhen. Tatsächlich könnten die Governance-Verantwortlichkeiten reduziert werden, da der Gebührenschalter dauerhaft für alle durch das Protokoll ermöglichten Transaktionen eingeschaltet werden könnte, wodurch jegliche Kontrolle der DAO über das wirtschaftliche Modell des Protokolls entfernt wird.

Zusätzliche Überlegungen basierend auf dem Anwendungstyp

Während diese Prinzipien im Allgemeinen auf ökonomische Modelle von Anwendungstoken zutreffen, können andere Gebührenerwägungen je nach Art der Anwendung anfallen: Apps, die auf Layer 1s oder Layer 2s, App-Chains und Apps, die Rollups verwenden, erstellt wurden.

Überlegungen für L1/L2-Anwendungen

Anwendungen auf Layer 1- oder Layer 2-Blockchains verfügen über Smart Contracts, die direkt onchain bereitgestellt werden. Gebühren werden erhoben, wenn Benutzer mit den Smart Contracts der Anwendungen interagieren. Normalerweise geschieht dies über eine benutzerfreundliche Oberfläche (wie eine App oder Website), die als Schnittstelle zwischen einem Endbenutzer und den zugrunde liegenden Smart Contracts dient. In diesem Fall stammen alle Gebühren von dieser Oberfläche. Das obige Beispiel zu app.xyz veranschaulicht, wie ein Gebührensystem für eine Layer 1-App funktionieren könnte.

Statt sich auf Kuratoren zu verlassen, um Frontend-Gebühren zu filtern, könnten Apps auch einen Whitelist- oder Blacklist-Ansatz für Frontends verfolgen, die zu Netzwerkgebühren beitragen. Auch hier wäre es das Ziel, sicherzustellen, dass Tokeninhaber und das Protokoll im Allgemeinen nicht von illegalen Aktivitäten profitieren oder davon profitieren und den gesetzlichen Bestimmungen und Vorschriften des jeweiligen Rechtsgebiets folgen.

Beim Whitelist-Ansatz würde die App einen Satz Regeln für Frontends veröffentlichen, ein Register derjenigen Frontends erstellen, die den Regeln folgen, ein Zertifikat an Frontends ausstellen, die sich dafür entscheiden, und von Frontends verlangen, Token zu setzen, um einen Teil der App-Gebühren zu erhalten. Wenn Frontends diese Regeln nicht befolgen, würden sie abgestraft und ihr Zertifikat für Gebührenbeiträge würde entfernt.

Bei der Blacklist-Methode müssten Apps keine Regeln erstellen, aber das Starten eines Frontends für die Anwendung wäre nicht ohne Genehmigung. Stattdessen würde die App verlangen, dass jedes Frontend eine Stellungnahme einer Anwaltskanzlei vorlegt, dass das Frontend mit seiner Zuständigkeit übereinstimmt, bevor es dem Frontend gestattet wird, die App zu nutzen. Sobald die Stellungnahme eingegangen ist, würde die App dem Frontend Zertifikate für Gebührenbeiträge ausstellen, die nur entfernt werden, wenn die App eine Benachrichtigung von einem Regulierungsorgan erhält, dass das Frontend nicht konform ist.

Die Gebühren-Pipeline würde den in den vorherigen Abschnitten angegebenen Beispielen entsprechen.

Beide Ansätze erhöhen die Belastung dezentraler Governance erheblich, da DAOs entweder eine Reihe von Regeln festlegen und pflegen oder rechtliche Meinungen zur Einhaltung bewerten müssen. In einigen Fällen mag dies akzeptabel sein, aber in den meisten Fällen wäre es vorzuziehen, diese Compliance-Belastung an einen Kurator auszulagern.

Überlegungen für Appchains

Appchains sind anwendungsspezifische Blockchains mit Validatoren, die nur für diese Anwendung arbeiten.

Als Gegenleistung für ihre Arbeit erhalten diese Validatoren eine Zahlung. Im Gegensatz zu Layer-1-Blockchains, bei denen Validatoren oft durch die inflationäre Ausgabe von Token belohnt werden, geben einige Appchains (dYdX) stattdessen die Kundenentgelte an die Validatoren weiter.

In diesem Modell müssen Tokeninhaber Einsätze an Validatoren leisten, um Belohnungen zu erhalten. Die Validatoren werden zu den kuratierten Staking-Modulen.

Dieses Arbeitsset unterscheidet sich von einem Layer 1-Validierer. Appchain-Validatoren abwickeln spezifische Transaktionen aus einer bestimmten Anwendung. Aufgrund dieses Unterschieds könnten Appchain-Validatoren ein höheres Maß an rechtlichem Risiko in Bezug auf die zugrunde liegende Tätigkeit tragen, die sie erleichtern. Daher sollten Protokolle den Validatoren die Freiheit gewähren, die Arbeit zu leisten, die sie gemäß den Gesetzen ihrer Gerichtsbarkeit und ihres eigenen Komfortniveaus leisten können. Dies kann ohne Beeinträchtigung der Erlaubnislosigkeit der Appchain oder einer erheblichen Zensurgefahr erfolgen, vorausgesetzt, dass ihr Validatoren-Set geografisch dezentralisiert ist.

Die Architektur für Appchains, die von den Vorteilen der Gebührenverfolgbarkeit profitieren möchten, wäre ähnlich wie bei Layer 1-Anwendungen bis zum Gebühren-Pipeline. Aber die Validatoren könnten eine Frontend-Zuordnung verwenden, um zu bestimmen, von welchen Frontends sie Transaktionen verarbeiten möchten. Die Gebühren für eine bestimmte Transaktion würden dann an den aktiven Validatoren-Satz gehen, wobei inaktive Validatoren, die sich dafür entschieden haben, nicht teilzunehmen, auf solche Gebühren verzichten würden. Aus Sicht der Gebühren erfüllt der Validator dieselbe Funktion wie die oben diskutierten Stake-Modul-Kuratoren, und diejenigen, die an diese Validatoren setzen, könnten sicherstellen, dass sie keine Einnahmen aus illegalen Aktivitäten erhalten. Die Validatoren könnten auch einen Kurator wählen, um zu bestimmen, welche Frontends in Übereinstimmung mit der Gerichtsbarkeit stehen.

Überlegungen für Anwendungs-Rollups

Rollups haben ihren eigenen Blockspace, können aber die Sicherheit einer anderen Kette erben. Die meisten Rollups haben heute einen einzigen Sequenzer, der für die Sequenzierung und Aufnahme von Transaktionen verantwortlich ist, obwohl Transaktionen über einen Prozess namens "direkt an Layer 1 übermittelt werden können.Zwangsinklusion.”

Wenn diese Rollups anwendungsspezifisch sind und ihren Sequenzer als einzigen Validator festlegen, können die Gebühren, die durch von diesem Sequenzer enthaltene Transaktionen generiert werden, basierend auf dem kuratierten Satz konformer Frontends oder als allgemeiner Pool an Stakeholder verteilt werden.

Wenn Rollups ihren Sequencer-Satz dezentralisieren, werden die Sequenzer zu den de facto kuratierten Staking-Modulen und die Gebühren-Pipeline würde der von Appchains ähneln. Sequenzer ersetzen Validatoren für die Gebührenverteilung, und jeder Sequenzer kann eigene Entscheidungen darüber treffen, von welchen Frontends Gebühren akzeptiert werden sollen.

Während es viele mögliche Modelle für Anwendungstoken gibt, ist die Bereitstellung von kuratierten Staking-Pools ein Weg nach vorne, der hilft, eine Nadel auf den extrinsischen Herausforderungen zu ziehen, die für Anwendungen einzigartig sind. Indem sie die intrinsischen und extrinsischen Herausforderungen erkennen, denen Apps gegenüberstehen, können Gründer bessere App-Token-Modelle von Grund auf für ihr Projekt entwerfen.

Haftungsausschluss：

1. Dieser Artikel wurde von [wiedergegebena16zcrypto]. Alle Urheberrechte gehören dem Originalautor [ Mason HallPorter SmithMiles Jennings und Ross Shuel]. Wenn es Einwände gegen diesen Nachdruck gibt, wenden Sie sich bitte an die Gate LearnTeam, und sie werden es umgehend bearbeiten.
2. Haftungsausschluss: Die in diesem Artikel zum Ausdruck gebrachten Ansichten und Meinungen sind ausschließlich die des Autors und stellen keine Anlageberatung dar.
3. Übersetzungen des Artikels in andere Sprachen werden vom Gate Learn-Team durchgeführt. Sofern nicht anders angegeben, ist das Kopieren, Verteilen oder Plagiieren der übersetzten Artikel verboten.