What Is an Offerwall?

An offerwall is a monetization and engagement system that allows users to complete sponsored actions in exchange for rewards.

Those actions can include installing and using an app, completing a survey, reaching a specific level in a mobile game, registering for a service, signing up for a trial, or completing another advertiser-defined action.

The basic idea is simple:

Advertiser pays for a qualified action → offerwall provider tracks the action → publisher receives revenue → user receives a reward.

For a website owner, an offerwall can become a new revenue stream without creating and selling a product of your own.

For an app developer, it can give users a way to earn virtual currency, extra lives, credits, premium features, or other in-app benefits.

And for users, the appeal is obvious: instead of simply seeing an advertisement, they get something in return for taking an action.

That difference is what makes offerwalls interesting.

They are not simply another advertising format.

They are closer to a performance marketplace sitting inside your website or application.

After working around GPT sites, reward platforms, APIs, postbacks, and offer-based monetization, I have found that the biggest misunderstanding is that an offerwall is just a page containing offers.

It is not.

The visible wall is the easy part.

The hard part is everything underneath it: attribution, user identity, conversion tracking, reward calculations, postbacks, fraud prevention, reversals, reporting, and making sure that the economics still work after users are rewarded.

This guide explains the entire model from a practical publisher and developer perspective.

How Does an Offerwall Work?

A typical offerwall involves four parties:

1. Advertiser
2. Offerwall or performance network
3. Publisher
4. User

The advertiser wants a measurable result.

Instead of paying simply for an impression, the advertiser might pay when a user installs an application, registers an account, reaches a game milestone, completes a survey, or performs another qualifying action.

The offerwall provider connects that demand to publishers.

The publisher places the offerwall inside its website, application, game, or rewards platform.

The user sees available offers, chooses one, completes it, and receives a reward.

A simplified flow looks like this:

Advertiser
    ↓
CPA / CPI / CPE Campaign
    ↓
Offerwall Network
    ↓
Publisher Website or App
    ↓
User Completes Offer
    ↓
Conversion Verified
    ↓
Postback / Server Notification
    ↓
Publisher Credits User

The important word here is verified.

A serious offerwall should not simply trust that a browser or mobile client says:

“This user completed the offer.”

The reward event normally needs to come through a controlled tracking and postback process.

CPAlead's current publisher documentation, for example, recommends passing a publisher user ID through the offerwall and using the publisher postback to identify the user who should receive the reward. It also recommends storing the conversion identifier so duplicate notifications do not create duplicate rewards.

That is a small technical detail with a huge financial impact.

If your reward system credits the same conversion twice, you are effectively paying users twice for one revenue event.

What Types of Offers Are Found on an Offerwall?

The exact inventory depends on the provider, geography, device, audience, and advertiser demand, but common offer types include:

App installs

A user installs an advertised application and may need to open it or complete an additional requirement.

For example:

Install the app and open it for the first time.

Higher-value campaigns may continue beyond installation.

Game milestones

These are particularly common on gaming-focused offerwalls.

A user might be asked to:

• Reach level 10
• Complete a tutorial
• Upgrade a building
• Finish a particular mission
• Reach a specified player rank

The advertiser is generally interested in a user who demonstrates meaningful engagement, not just a download.

Surveys

Users answer questions about products, purchasing habits, demographics, or other topics.

Survey inventory can be attractive because completion may happen inside a relatively short session, although availability varies significantly by country and user profile.

Registrations and sign-ups

A user may be asked to create an account, register for a service, submit an application, or perform another defined registration event.

Trials and subscriptions

Some campaigns compensate users after starting a trial or subscription.

These should be handled particularly carefully because the advertiser's conversion criteria, cancellation rules, and attribution windows can affect whether the publisher ultimately keeps the revenue.

Purchase-based offers

Some campaigns require an actual purchase.

These can have high advertised rewards, but they also bring additional user expectations and support complexity.

Lead-generation offers

A user may submit information, request a quote, apply for a service, or complete another lead event.

The common thread is that the advertiser pays for an outcome.

That is what differentiates an offerwall from ordinary display advertising.

Offerwall vs. Rewarded Ads: What Is the Difference?

These two concepts are often mixed together because both involve rewarding users.

They are not the same thing.

Rewarded ad

A traditional rewarded ad generally gives the user an in-app reward after interacting with an advertisement.

For example:

Watch this video and receive 100 coins.

Google describes rewarded ads as a format where users can interact with video ads, playable ads, or surveys in exchange for in-app rewards. The user chooses to participate, and the reward is handled as part of the ad experience.

Offerwall

An offerwall presents multiple advertiser actions.

For example:

Complete a survey        +500 points
Install Game A           +1,200 points
Reach Level 10           +4,500 points
Register for Service     +2,000 points
Complete Research Study  +800 points

The user chooses which offer to pursue.

The difference is therefore not simply visual.

A rewarded ad typically revolves around an ad interaction.

An offerwall revolves around a marketplace of rewarded actions.

Why Do Website Owners Use Offerwalls?

For many publishers, the biggest advantage is diversification.

A website may already have:

• Display advertising
• Affiliate links
• Direct sponsorships
• Subscription revenue
• Digital products
• Donations
• Premium memberships

An offerwall adds another possible monetization layer.

This can be particularly powerful for websites where the audience is already interested in rewards, gaming, savings, incentives, or online earning.

For example, a GPT website can use an offerwall as one of its primary earning sections.

A community site might use it as an optional rewards area.

A loyalty platform can use offers to give members another way to earn points.

A mobile application can allow users to earn virtual currency through external offers instead of requiring the developer to give away premium currency for free.

The key is that the offerwall should make sense for the product.

Putting a wall full of unrelated offers inside a serious productivity application probably will not create the same results as putting it inside a rewards-focused application.

Why Do App Developers Use Offerwalls?

Mobile developers are often searching for a monetization method that can generate more value from users who are not making direct purchases.

Suppose a mobile game has:

• Paying users
• Non-paying users
• Highly engaged users
• Users who leave quickly

A small percentage may spend money.

The problem is what to do with everyone else.

An offerwall provides another path.

A non-paying player can potentially generate advertising revenue by completing sponsored actions.

At the same time, the player receives game currency.

This creates a different value exchange:

Advertiser gets a new customer
        ↓
Publisher gets advertising revenue
        ↓
Player gets in-game value

Unity's current Offerwall documentation describes the model around virtual currencies, placements, content cards, SDK integration, and publisher-side or provider-side currency management.

Unity also provides Offerwall integrations for Android, iOS, Flutter, React Native, and Unity applications.

How Does an Offerwall Make Money?

The publisher does not normally invent the advertiser payout.

The advertiser or campaign owner establishes the economic value of a qualifying action.

Imagine an advertiser pays the network:

$5.00

for a completed action.

The offerwall provider and publisher then determine how that revenue is distributed.

For illustration:

Advertiser payout:       $5.00
Publisher share:         $3.50
User reward value:       $2.50
Platform gross margin:   $1.00

The exact numbers are only an example.

Actual commercial arrangements vary significantly by provider, campaign, country, traffic source, offer type, and publisher agreement.

The important principle is this:

Your revenue is not the same thing as the advertised offer payout.

A publisher must account for:

• User rewards
• Network fees or revenue share
• Payment processing
• Fraud losses
• Chargebacks or reversals
• Support costs
• Taxes
• Infrastructure
• Referral commissions
• Currency conversion

This is why looking at an offer and seeing:

Earn $10

does not mean your business earns $10.

The unit economics happen underneath the visible reward.

What Is an Offerwall Network?

An offerwall network acts as the intermediary between advertisers and publishers.

Instead of negotiating with hundreds of advertisers yourself, you integrate with a network that already has campaign inventory.

The provider usually handles some combination of:

• Advertiser relationships
• Campaign management
• Tracking
• Attribution
• Offer filtering
• Fraud detection
• Conversion reporting
• Postbacks
• Publisher reporting
• Payment reconciliation

That is one reason offerwall networks are attractive to smaller publishers.

You are essentially outsourcing the advertiser marketplace.

Some providers offer a complete hosted wall.

Others offer:

• iframe integration
• JavaScript integration
• REST APIs
• SDKs
• server-to-server postbacks
• white-label experiences

For example, current CPAlead documentation provides multiple implementation options, including direct links, iframe, scripts, and Android integration, while using a publisher postback for reward crediting.

Offerwall Integration Methods

There is no single integration method that is best for everyone.

Hosted offerwall

The simplest approach is to send users to a provider-hosted offerwall.

Advantages:

• Fast implementation
• Minimal engineering
• Provider manages much of the UI
• Easy testing

Disadvantages:

• Less control over branding
• Less control over the user journey
• Potentially weaker integration with your product

This is often the right starting point for a small website.

iframe

An iframe allows the offerwall to appear inside your website.

It can feel more integrated than a plain external link while still reducing development effort.

The tradeoff is that your application is still dependent on the provider's interface and browser behavior.

JavaScript integration

Some web providers allow the wall to be embedded or controlled using JavaScript.

This can provide a more native experience and greater control over placement and behavior.

API integration

An API gives the developer much more control.

Instead of rendering a provider's wall directly, your backend can retrieve offer data and build its own interface.

This allows features such as:

• Custom sorting
• Custom categories
• Personalized layouts
• Your own point system
• Advanced analytics
• A/B testing
• Provider aggregation

But with that flexibility comes additional engineering responsibility.

Mobile SDK

For Android, iOS, Flutter, React Native, Unity, and similar platforms, an SDK can make integration easier because the provider handles much of the client-side experience.

Unity's current documentation, for example, supports Offerwall SDK integration and publisher-managed or provider-managed virtual currency flows.

Why Server-to-Server Postbacks Matter

This is one of the most important technical concepts in an offerwall.

A postback is a server-to-server notification sent after the provider records a conversion.

A simplified example:

User ID: 82731
Offer ID: 451
Conversion ID: ABC123
Payout: $4.20
Status: Completed

Your backend receives the notification and decides what to do.

A production reward system should not simply add money every time an HTTP request arrives.

You need to validate:

• Is the request authentic?
• Does the conversion belong to a known user?
• Have we processed this conversion before?
• Is the conversion valid?
• Is the payout amount valid?
• Is this a completion or a reversal?
• Does this offer permit this traffic source?
• Has the user's account been flagged for fraud?

Then the system can create a ledger transaction.

A sensible reward architecture looks like:

Postback
   ↓
Authentication / Signature Validation
   ↓
Conversion Lookup
   ↓
Duplicate Check
   ↓
Fraud / Risk Checks
   ↓
Reward Calculation
   ↓
Ledger Transaction
   ↓
User Balance

This architecture is far safer than directly modifying a balance.

Why You Should Use a Ledger Instead of Just a Balance

This is one lesson that becomes obvious only after building real reward systems.

Imagine a user has:

10,000 points

and then an advertiser reverses a previous conversion worth:

2,000 points

If your application only stores:

balance = 10000

you may have no reliable way to explain where that balance came from.

A proper ledger records events.

For example:

+2,000  Offer completion
+500    Survey completion
-2,000  Offer reversal
+300    Daily bonus
-500    Withdrawal

Current balance:

300 points

The ledger gives you an audit trail.

It is especially useful when users contact support and say:

“Why did my balance decrease?”

You should be able to identify the exact transaction rather than guessing.

HansalDev's guide on building an offerwall website follows this same architecture: verified server-to-server callbacks, idempotent reward processing, a wallet ledger, fraud checks, and withdrawal controls.

Offerwall Fraud: The Problem Most Beginners Underestimate

If you plan to operate an offerwall, fraud will not be an optional consideration.

Reward systems attract users who are motivated by the reward itself.

Most users may be legitimate.

Some will test the limits.

Others will actively search for ways around them.

Potential abuse can include:

• Multiple accounts
• VPN or proxy traffic
• Device farms
• Emulator abuse
• Fake identities
• Cookie manipulation
• Repeated conversions
• Incentive abuse
• Chargeback behavior
• Automated activity

This creates a difficult balance.

You cannot reject everyone simply because they look unusual.

But you also cannot blindly reward every postback.

A good system combines multiple signals:

Account age
+
Device signals
+
IP reputation
+
Velocity
+
Conversion history
+
Offer behavior
+
Provider response
+
Withdrawal history
=
Risk score

You should also expect some advertiser conversions to be reversed.

That means a conversion that looks successful today may not represent final revenue tomorrow.

Your accounting system therefore needs to support states such as:

Pending → Approved → Reversed

rather than assuming every reward is permanently valid the moment it appears.

What Are the Most Important Offerwall Metrics?

Do not judge an offerwall using total revenue alone.

At minimum, monitor:

Offer starts

How many users actually click or begin an offer?

Conversion rate

How many started offers become qualifying conversions?

Revenue per active user

How much revenue does the wall generate relative to your active audience?

Reward cost

How much of your generated revenue are you returning to users?

Net revenue

What remains after rewards, provider costs, reversals, and other direct expenses?

Retention

Do users return after discovering the offerwall?

Average revenue per user

This helps compare the value of different traffic segments.

Fraud rate

How much activity is suspicious, reversed, rejected, or chargeback-prone?

Country-level performance

This is particularly important because offer availability and advertiser economics can vary dramatically by geography.

An offerwall that performs extremely well in the United States may behave very differently in Egypt, India, Brazil, Indonesia, or other markets.

That is why a network should never be judged only by its highest advertised payout.

Geography Can Change Everything

One of the biggest mistakes is assuming that every user sees the same offer inventory.

They do not.

Availability can depend on:

• Country
• Device
• Operating system
• User profile
• Existing app installation
• Advertiser targeting
• Campaign caps
• Historical user behavior
• Time of day
• Traffic quality

Imagine a publisher has:

40% United States
20% United Kingdom
15% Germany
10% Canada
15% MENA

The same offerwall provider could generate very different economics across those segments.

This is why serious publishers should report performance by country rather than looking only at global averages.

It can also make sense to integrate more than one provider when the audience is geographically diverse.

HansalDev's current comparison of offerwall networks makes the same practical point: there is no universal “best” network because inventory, geography, integration, traffic quality, and user eligibility all affect actual performance.

How Should You Design the Offerwall UX?

The goal is not to show as many offers as possible.

The goal is to help users find a legitimate, understandable offer quickly.

A good wall should make these things clear:

What do I need to do?

How much will I earn?

How long might it take?

Is the offer available for my device?

Are there additional conditions?

When will I receive the reward?

A useful card might look like:

Reach Level 15

Complete the game within 14 days

Reward: 4,500 points

Estimated effort: Medium

The user should not have to read a tiny block of legal text to understand the basic action.

At the same time, terms should not be hidden.

Transparency reduces support problems.

It also reduces the gap between what the user thinks they purchased and what they actually agreed to do.

Offerwalls and User Trust

This is where the technology meets the product.

A user who completes an offer and does not receive the promised reward is not thinking:

“There was a postback synchronization issue.”

They are thinking:

“This site stole my time.”

That distinction matters.

A good offerwall therefore needs a clear support process.

Users should be able to find:

• Offer ID
• Completion status
• Reward amount
• Pending status
• Expected credit time
• Support instructions

Even better, give them an offer history.

For example:

Offer History

Game X — Level 10
Status: Pending

Survey Y
Status: Credited

App Z — Install
Status: Reversed

This makes the system feel accountable.

That feeling of accountability is surprisingly important for retention.

Offerwall Policies and Platform Compliance

This is an area where developers need to be careful.

An offerwall can involve advertising, incentives, tracking, user data, third-party SDKs, and sometimes financial rewards.

You therefore need to review the rules of every platform involved.

Google advertising policies

Google's policies distinguish between rewarded ad experiences and other forms of incentivized activity.

For AdMob rewarded ads, Google requires clear disclosure of the reward and action, user choice in standard rewarded formats, and delivery of the promised reward. Google also restricts direct monetary rewards in rewarded ad units and sets conditions around how rewards can be redeemed.

Google also explicitly warns publishers against artificial or incentivized ad clicking and says publishers must not encourage users to click Google ads.

This distinction matters:

An offerwall is not permission to incentivize ordinary Google ad clicks.

Treat the offerwall and your conventional advertising inventory as separate products with separate policy requirements.

Apple and iOS

Apple also requires developers to accurately describe the data practices of their applications and third-party SDKs.

Apple's current App Store documentation explains that developers must disclose relevant data collection by third-party code and identify whether collected data is linked to users or used for tracking.

If your implementation involves tracking users across apps and websites, Apple's AppTrackingTransparency framework may also apply. Apple states that authorization is required for tracking covered by the framework.

This becomes particularly important when integrating third-party advertising and offerwall SDKs.

Before shipping, review the provider's data collection documentation and the platform requirements rather than assuming that an SDK is automatically compliant.

Should You Use an Offerwall on a Website?

An offerwall is particularly worth testing when your audience already has a reason to care about rewards.

Examples include:

• GPT websites
• Loyalty platforms
• Gaming communities
• Reward portals
• Cashback products
• Community platforms
• Digital incentive services

It can also work as a secondary monetization feature on other sites, but the fit matters.

A visitor coming to read a technical article may have zero interest in installing three games to earn points.

A user visiting a rewards platform is completely different.

So the strongest predictor of success is not:

“Does the offerwall have high payouts?”

It is:

“Does the offerwall match the user's intent?”

Should You Use an Offerwall in a Mobile App?

For applications, the answer depends heavily on the app's monetization model.

Offerwalls are especially relevant to:

• Mobile games
• Reward apps
• Loyalty apps
• Points-based applications
• Entertainment apps
• Free-to-use applications with virtual currencies

A game can, for example, allow players to earn premium currency through optional offers instead of requiring every player to make an in-app purchase.

This can potentially improve monetization without forcing a purchase.

However, the experience should remain optional and should not interfere with the application's core functionality.

Apple's current guidelines explicitly state that apps may incentivize certain actions inside apps, while also prohibiting forcing users to perform certain App Store-related actions such as ratings or reviews to access functionality.

Hosted Offerwall vs. Building Your Own

This is an important strategic decision.

Use a hosted offerwall when:

You want to launch quickly.

You have limited engineering resources.

You want the provider to handle most of the offer UI.

You are testing whether the business model works.

Build your own interface when:

You want complete branding.

You need custom ranking and personalization.

You want multiple offer providers behind one interface.

You need advanced analytics.

You want control over your wallet and reward experience.

You are building an offerwall product rather than simply adding one to another product.

The middle ground is often the best approach:

Use provider APIs for inventory and your own backend for identity, ledger, rewards, fraud, and user experience.

That gives you considerably more control without requiring you to become an advertiser network yourself.

Can You Combine Multiple Offerwall Networks?

Yes, and for larger publishers this can be strategically useful.

Imagine:

Your Platform
      ↓
Offerwall Aggregation Layer
      ↓
 ┌──────────┬──────────┬──────────┐
 Network A  Network B  Network C

Instead of sending the user to three different walls, you can potentially normalize the offers into your own product experience.

The benefits can include:

• More inventory
• Greater geographic coverage
• Better redundancy
• More testing opportunities
• Potentially better monetization

But there are complications.

You need to prevent duplicate campaigns.

You need to understand attribution rules.

You need to keep provider-specific identifiers.

You need separate postback processing.

You need to understand reversals.

And you need to ensure you do not accidentally violate a provider's traffic or integration terms.

At that point, you are no longer simply “adding an offerwall.”

You are building a monetization layer.

A Practical Architecture for a Website Offerwall

For developers building the infrastructure themselves, a reliable architecture can look like this:

Frontend
    ↓
Authenticated User
    ↓
Offerwall / API
    ↓
Tracking URL with User Reference
    ↓
Advertiser / Network
    ↓
Conversion
    ↓
Provider Postback
    ↓
Webhook Controller
    ↓
Signature Validation
    ↓
Conversion Deduplication
    ↓
Fraud / Risk Check
    ↓
Reward Ledger
    ↓
User Balance
    ↓
Withdrawal System

Your database should ideally maintain separate concepts for:

• Users
• Offers
• Offer clicks
• Conversions
• Postbacks
• Reward transactions
• Reversals
• Withdrawals
• Fraud events
• Provider accounts

Do not put everything into one users.balance field and expect that to scale cleanly.

The balance is the result.

The ledger is the history.

That distinction becomes critical as soon as money is involved.

For a deeper technical treatment, see HansalDev's guide:

How to Create an Offerwall Website: Complete Builder's Guide

How Much Can an Offerwall Earn?

There is no universal answer.

Anyone promising a fixed number such as:

“An offerwall will make you $1,000 per month”

is ignoring too many variables.

Revenue depends on:

Traffic volume

How many people actually reach the wall?

User intent

Are they interested in rewards?

Geography

What advertisers are available for your users?

Device mix

Do you have Android, iOS, desktop, or mixed traffic?

Offer availability

How many eligible offers exist?

Conversion rate

How many users actually complete them?

Reward economics

How much of the payout are you returning to users?

Fraud and reversals

How much apparent revenue survives final validation?

A more useful formula is:

Net Offerwall Revenue

=
Qualified Conversions
×
Net Publisher Revenue per Conversion

−
User Rewards
−
Reversals
−
Fraud Losses
−
Processing Costs

That is much closer to the real business model.

The Biggest Offerwall Mistakes

Choosing a network based only on the highest payout

A $20 offer is useless if your users cannot qualify for it.

Crediting rewards before validating conversions

This creates financial exposure.

Not implementing duplicate protection

One repeated callback can result in double payment.

Ignoring reversals

Advertiser revenue is not always final immediately.

Treating all countries equally

Offer inventory and economics differ significantly.

Building the UI before building the ledger

The wall can look beautiful while the accounting underneath is fundamentally broken.

Overloading users with offers

More offers do not automatically mean more conversions.

Hiding support information

Reward users need a clear path when something goes wrong.

Ignoring platform policies

A technically correct implementation can still create distribution or monetization problems if the app violates platform rules.

The Future of Offerwall Monetization

Offerwalls are evolving from simple lists of sponsored actions into more sophisticated monetization systems.

The direction is clear:

Personalization

Show users offers that are relevant to their interests and devices.

Dynamic ranking

Prioritize offers based on conversion probability and expected value.

Smarter fraud detection

Use behavioral and device signals instead of relying on simple blacklists.

Multi-network aggregation

Combine several demand sources.

Better APIs

Move from embedded walls toward fully controlled publisher experiences.

Real-time event processing

Handle postbacks and reward updates more quickly.

Deeper product integration

The offerwall becomes part of the application rather than a separate page.

The best implementations will probably feel less like advertisements and more like a built-in marketplace.

That is the real opportunity.

Is an Offerwall Worth Adding to Your Website or App?

For the right product, absolutely.

But the answer should not be based on the existence of high payouts or impressive screenshots.

Ask five questions first:

Do my users actually want rewards?

Do I have enough active users to generate meaningful volume?

Does the provider have good inventory for my countries?

Can I implement secure conversion tracking and reward processing?

Can I support users when conversions are delayed or reversed?

If the answer is yes, an offerwall can become much more than another advertising widget.

It can become a complete engagement loop:

User visits
   ↓
Discovers an offer
   ↓
Completes an action
   ↓
Receives a reward
   ↓
Uses the reward
   ↓
Returns to the platform
   ↓
Completes another offer

That loop is why offerwalls remain interesting for both websites and mobile applications.

The technology itself is not particularly mysterious.

The real challenge is building a trustworthy system around it.

You need accurate attribution.

You need secure postbacks.

You need an auditable wallet.

You need fraud controls.

You need sensible reward economics.

And most importantly, you need to make the experience useful enough that users willingly come back.

Final Thoughts

An offerwall is essentially a performance-driven rewards marketplace embedded inside a website, app, game, or digital platform.

Advertisers pay for actions.

Offerwall networks provide campaign inventory and tracking.

Publishers provide the audience and user experience.

Users receive rewards for completing qualifying actions.

That sounds simple until you operate one.

Then you discover that the real business is not the visible wall.

It is the system underneath it.

The most successful implementations treat the offerwall as a serious product:

identity → attribution → conversion → verification → ledger → reward → withdrawal → support

That mindset changes everything.

For website owners, offerwalls can create a new revenue stream and increase engagement.

For app developers, they can monetize users who would otherwise generate little or no direct revenue.

For GPT and reward-platform operators, the offerwall can become the central engine of the entire business.

And for developers building the infrastructure themselves, it can become a sophisticated monetization layer built on APIs, S2S callbacks, reward accounting, and fraud prevention.

For more practical reading, HansalDev also covers the broader GPT business model, how offerwall websites are built, mobile SDK integration, and offerwall network comparisons:

How the Get-Paid-To (GPT) Business Model Works

How to Create an Offerwall Website: Complete Builder's Guide

How to Add an Offerwall SDK to Android & iOS Apps

Best Offerwall Networks in 2026

For technical implementation and policy validation, the most useful primary references include Google's rewarded ads documentation, Google's rewarded ad policies, Apple's App Privacy documentation, and Unity's Offerwall documentation.

Written for website owners, app developers, publishers, and digital product builders evaluating offerwall monetization in 2026.