Revenue models for applications

The objective of this topic is to brainstorm sensible revenue models for applications. So far, I’ve come up with about four (although it could be argued that burning tokens in intents vs paying fees in intents are essentially the same mechanism). More are definitely possible, brainstorming welcome!

Tokens required

App token burn in intents

Similar to XAN burn in intents (here), the intents crafted by an application and the solvers which process them can require that some of an app’s associated token be burned. These can be combined when applications are composed (so multiple tokens would be burned).

Tokens not required

Fees in intents

The intents crafted by an application and the solvers which process them can require that some token be sent to a specific party (i.e. the application developer). This mechanism works similarly to token burning in intents, but doesn’t require a token.

Sequencing fees

An application developer can operate a sequencer (settling elsewhere), and sequencing fees (top-of-block auctions, priority fees, and/or other transaction-related fees) are simply paid to them. No token is required for this model, although one could be used for fees and then burned (which then may make it a convenient economic tool for a decentralized sequencer).

Bond proxy revenue

An application could hold XAN bonds on behalf of users (not custodially, but in application code), and take a small cut of the interest in return for doing so (and perhaps also vote for those users, craft a different, secondary voting mechanism, etc.). An application could hold a portfolio of bonds and perhaps provide different products to users (e.g. fixed interest). No token is required for this model, although one could be used if desired.

3 Likes