It's 2025...and channel creation is no longer the same on Push

It’s 2025...

The US elections are over, and Trump is back in office... Crypto is on a bull run..the screens are glowing green...the best minds are creating amazing web3 products...web3 is on its journey to onboard the next billion users.

You’ve just launched your new product, service, or newsletter as well. Good for you bud.

You realize you need a web3-specific way to communicate with your users. Naturally, you decide to create a channel on Push Protocol to start sending notifications directly to their wallet addresses.

You assume that since Push Protocol channels are on Ethereum, you'll need to convert your native L2 tokens to ETH.

But then, something catches your eye. 👀

You notice the Push dApp allows you to create a channel from any chain of your choice, using any token in your wallet.

You will be able to create any cross-chain request from any chain to Push Smart Contracts (on Ethereum), seamlessly.
No bridging, no waiting, no wasting of your precious tokens.

Yesterday I wrote a 2500-word long proposal for the Push Protocol community and it is one of the most significant proposals to date for the Push Smart Contracts.

Buckle up! Decipherers, today I’ll take you on a journey into the future of Push Protocol. 🚀

First Things First...

Before understanding why this research and proposal are significant, let’s quickly get the gist of where Push stands currently and what its history is.

For those who don’t know, Push is building the communication layer for Web3, using which any dApp, smart contract, or backend can send any real-time notifications that are tied directly to a user's wallet address (aka Web3 usernames).

To send notifications to your users using Push Protocol, one must create a channel. Creating a channel on Push means establishing yourself as a service that your users can choose to opt-in to and receive notifications/updates from you. Basically, similar to how YouTube channels and subscription works.

Push Protocol has smart contracts deployed on Ethereum and multiple EVM chains like Polygon, Arbitrum, BSC, Optimism, etc. These smart contracts play an important role in the Push Protocol’s architecture. These contracts allow the creation of channels, sending on-chain notifications, incentivization mechanisms, and so on.

In a nutshell, one must interact with these smart contracts for any imperative action like the creation of their channels, maintenance of their channel detail, etc.

How does Push Smart Contracts work today?

Push Smart Contracts are currently designed in the following way:

1. Push Core Contract:
   1. Deployed only on Ethereum.
   2. This is the main contract that handles all the imperative features like channel creation, incentivization mechanisms like staking, channel state changes, incentivized chat request functionalities, etc.
   3. Apart from features, the Push Core contract also includes the Protocol Fee Pool which stores the fees earned by the core smart contract via different actions. These fees are then used to incentivize token holders.
2. Push Communicator(Comm) Contract:
   1. Deployed on multiple EVM chains, this is a lightweight contract that primarily handles sendNotification features as well as channel alias-related functionalities.
   2. Push Comm contract being on multiple chains allows Push Protocol support notifications on any other chain.

Now that you understand the current state of Push, let’s get to the next stage.

So, What’s Wrong?

It should be noted that for all crucial functionalities related to the channels in Push Protocol, one must interact with the Push Core contract which is only deployed on the Ethereum chain.

This means a user must always switch to the Ethereum network for any important action related to their channel.

This leads to a bad user experience for existing or new users who want to interact with the Push Core contract. This strict requirement to only use one specific network is cumbersome, particularly for users who primarily operate on other EVM-compatible chains or even non-EVM users.

Additionally, this acts as a barrier to Push Protocol as well.

The strict reliance on Ethereum exclusively limits the Push Protocol's ability to tap into other chains and help solve the communication/notification issues of those chains adequately. This constraint hinders the protocol from reaching a broader audience and solving communication issues across diverse blockchain environments.

Why Not Deploy Push Core on Multiple EVM Chains?

An obvious solution that comes to mind to resolve this issue is, “Hey, why not deploy Push Core to multiple chains?”

While it does sound like a simple solution, it isn’t really.

Push Core contract includes a crucial component called the Fee Pool. Whenever any important action occurs in Push Core contract like the creation of a channel, updating an existing channel, reactivating/deactivating a channel, or creating an incentivized chat request, the contract charges fees from the user ( a small fee of 10 PUSH tokens).

These fees accumulated by the contract are stored in the FEE_POOL. This is a critical component because these accumulated fees are used as an incentivization mechanism and distributed among the Push Token holders.

In simpler terms, these rewards are directly linked to the protocol’s growth. As the protocol grows with more channels, so do the fees and hence incentives for Push Token holders.

Now, here is the issue with Push Core on multiple chains.

Multiple deployments of Push Core contracts indicate multiple fee pools on various chains which keeps increasing as Push starts to support more chains.

This leads to a difficult scenario of handling and syncing up multiple fee pools between all different chains. This will eventually affect the incentivization framework for token holders as well since it's tied to the fee pool of the Push Core contract.

In a nutshell, deploying multiple Push Core on different chains is not ideal, as it leads to significant modifications in the existing architecture, thereby making this implementation quite complex, less secure, and time-consuming.

The Problem Statement

Considering all the above details, here is the final problem statement:

1. Enhance the user experience (UX) for both existing and new users of Push Protocol when interacting with the Push Core smart contract.
2. Reduce the strict dependency of Push Smart contracts on the Ethereum chain.
3. The solution should prioritize security and minimize extreme disruptions to the existing architecture.
4. And, Push Core cannot be deployed on multiple chains.

So, how do we solve it?

Enter, Cross Chain Request feature ( CCR )

Now, we come to the exciting part, the CCR feature.

The Cross Chain Requests ( CCR) feature will enable users to perform important actions like channel creation, creation of Incentivized Chat requests, or any arbitrary request from the chain of their choice.

In other words, users would no longer need to switch their network to Ethereum to interact with the Push Core contract. Instead, they can remain on their favorite chains and still be able to interact with the Core contract seamlessly and perform the required actions.

The core idea of the CCR feature is to make Push smart contracts capable of handling requests that can originate from any chain and are securely relayed to Push Core contracts on Ethereum for necessary validations & state changes.

Implementation Proposal of CCR

Here is how we proposed the implementation of the CCR feature for Push Smart Contracts.

It's quite clear that deploying Push Core on multiple chains is not a solution. Therefore, the best way forward seems to be:

1. Leveraging Wormhole’s NTT Framework & Relayers
2. Leveraging Push Communicator’s Multi-Chain Presence

Let’s quickly explore each one:

1. Wormhole’s NTT Framework & Relayers

The idea of CCR is to be able to relay messages ( or tokens ) from Push Comm contract on any chain to Ethereum. This means we would need a cross-chain network that allows us securely relay our messages and tokens from Comm to Core.

In order to achieve this feature, we currently propose using Wormhole’s NTT architecture and Relayers. However, this might change in the future as new features of Push are realized.

Mentioned below are some of the important reasons why we chose Wormhole for this feature:

• Wormhole’s NTT Framework for Token Bridging:
  1. Wormhole’s NTT framework is best suited for us as it allows us to use our existing Push Token with its framework seamlessly.
  2. Most importantly, with NTT we will be able to retain ownership, upgrade authority, and customizability over our token as NTT framework can integrate with any token contract or standard and any protocol governance processes.
• Support for EVM & Non-EVM Chains:
  • Push Communicator contract is essentially designed to be deployed on all chains.
  • Wormhole’s wide range of support for EVM/non-EVM chains aligns very well with the eventual vision of Push Communicator contracts
• Secure and Battle-Test bridging network:
  • Since security is of utmost importance to us, we believe Wormhole is a battle-tested network for relaying tokens or arbitrary messages between chains.

2. Push Communicator’s Multi-Chain Presence

Now, coming to how we can leverage Push Communicator contract.

As previously mentioned, the Push Comm smart contract was designed to be a lightweight and stand-alone smart contract that can be deployed on multiple chains easily.

This is an added advantage that we already have which reduces the complexity of implementing the CCR feature. Since Push Comm is already deployed on multiple EVM-compatible chains ( and soon non-EVM chains), it already resolves the first concern of expanding the smart contracts to multiple chains.

The next step would be the Implementation of the Cross Chain Request feature in already existing Push Comm contracts.

This means we must include the following changes in the existing smart contracts:

1. Required Modifications in Push Communicator Contract
   • Accepting Message Payloads from Users:
     • The first step allows users to pass the payload which could be token value or messages ( or both together ) that must be bridged to the Push Core contract to trigger a specific action.
     • For instance: passing 50 push and channel details as payload to create channel on Push Core on Ethereum chain.
   • Validation of Message Payloads:
     • Push Comm must also validate the message payloads by user is adequate.
   • Relaying of the Message Payload:
     • Once validated, the final step is to bridge this payload to the Push Core contract securely.
2. Required Modifications in Push Core Contract:
   • Inclusion of receiveWormholeMessages():
     • This is a required function for the Core contract to be able to receive, decode as well as process the incoming payloads.
   • Adjustments in existing functionalities:
     • Additionally, the core contract also needs to include modifications in the existing functions to ensure they are compatible for handling cross-chain requests.

So, What does the Future of Channel Creation look like?

1. Bob is a native Polygon user and has a Polygon-PUSH token in his wallet. He wants to create a channel and start sending notifications.
2. Instead of bridging $PUSH tokens from Polygon to Ethereum and changing the network, BOB simply goes to the existing Push Communicator contract on Polygon.
3. With the Cross Chain Request feature enabled, the Push Comm contract has a function called createChannel()
4. BOB calls this function and provides the details of his channel, i.e., channel’s name, description, type, etc.
5. Channel creation also requires 50 PUSH, so BOB also approves 50 PUSH tokens to be used by Push Comm.
6. Along with this 50 PUSH, BOB also sends some native tokens ( i.e., MATIC, in this case) for the transaction to be submitted. It should be noted that any unused Matic shall be refunded to BOB.
7. Once the transaction is submitted, the _createChannel() function on Push Comm shall perform the following actions:
   1. Validates the provided input and token value by BOB is valid.
   2. Creates a payload of the provided input. ( this payload will eventually be bridged to Core )
   3. Once created, it uses Wormhole Relayers to relay the arbitrary data( payload containing details about the channel being created) to Push Core on Ethereum.
   4. Then, it uses Wormhole’s NTT framework to bridge the 50 PUSH tokens from Push Comm ( polygon ) to Push Core ( eth ).
8. The completion of this step shall indicate that BOB’s request to create a channel has been successfully accepted and relayed to the Push Core contract.
9. The last step required is for the Push Core contract to be able to handle this incoming cross-chain request.
10. Once Wormhole relayers bridge the tokens and message payload to the Push Core on Ethereum, the Core contract performs the following actions:
    1. Decodes the incoming payload.
    2. Checks and validates the type of request contained by the payload, i.e., channel creation request in this case.
    3. It then uses the payload data to call the actual _createChannel() function on Push Core, updates the state of the Core contract and thus, successfully completes the request from BOB.
11. As soon as this transaction gets executed, BOB ends up having a channel successfully created on Push Core on Ethereum without ever having to leave the Polygon chain.

Alright decipherers,

Hope you got a good glimpse of what the future of channel creations might look like for Push Protocol.

I will be back soon with more updates on this.

And expect more articles on Cross-Chain soon.

Until Next time.