Move on Sui includes functionality that lets builders pay the gas fees for some or all of their app transactions, eliminating one of the biggest hurdles users face in moving to Web3. Typically on Web3 networks, users pay what's called a gas fee to use an app. Sui's sponsored transaction functionality eliminates this friction for builders willing to adopt it.

The need to install a wallet and buy tokens to pay gas fees will instantly turn off many potential users, especially those used to the multitude of seemingly free Web2-based apps available. Although familiar apps such as Gmail and Facebook cost money to develop and maintain, their purveyors recoup costs and earn profits through advertising rather than charging users directly for network access.

Web3 needs more sophisticated revenue models to grow its user base, and sponsored transactions give builders that capability. With sponsored transactions, builders can pay the gas fees incurred by users of their apps and explore revenue models to cover their costs, from advertising to trialware to subscriptions.

Sponsorship strategies

The Sui documentation on sponsored transactions describes three implementation methods:

• User-initiated transactions
• Sponsor-initiated transactions
• GasData object-based transactions

In a user-initiated transaction, the user creates a GasLessTransactionData object, possibly as a function of an app, which gets sent to the builder for approval. The builder then initiates and signs a TransactionData object, which includes data on the gas fees. That structure goes back to the user to sign, then gets sent on to the Sui network for processing.

The actions required in this type of sponsored transaction would typically be automated in an app, making the back-and-forth invisible to the user. However, the builder needs to create a backend to manage approvals and gas fee payments.

Sponsor-initiated transactions give builders a means of directly sending gas fees to users, opening up a variety of promotional models to grow app use. Using this method, a builder creates a TransactionData object which essentially pre-authorizes a transaction, including assignment of gas fees to the builder. The builder can send the TransactionData object to a user via email, instant messaging, or any other type of Internet-based messaging.

This method works for direct email promotions, reaching out to potential users who may know nothing about Web3. The TransactionData object could allow for a limited trial, after which the user would need to pay for continued use of an app, or potentially bring the user into an ad-sponsored experience.

The third method requires that the builder first creates a GasData object, which defines the gas fee budget, and sends it to a user. The user, likely in the context of an app, creates a TransactionData object, signs it, and sends it back to the builder. The builder signs this object and sends it to the network for processing.

Of course, instead of directly sending objects between the user and builder, as with a sponsor-initiated transaction, the GasData and TransactionData objects are likely part of an app workflow. This method can be likened to giving the user a debit card which they can only use to pay an app's gas fee.

Revenue models

As Web2 models prove, with a sufficiently large user base builders can earn a lot through advertising models, enough to pay capital costs and earn a profit. Most web apps use existing ad networks to generate revenue, which generally make it easy to integrate display ads or other types of advertising. Google's ad network is one of the better known, but builders should research networks that meet their needs.

Where ads might work for apps that focus on user browsing, game and utility app builders may want to consider trialware, premium services, or add-ons. For example, a builder may offer a utility with basic functionality, and unlock premium features for a price. Under this model, the builder would need to pay the gas fees for all transactions from the basic and premium versions of the utility, and bet on the revenue from the premium version covering the total transaction fees. Add-ons work well for games, where a user may want to buy new levels to play or in-game equipment.

These latter models could be paid for using a software subscription service, paid for through fiat currency, or engineered on Sui. There are a number of software subscription services, some traditional and some competing directly in the Web3 market, that builders can research to support their apps. As a completely Sui-based model, a builder could require payment for subscriptions or add-ons in SUI tokens, although that may defeat the purpose of sponsored transactions.

Mainstream adoption

Sui's mission is to move the next billion people to Web3. Sui supports that mission technically through its highly performant, scalable network and low, predictable gas fees. Coupled with that environment, Move on Sui gives builders the tools to create a new generation of apps.

Sponsored transactions, along with other user-friendly features of Sui, pave the way to onboard people with no Web3 experience. They abstract away the unique technical aspects of using tokens and wallets and eliminate a roadblock to mainstream growth.