Monetizing the WalletConnect Network

Towards Sustainable Fees for Onchain Connectivity

WalletConnect

November 2025

1. Summary

Since its inception in 2018, WalletConnect has become a foundational layer of onchain infrastructure enabling seamless, secure, remote connections between wallets and apps. Over the years, the WalletConnect Network has grown to support more than 700 wallets and 80,000 apps, facilitating over 380 million secure connections and enabling billions of dollars in onchain value transfer. From mobile wallet interactions to institutional DeFi access, WalletConnect has powered critical use cases across the ecosystem.

In 2025, the WalletConnect Network transitioned to a decentralized architecture. Today, 21 independent Node Operators maintain the network, and the introduction of the WalletConnect Token (WCT) has enabled decentralized governance, staking, and the introduction of rewards programmes for ecosystem participants.

• Wallet Partners receive token rewards for driving user activity and adoption.
• Node Operators earn rewards for providing reliable connectivity and decentralizing the network.
• Stakers participants are rewarded for their long-term commitment to the network.

To date, these rewards have been funded from a pre-allocated "rewards pool" comprising 17.5% of the initial token supply. However, this rewards pool will be depleted over time, meaning that maintaining this level of infrastructure and aligning incentives across all participants will not be sustainable without introducing fees. To date, none of the participants of the WalletConnect Network has paid to use its services.

This paper proposes a sustainable fee mechanism to address that imbalance. In the original WalletConnect Network whitepaper, we envisaged that apps, which typically derive substantial value from the Network, would eventually become fee-paying. Here, we introduce a proposal for application-side fees based on volume and yield, metrics that reflect the economic value flowing through the WalletConnect Network from wallets to apps.

As a first step, it proposes a relatively simple monetization framework, designed to minimize implementation complexity and provide a clear path to adoption. It is not intended to represent the final or permanent model for network monetization. Rather, it serves as a starting point, one that can evolve through community input, ecosystem scrutiny, and iterative improvements.

Before implementation, this proposal will be subject to open discussion and a governance vote, ensuring alignment with the broader WalletConnect community and its long-term vision.

2. The Rationale Behind Application-Side Monetization

Applications (apps) in the onchain ecosystem offer valuable services to users, but critically, they do not operate in isolation. Every app-to-user interaction depends on a secure and trusted communication bridge between a wallet (where the user holds funds and signs transactions) and the application interface. Since 2018, WalletConnect has provided this bridge, enabling real-time, secure, and seamless connections between wallets and apps without requiring users to compromise on custody or experience.

While apps provide the front-end service, wallets and the WalletConnect Network jointly enable access to the user and to the value they hold. Wallets safeguard the user’s private keys and interface for signing transactions. WalletConnect delivers the communication protocol that connects the two sides in a decentralized and interoperable manner. Without this infrastructure, value exchange between users and apps, especially across wallets and platforms, would be fragmented or entirely infeasible.

As the onchain economy matures, a large share of financial value flows through WalletConnect-powered connections. Apps are often the monetary beneficiaries of this value, whether through fees, spreads, revenue-generating actions, or broader business models.

To date, no fees have been paid for using the WalletConnect Network, creating a fundamental imbalance in the value chain.

Over the years, WalletConnect has facilitated billions of dollars in transaction volume and hundreds of millions of secure connections, directly powering the economic activity and growth of thousands of applications; yet none of this value has contributed back to sustaining the shared infrastructure that enables it. Introducing fees on the application side:

• Aligns incentives: Applications that benefit from WalletConnect-enabled transactions also contribute back to the infrastructure.
• Ensures sustainability: Wallet partners, Node operators, and governance participants can be adequately and fairly compensated.
• Preserves neutrality: Users remain unaffected by fees; they continue using their preferred wallets without changes to their experience.

This approach recognizes that value flows from users (via wallets) to apps, and that apps should contribute to the infrastructure that makes this value flow possible.

3. Objective

The primary objective of introducing WalletConnect fees is to ensure the economic sustainability and long-term growth of the network.

It seeks to align incentives among the core participants of the ecosystem: wallets, applications, and node operators, while maintaining a neutral, open, and reliable connectivity layer for the financial internet.

Applications contribute fees based on the financial activity they generate through the network.

End users will not pay to use WalletConnect. The experience remains smooth, free, and uninterrupted.

Fees apply only at the application layer, ensuring that wallets and their users continue to connect, transact, and interact as before.

WalletConnect fees apply only when the network facilitates value-bearing transactions.

Applications that use WalletConnect solely for authentication, wallet login, account linking, or other non-financial interactions do not incur fees.

This ensures a usage-based and value-aligned model, where applications contribute in proportion to the economic value they capture, rather than paying a blanket charge for network access.

In the following sections, we outline the two main categories used to measure financial activity and determine fees.

• Wallets receive rewards for enabling user access, safeguarding private keys, and executing onchain transactions on behalf of users.
• Node Operators earn rewards for running the WalletConnect infrastructure in a secure, decentralized, and regionally distributed manner, ensuring network reliability and performance.

3.1 Rewards Distribution

In this model, rewards are determined by the actual revenue generated by the network, ensuring that incentives scale directly with network performance.

Revenue Distribution Model

Let:

• R= Total Protocol Revenue,
• B_w= Base Wallet Rewards (USD-based, converted to WCT),

$$ B_{\mathrm{w}} $$

• B_n= Base Node Rewards (USD-based, converted to WCT).

• Surplus: S=R−B_w−B_n.

$$ S=R-B_{\mathrm{w}}-B_{\mathrm{n}}. $$

Revenue is allocated as follows:

1. Wallet Rewards

$$ \mathrm{W a l e t;R e w a r d s}=B_{\mathrm{w}}+\phi_{w},S, $$

2. Node Rewards

$$ \mathrm{N o d e\ R e w a r d s}=B_{\mathrm{n}}+\phi_{n},S, $$

3. Protocol Treasury

Treasury Allocation=ϕ_tS,

Where: ϕ_w,ϕ_n,ϕ_tare governance-defined allocation parameters such that:

$$ \phi_{w},\phi_{n},\phi $$

$$ \phi_{w}+\phi_{n}+\phi_{t}=1 $$

The Protocol Treasury funds:

• Ongoing research and development,
• Strategic growth initiatives,
• Potential top-ups to the Flexible Rewards Vault.

The Flexible Rewards Vault (a fixed share of the total supply) subsidizes base rewards if:

$$ R<(B_{\mathrm{w}}+B_{\mathrm{n}}) $$

• In such cases, the vault covers the shortfall to maintain minimum incentives for wallets and node operators.
• Staking rewards are funded separately from this vault, as part of the protocol’s monetary policy, rather than operational income.

3.1.1 Key Advantages

• Performance-based— Rewards grow in line with actual network revenue.
• Currency-aligned— USD-based calculation, WCT-based payment.
• Built-in sustainability— Treasury funding ensures long-term growth investment.
• Shock resilience— Flexible Rewards Vault maintains base incentives in downturns.
• Governable— Allocation parameters ϕ_w,ϕ_n,ϕ_tcan be adjusted via governance, or even modeled as functions of revenue growth.

$$ \phi_{w},\phi_{n},\phi_{t} $$

Figure 1: Protocol revenue and rewards distribution flow.

4. Categorization

To provide the fairest and most accurate pricing mechanism, the WalletConnect Network introduces a categorization framework that recognizes the different ways applications generate value through onchain financial activity.

The objective is to ensure that the network’s monetization framework remains aligned with each application’s underlying business model, so that fees are proportional to the real economic value derived from WalletConnect-facilitated activity.

Through analysis of network activity and common revenue models across the decentralized application landscape, WalletConnect identifies two primary categories of financial activity:

• (i) volume-based activity
• (ii) yield-based activity

Importantly, this categorization happens at the smart contract level, not at the application or project level. This means that each transaction is analyzed based on the specific contract calls executed within a wallet-signed transaction and is classified into one of the two categories accordingly.

This enables fine-grained billing accuracy — so if an application offers multiple types of financial services (e.g., swaps and staking), each component is billed according to its actual financial activity type.

Billing applications are based on their project identifier (project_id). This mechanism will be further reinforced through our Certification program, where, similar to how applications are required to verify their URL domain, projects will now also need to register the smart contracts they rely on. These contracts will be verified and then used as the basis for accurate categorization within the monetization framework.

4.1 Volume-Based Financial Activity

Definition:

Volume-based activity refers to economic interactions where value is generated per transaction or unit of volume processed. This includes cases where a protocol captures a fee, spread, or commission from each transfer or swap facilitated through WalletConnect.

Examples of volume-based contracts include:

• Swap or trading contracts in DEXs and aggregators
• Bridge contracts processing cross-chain transfers
• Payment and checkout contracts facilitating token settlements

Characteristics:

• Value scales with transaction count or total notional volume.
• Financial events are discrete — each transaction generates a measurable instance of economic activity.
• The network’s role is primarily execution and connectivity, enabling reliable message relays and transaction signing between wallets and applications.

Pricing Implication:

These activities are priced using the deterministic volume-based fee function, which calculates fees as a function of Total Network Volume (TNV). This ensures that contracts handling greater throughput — and thus generating higher transactional revenue — contribute proportionally to network sustainability.

4.2 Yield-Based Financial Activity

Definition:

Yield-based activity refers to financial interactions where value is generated continuously over time, through yield accrual, staking, or interest-bearing mechanisms. In these cases, WalletConnect facilitates not only deposits and withdrawals but also the ongoing management of time-dependent positions.

Examples of yield-based contracts include:

• Lending or borrowing contracts generating interest over time
• Staking and restaking contracts, distributing yield or rewards
• Liquidity vaults and structured-yield products

Characteristics:

• Revenue depends on time, rate, and balance, rather than transaction count.
• Value accrues continuously as yield or interest, realized only upon withdrawal or claim.
• The network’s role extends to lifecycle management — enabling recurring user interactions across deposit, harvest, and claim events.

Pricing Implication:

These activities are priced using a yield-based function, which considers the realized yield on a position. Fees accrue only when yield is withdrawn or realized, aligning network monetization with actual economic reward rather than nominal transaction flow.

4.3 Smart Contract–Level Categorization

Categorization is determined at the smart contract level, not the overall application level. This distinction ensures granular billing accuracy, allowing hybrid applications — such as those combining swaps and yield products — to be billed proportionally to their respective financial activities.

For instance:

• Swap or Bridge contracts are categorized under the volume-based model, applying the volume-based fee function.
• Staking or Lending contracts are categorized under the yield-based model, applying the yield-based function.

This structure prevents overgeneralization and ensures that each portion of an app’s ecosystem is billed according to its true economic purpose.

4.4 Certified App Program and Data Integrity

The WalletConnect Network leverages its Certified App Program to ensure high-quality data labelling and reliable categorization. Through this program:

• Applications undergo contract verification and audit to confirm ownership, purpose, and security.
• Verified smart contracts are tagged according to their financial activity type (volume-based or yield-based).
• These mappings are maintained within WalletConnect’s onchain and offchain registries, enabling precise classification at the transaction level.

This approach mirrors WalletConnect’s historical verification of URL domain ownership — extending the same rigor to smart contract validation.

As part of the certification process:

• Each app’s verified contract set must be declared and audited.
• Transactions routed through WalletConnect are automatically matched to their certified contract type.
• Multi-product applications (e.g., liquidity provision and swaps) are accurately disaggregated, ensuring each activity is billed under the correct fee model.

4.5 Evolution and Adaptability

As the onchain ecosystem evolves, new financial primitives and revenue models will emerge. The WalletConnect Network is designed to adapt dynamically — introducing new pricing mechanisms or refining existing ones to reflect these innovations.

This adaptability ensures that the protocol remains fair, competitive, and sustainable, regardless of how decentralized finance and application models continue to evolve.

5. Volume-Based Fee Function

The volume-based fee function applies to applications where transactional volume represents the main source of value creation — such as trading, bridging, or payments.

This model ensures predictable, value-aligned monetization for the majority of the ecosystem. Fees are determined by a continuous, non-linear function that dynamically adjusts based on each application’s recent economic activity.

This structure ensures fairness, scalability, and predictability — applications with higher sustained usage contribute more in absolute terms while benefiting from progressively lower effective rates.

5.1 Understanding TNV

Total Network Volume (TNV) is the core metric used to determine fees for volume-based applications. It captures the total economic value transmitted through the WalletConnect Network, representing the aggregate token value exchanged in transactions initiated by wallets during WalletConnect sessions. Each transaction hash collected through the Wallet SDK is analyzed, and the corresponding token transfers are parsed and summed to calculate TNV. This provides a reliable proxy for the financial activity facilitated between wallets and applications.

5.1.1 How TNV is Calculated

For each transaction initiated via a WalletConnect session:

1. Capture— The Wallet SDK collects transaction hashes generated during WalletConnect sessions.
2. Parse— Each transaction is programmatically analyzed to identify all token transfers on supported blockchains.
3. Evaluate— The inflows and outflows related to the initiating wallet address are summed.
4. Compute— The TNV for a transaction is defined as the maximum of the total inflow or outflow for the wallet.

$$ \operatorname{T N V}(w)=\operatorname*{m a x}\left(O(w),I(w)\right) $$

where:

• w is the wallet address,
• O(w) is the total outflow from w,
• I(w) is the total inflow to w.

This ensures that the captured value reflects the most significant directional flow of assets while avoiding artificial inflation from internal contracts hops.

5.1.2 Transaction Classification

Table 1: Transaction classification for TNV computation

For each case, TNV is defined as the maximum of inflow or outflow, ignoring contract-only transfers.

5.1.3 Examples

Table 2: Examples of TNV as max(O,I)

This approach makes TNV a universal, chain-agnostic metric for measuring WalletConnect-enabled financial activity.

5.2 Fee Function Definition

The daily effective rate for each application i on day d is defined as: $$ \begin{cases} \alpha\big(\operatorname{T N V}{i}^{(30)}(d)\big)^{\beta-1},&{\operatorname{T N V}{i}^{(30)}(d)\geq\tau,}
0,&{\operatorname{o t h e r w i s e}.}\ \end{cases} $$

The corresponding daily fee is calculated in USD:

$$ \mathrm{F e e}{i}^{\mathrm{U S D}}(d)=r{i}(d)\cdot\mathrm{T N V}_{i}(d) $$

where:

• α is a scaling factor defining overall revenue magnitude,
• β is an elasticity exponent controlling decay of the effective rate,
• τ is a billing threshold in USD,
• TNV_{i⁽³⁰⁾(d) is the rolling 30-day cumulative TNV for app i.}

At the end of each billing cycle, the accumulated USD-denominated fee can be settled in either USD-based stablecoins or WCT (conversion mechanics detailed in Section 7.1.1).

5.2.1 Threshold Parameter τ

Fees are only applied when an application’s rolling 30-day Total Network Volume exceeds τ. This threshold ensures that only projects contributing meaningful economic activity are billed, while smaller or early-stage applications remain exempt until they reach sufficient scale.

$$ \begin{cases} \alpha\left(\operatorname{T N V}{i}^{(30)}(d)\right)^{\beta-1},&{\operatorname{if}\operatorname{T N V}{i}^{(30)}(d)\geq\tau,}
0,&{\operatorname{if}\operatorname{T N V}_{i}^{(30)}(d)<\tau.}\ \end{cases} $$

5.2.2 Example Parameterization

For illustrative purposes, the following parameter set is used: $$ \alpha=0.0125,\quad\beta=0.65,\quad\tau=1, 000, 000. $$

For any application with $$ \operatorname{T N V}_{i}^{(30)}(d)\geq\tau. $$

is: $$ \regex{r_{i}(d)=0.0125\cdot\left(\mathrm{T N V}_{i}^{(30)}(d)\right)^{-0.35}} $$

5.2.3 Model Output

The table below illustrates sample effective rates and corresponding monthly fees for applications at different average 30-day TNV levels, using the parameter set: $$ \alpha=0.0125,\quad\beta=0.65,\quad\tau=1, 000, 000 $$

These values are derived from the power-law fee function: $$ R(D)=0.0125\cdot\bar{M}(d)^{0.65} $$

Table 3: Illustrative effective rates and approximate daily fees

These figures assume that each application’s rolling 30-day TNV remains constant throughout the month, producing a steady effective rate over the billing window. Under real network conditions, day-to-day TNV fluctuations would make total monthly fees path-dependent, but the values above serve as central estimates for a stable period.

5.2.4 Visual Analysis

Monthly Fee vs. Monthly Average TNV

A sublinear curve showing increasing fees with TNV growth, but diminishing marginal cost.

This chart illustrates the relationship between an application’s average monthly Total Network Volume (TNV) and the corresponding monthly fee generated by the pricing function.

Because the function follows a power-law curve with an exponent β-1<1, the fee increases with volume but at a decreasing rate — producing a smooth, concave shape that reflects economies of scale.

6. Yield-Based Fee Function

While the volume-based model effectively captures value for trading and transactional activity, it is not directly aligned with the economics of lending, staking, or other yield-generating protocols.

These protocols create value through interest or yield accrual over time, rather than from discrete deposits or withdrawals.

To reflect this, WalletConnect introduces a yield-based fee function that measures realized yield facilitated through the network — fees accrue only when gains are realized (withdrawn or claimed).

6.1 Realized Yield Definition

For each withdrawal or claim event j executed by application i: $$ \mathrm{Y i e l d}{i,j}=\operatorname*{m a x}(0,;V{i,j}^{\mathrm{o u t}}-P_{i,j}^{\mathrm{b a s i s}}) $$

$$ \mathrm{F e e}{i,j}^{\mathrm{U S D}}=\phi\cdot\mathrm{Y i e l d}{i,j} $$

Where:

• V_i,j is the USD-equivalent value withdrawn or claimed.
• P_i,j is the Cost basis of the withdrawn portion (weighted-average or pro-rata).
• ϕ is the WalletConnect fee multiplier (governable, bps-level).

No fee is charged if $$ V_{i,j}^{\mathrm{o u t}}\leq P_{i,j}^{\mathrm{b a s i s}} $$

6.2 Cost Basis and Partial Withdrawals

Each user position tracked through WalletConnect maintains a running weighted-average cost (WAC) — often referred to as the cost basis of the position. This cost basis represents how much capital has actually been contributed into a yield-generating position over time, accounting for multiple deposits, accrued yield, and withdrawals.

Maintaining a consistent cost basis ensures that fees are charged only on realized gains, never on principal or re-deposited funds.

6.3 Reference-Rate Fallback

If onchain realized yield cannot be directly determined, it may be approximated using a reference rate and duration d_i,j: $$ \operatorname{Y i e l d}{i,j}\approx R{\operatorname{r e f}}\cdot A_{i,j}\cdot\frac{d_{i,j}}{365}, $$

where:

• A_i,j is the USD value of the withdrawn position,
• R_ref is a governance-approved reference rate (e.g., onchain oracle or protocol APY),
• d_i,j is the holding duration in days.

The corresponding fee becomes: $$ \operatorname{F e e}{i,j}^{\operatorname{U S D}}=\phi\cdot A{i,j}\cdot R_{\operatorname{r e f}}\cdot\frac{d_{i,j}}{365} $$

7. Payment Mechanics and Enforcement

To operationalize the application-side monetization framework, this section outlines the fee collection model, billing flow, grace policies, and anti-abuse measures. The system is designed to be transparent, fair, and developer-friendly — while ensuring accountability for usage of the WalletConnect infrastructure.

7.1 Monthly Billing Model

WalletConnect bills applications on a monthly basis, while accruing fees daily according to the applicable pricing function defined in Sections 5 and 6 (either the volume-based model or the yield-based model for lending/yield protocols). This design aligns value extraction with network activity in real time while maintaining predictable, once-per-month settlement.

Each application’s daily fee is computed in USD, aggregated during the billing cycle, and settled at the end of the period.

8. Conclusion

The proposed monetization framework introduces sustainable, value-aligned fees for the WalletConnect Network while keeping end users fee-free. By combining TNV-based and yield-based models, WalletConnect can:

• Charge applications in proportion to the economic value they realize.
• Reward wallets and node operators from protocol revenue.
• Maintain governance control over key parameters and safeguards.

As network usage and financial primitives evolve, the fee functions and parameter choices can be refined via governance, but the core structure described here provides a clear and implementable starting point.