This is Part 2 of the AOM series. In the first part, we discuss the fundamentals of The actor-oriented model.

In this part, we will discuss the Lifecycle of Actors and Communication b/w Actors.

Lifecycle of Actors

In the AOM, Actors can create other actors. This brings in the parent-child hierarchy and contributes to the scalable model.

Child Actor Properties

As explained before, every actor is isolated, i.e., they have their own memory, state management, and message queue. This also applies to child actors. So, when a parent actor creates a child actor, the child actor will have a separate state, memory, and message queue from the parent actor.

Having separate state management, memory, and message queues helps create highly efficient and scalable network models. For example, a parent actor can create a separate child actor for each function, and since the child actor has the same properties as other actors, all the child actors (and their respective functions) can be executed simultaneously, creating high-speed computation.

Parent-Child Actor Relationship

In a parent-child relationship, parents have some supervision over their child, and the same is implemented in the parent-child actors. Parent actors can supervise child actors using different strategies for different conditions.

Parent actors can manage the lifecycle of child actors, including

• creation,

• monitoring,

• restarting,

• and termination.

For example, If a child actor gets into a deadlock, the parent actor can restart or terminate that child actor.

Communication b/w actors

The only way for an actor to communicate with another actor is by using the messages.

For Example:

If actor2 wants to get a value of a variable count from actor1, they will need to go through the following process of message passing:

1. The actor2 will send a message to actor1 to get the count value.

2. The actor1 will receive the message, process the message and send a message, including the count value, back to actor2.

The following are the key characteristics of the message passing:

• Asynchronous Communication

• Message Queue

• Message Immutability

• Message Processing

• Message Handling and Context Switching

• Fault Tolerance and Error Handling

Let's understand each of them.

Asynchronous Communication

When an actor(sender) sends a message to another actor(receiver), they can execute the remaining code without waiting for a reply. This removes the sender's dependency on the receiver; now, both can work simultaneously.

Message Queue

When a message is sent, it is wrapped in an envelope and placed in the receiver's message queue.

Each actor has a dedicated message queue where incoming messages are stored until the actor processes them.

Message Immutability

After sending a message, the message and its content can't be changed. This ensures the consistency of the system and prevents any side effects that might occur due to this.

Message Processing Loop

Every Actor has an event loop that keeps looking for the new message received in the message queue.

When a new message is found, the following happens:

1. The message gets dequeued from the message queue.

2. The corresponding handler function is then called for the message in the actor.

This ensures that the actor processes only one message at a time and maintains a single-threaded execution model, i.e., a message starts processing after the previous message is being processed completely.

Message Handling

When a message is dequeued from the message queue, the actor's message handlers are invoked to handle it.

The handler's invocation may update the actor's current state (like changing the variable values), send new messages (a response back to the sender), or create child actors (new actors to distribute the computation).

Fault Tolerance and Error Handling

If an actor encounters an error while processing a message, the actor system or the parent actor can manage the actor according to the defined supervision strategy.

For example:

If an actor encounters an error while processing a message, the actor system will detect the error. Depending on the supervision strategy, the actor system or the parent actor can restart or terminate the actor or report this error to a higher level in the hierarchy.

Thanks for reading! If you have any queries, feel free to DM 🫡

Feedback is always appreciated 🙌🏻

Keep Building (🧱, 🚀)

Using AOM, developers can build highly scalable distributed networks that have the potential to grow and improve the efficiency of different technologies, like blockchain, as they scale.

The AOM series will help you to understand the core concepts of AOM.

LFG (🧱.🚀)

Objectives

• Understand the principles of AOM

What is an Actor?

Actor is the basic unit of computation of the AOM.

• It is autonomous,

• it can execute concurrently with other actors,

• and can only communicate through message passing with other actors.

Being autonomous enables the actor to have its own state management, which is not shared with other actors.

Since the state is not shared with other actors, no actor is required to wait for the execution of other actors, enabling the parallel execution of multiple actors simultaneously.

If the actors want to communicate with other actors, they need to use message-passing flow, which is the only method for actors to communicate with each other.

You can imagine an actor as a piece of code with its own class and variables and is not dependent on the variables or classes of other code to get executed. If an actor (actor2) wants to read any variable, the source actor (actor1) will execute a separate function to send a message with the requested data.

State Management

Every actor has its own state, which means its own memory that is not linked to other actors.

This enables actors to execute without any external requirement outside of their scope.

Concurrency

As the actors are independent in both their computation limits and state management, multiple actors can be executed simultaneously.

This enables parallel computation, bringing high scalability to the applications.

Message Passing

Complex applications require communications to share data between different computation units (or actors, in this case). Message passing among the actors makes this possible.

Example:

An actor (actor1) wants to know the state of the variable price in another actor (actor2). To do this, actor1 will first send a message to actor2 with the request. Actor2 will compute the message request and then create another message with the state of the variable price to actor1.

As per the AOM,

• messages are immutable, meaning they cannot be changed once created.

• actors can process only one message at a time.

That's it for Part 1. (I know it's really short, but I will increase the depth progressively.)

Thanks for reading!

Any feedback is appreciated 🙌🏻

Keep Building (🧱,🚀)

Recently, I have been studying about Tokenomics. I came across a "Fair Launch" by AO during my study. AO is the Hyper Parallel Computational layer built on top of Arweave, and a few days back, they had their Token Generate Event (TGE).

The exciting part about AO Tokenomics is its stakeholders.

The stakeholders include ONLY THE COMMUNITY. However, the team is confident that the Ecosystem Development will go smoothly.

I am intrigued by how this will work for the core AO dev team, ecosystem projects on AO, for stakeholders in Arweave, and for general community members. So, I sat one night and read the latest draft on AO.

Here are some of my critical findings about AO tokenomics. I hope you find something useful.

LFG 💪🏻

Total Supply

Fundamentals of Bitcoin inspire AO Tokenomics.

There can only be a 21M supply of AO tokens like Bitcoin. These tokens will be minted over the years with 4 year smooth-halving.

Circulating Supply

The method of circulation is genuinely fascinating.

The AO tokens were minted every 5 minutes from the launch of the AO network on February 27th, 2024.

Minting new tokens every 5 minutes accumulated to 1.425% monthly of the remaining supply. Minting like this is equivalent to 4 years of halving like Bitcoin, but instead of doing it abruptly, it's done in a flow.

A small visual to get it into the perspective:

Distribution

AO is built on Arweave, the permanent data storage network, which provides economic security to AO, the computation layer, and permanent storage and validation for all the messages passed on AO in a truly decentralised manner. This is only possible because of $AR, the native token on Arweave.

This brings two types of participants who can earn AO during the minting period.

1. $AR Holders

2. Users who bridge the assets

$AR Holders

As mentioned above, the AO was minted from the network launch on 27 February. In four months, this accumulated to more than 1M $AO, distributed proportionately among AR holders.

Further, to continue incentivising the Arweave Community (including miners), 1/3rd of the newly minted AO will be distributed to $AR holders.

Bridged Assets

Users can bridge assets from other networks to AO networks to contribute to the economic security of their network.

Users are highly incentivised to bridge their assets from other networks to AO.

• First, they can use (not right now) the bridged assets in the wide varieties of applications on AO and

• Second, they will mint AO.

After bridging assets like stETH, users will earn 2/3rd of newly minted AO tokens proportionately.

The bridging is divided into phases.

• Currently, phase 1 is in process, during which you can deposit stETH from Ethereum Mainnet to the AO network and mint AO but cannot use stETH in the AO Network.

• In the coming phases, the stETH will be available within the AO Network while minting AO for the users.

Ecosystem Growth

The above sections explain how the AO will be distributed to 100% of the community.

This raises the question of how the development of different projects on AO and the AO itself will be sustained. The answer is Bridged Assets.

As per the AO's latest paper, ecosystem growth is divided into two parts:

• Permissionless Ecosystem Funding

• Permaweb Ecosystem Development Guild (PEDG)

Permissionless Ecosystem Funding

The idea of permissionless ecosystem funding is really simple. The community will support the projects in their development and provide potential revenue.

Community members can interact with applications using their bridged assets. When the team receives these bridged assets, projects can earn AO with the proportionate liquidity they can gather from the community, providing the team with sufficient funds for development. This makes the whole process permissionless and removes the requirement for grants to keep building.

Permaweb Ecosystem Development Guild

The PEDG includes six core teams that contribute to the development and maintenance of AO. These teams are funded by the native yield of the bridged assets, like stETH on Ethereum Mainnet.

Thanks for reading!

Any feedback is appreciated 🙌🏻

Keep Building (🧱,🚀)

You can please some of the people all of the time, you can please all of the people some of the time, but you can’t please all of the people all of the time. - John Lydgate

In Web3, space protocols try to deliver the best possible airdrop. Now, every protocol has a different definition of "best." Some think that providing a good share to the community is best, some believe that keeping the investors happy is best, some say giving it to all is best, and some say let's do it and think of the consequences later is best.

Indeed, every one of them has their reasons. We (or at least I) are no one to say why you did this, or you should have done this because we ( or at least I) are here to bring revolution to the internet, not ONLY for the money 🙂

My recent foray into tokenomics has been an enlightening journey, one that will equip me to build my own in the future. This created a Frequency Illusion, and I started noticing the "Fair Launch" which AO did a few days back.

My inspiration for this blog came from a recent 'Fair Launch' I observed and the subsequent discussions and insights shared by various community members. This led me to jot down the most crucial factors a protocol should consider before embarking on an airdrop.

Let's dive in 🏊‍♂️

Community

Protocols excel in their tech, but only with their community to support them.

The community members contributed to the protocol without self-interest and because they believed in the product.

Protocols should define before their airdrop what type of community members will be rewarded for their contributions.

Early Contributors

Every protocol now was (in many cases is) a startup.

A startup is a new venture with a small, motivated team focused on innovation and rapid growth.

Rewarding the team who helped you reach the airdrop is something that every protocol should do in one way or another.

Early contributors can also include the computer geek lying on his mattress and creating valuable PR to make your protocol more efficient, secure, or understandable. They can also include a few of your advisors who are not technically on your team but have always reviewed your codebase, pitches, designs, etc.

But it should be clear to both you (as a protocol) and them (as a contributor) that the protocol should not be liable for this. Contributions can be considered volunteered work if tokenomics are not in favor (which I can't think of the case why they wouldn't).

Sybil Resistance

Sybil attacks exploit the network by using multiple fake identities.

It's no news that the crypto space is filled with Airdrop hunters. I also tried and failed miserably.

These airdrop hunters include some college students who got a taste of money, some serious hackers running bots at once to get qualified, and others.

Many protocols use several ways to avoid this, and that's great. Giving the airdrop to these hunters is discouraging for other community members.

Criteria

Every protocol needs to define criteria when they are approaching the airdrop.

This is mainly done when the "Check Eligibility" site goes live, which is the clean way.

You define the criteria after taking the snapshots = You avoid many bots and hunters already.

However, I have seen many protocols announce their criteria for upcoming airdrops to bring in more liquidity. This works, but again, it shifts the focus from the community and building the future to filling one's pockets. Adopting this has made several airdrops worthless to both airdrop hunters and genuine community members.

Allocation of Tokens

I guess this is the most important point of all. The protocol founders should always consider this before raising funds.

In the crypto space, many protocols with even great tech are required to raise funds to keep building before going to the mainnet due to the niche category from where they need to hire and the infrastructure cost they have to bear in the starting at least. In most cases, raising funds comes at the cost of allocating tokens to investors. Though these allocations have vested periods to prevent the spike in the circulating supply of tokens (or dumping of tokens), issues arise with this.

I know and understand two of them:

• Suppose the token distribution aligns with the community (releasing most tokens to the community). In that case, it dramatically impacts the token price, affecting investors' portfolios and making them unhappy.

• Suppose the token distribution is aligned towards generic distribution (or some other term). In that case, the distribution of tokens to the community can be halted in several ways. One is making the token non-transferrable for some period. This safeguards the investor's portfolio, but community members lose interest because they genuinely believe in the product and don't want to be treated like that or because they are airdrop hunters who trade 24 hours to make money.

There are many other reasons why token allocation should be considered from the start by the founders and the team if they are sure that they will be holding the token.

Eligibility Check

Use Excel.

This is what the community wants. Community members just want to know whether they are eligible. There shouldn't be any reason they need to connect their wallets and sign a transaction.

The approach of connecting a wallet and signing the transaction only motivates scammers to build clones and harm others. Many incidents have already happened where members sign malicious transactions in the belief of the product and the team and get caught in severe scams. Making community members connect their wallets should be avoided as much as possible.

Preparation for Distribution

The distribution phase of the token is done in several ways a few of them are:

• directly sending allocated funds to the wallet.

• making the user sign a transaction.

• making the user sign a transaction and connecting their socials to claim the tokens. (this helps in avoiding sybil attacks)

Whichever method the protocol chooses, they should be ready with clear definitions and guidelines for claiming the token in the form of a post on X or a blog. This helps prevent(up to an extent) users from visiting phishing sites and getting scammed.

Protocols should also consider the following points:

• The claim site should be able to handle high traffic.

• The network on which they are distributing the token should not get bottlenecked

• Deleting the scam links from the comments on socials (can help, but it is a tedious process)

These were my 2 cents on the Fair Launch.

Let me know your thoughts on the above points by simply DMing me.

Thanks for reading!

Keep Building (🧱,🚀)

• Twitter @megabyte0x

• GitHub @megabyte0x

• Email contact@megabyte0x.xyz

• Farcaster | Lens

It's been a great journey so far with The Graph Protocol on Ethereum but to scale and to provide the benefits of its services to everyone The Graph Protocol is now shifting to Arbitrum One.

With this shift, many changes are coming for the community members, one of them is for Delegators.

If you are already a Delegator on the Ethereum Mainnet Network, head to this tutorial to shift your delegated GRT from Ethereum Mainnet to Arbitrum:

https://yasshhh.hashnode.dev/a-guide-to-seamlessly-transferring-delegation-from-ethereum-mainnet-to-arbitrum

But before going through the whole process it's better to know about Delegators and things to consider before delegating.

Now LFG!!!!!!!🚀🚀🚀🚀🚀

WHO participates in Delegating?

People who delegate(or stake) are known as Delegators, and...

Delegators are network participants who stake GRT to one or more Indexers.

To learn about all the participants in The Graph Protocol, check this out:

https://twitter.com/megabyte0x/status/1689630196427812864?s=20

Many community members are not able to run their own Graph Node because it requires high technical skills and resources, but they can still contribute to the security of the network by being a Delegator. They don't need to run their node and contribute to the security by staking GRT.

BENEFITS from Delegating

Upon staking or DELEGATING, they

• earn fees by the cut from the Indexers' query Fees.

• Contribute to the security of the network.

things to CONSIDER before Delegating

There are several things one should consider before starting delegating:

• Delegation Tax

  When you delegate GRT, 0.5% of the total gets burned.

  For Example:

  When you stake 100 GRT, 0.5 GRT will be burned.

  This brings a bit of calculation to estimate the amount of time you need to wait to get back the Delegation Tax amount as a Reward Amount from the Indexer.

• Unbounding Period

  If you want to undelegate (unstake) your GRT you will be required to wait for 28 days. During these 28 days, your GRT will be locked and earning NO REWARDS.

• Trustworthy Indexer

  This is the most important thing to consider. YOU NEED TO CHOOSE YOUR INDEXER VERY WISELY.

  There are two values you should look out for:

  • Indexing Rewards Cut: This value states the % of the rewards INDEXER will be keeping.

    For Example:

    If the Indexing Rewards Cut is 80% that means INDEXER will be keeping 80% of the reward, and DELEGATOR(YOU) will be getting 20% of the reward.

  • Query Fee Cut: This works exactly like the Indexing Rewards Cut ☝🏻 but there's one more thing to consider, Query Fee Rewards increase with time based upon the activity of the network.

    Keep an eye on the network activity, more activity means more query rewards means more Query Fee Cut Rewards.

You can calculate your approximate rewards using the below formulas for getting the most out of the Indexers:

• Indexer Delegation Pool

  Every delegator owns the number of shares proportional to the GRT they delegated into the pool.

  It's simple math, the more share you own more rewards you will be collecting than others.

  

• Considering the delegation capacity

  Currently, the Delegation Ratio is set to 16, which means if the Indexer has staked 1M GRT then the max capacity is 16M GRT.

  Butttttt.... if users staked in a total of 18M GRT to this indexer, then the extra 2M (18M-16M) GRT will not be used for earning rewards.

oooooofff...😮‍💨 a lot of things to CONSIDERRRRR....😩

but remember: "Hard💪🏻 stuff brings the best rewards."

Let's have some action now!!

actually DELEGATING!

Now let's play with some GRT Tokens...

prerequisites

• GRT either on Ethereum Mainnet or Arbitrum One

• Native ETH on Arbitrum One.

• Calculator 😂 (It's for you I am good at math 😏)

getting GRT on ARB

if you have GRT on ARB already, congrats! You are one step ahead and can move to the next section.

For those who don't have GRT on ARB, let's experience some true web3 UX 😜

bridging ETH from Ethereum Mainnet to Arbitrum One

To get your GRT from Ethereum Mainnet to Arbitrum One you need to bridge it, and for that follow the steps:

1. Head to the Official Arbitrum Bridge (https://bridge.arbitrum.io/)

   

2. Connect your wallet and select GRT, Ethereum Mainnet (FROM) and Arbitrum ONE (TO).

   

3. Enter the amount of GRT you want to bridge.

4. Click on "Move funds to Arbitrum One" and approve and confirm the transaction.

5. Now wait!!!

After tremendous anxiety full waiting, you are ready to delegate.

choosing and analyzing the INDEXER

To earn with full potential Indexers need to be transparent and honest, this will help you and other Delegators in analyzing and calculating their true rewards.

Follow these steps:

• Head to Indexers on Arbitrum Network in the Graph Explorer (https://thegraph.com/explorer/participants/indexers?chain=arbitrum-one)

  

• Connect your wallet and sign in to The Graph Explorer.

• 1st thing to consider is to choose an Indexer from both tech and non-technical perspectives.

  ⚠

  NOTE: I am choosing some random. [YOU ARE NOT AT ALL ADVISED TO CHOOSE THE SAME]

  

• Analyzing the factors:

  From the above image, we have the following parameters:

  Max Capacity: 3.4M and Delegation Received: 1.6M

  This means only 1.8M [3.4-1.6] tokens will earn rewards.
  Indexing Reward Cut: 27%

  This means you [Delegators] will receive only 73% of the Indexing Reward.
  Query Fee Cut: 80%

  This means you [Delegators] will receive only 20% of the Query Fee Reward.

final steps!!

I am fine with the amount I'll be receiving, so I'll be following these steps:

• click on "Delegate"

• enter the amount of GRT I want to delegate(stake), i.e., 1000.

• grant Access to the GRT tokens

• hit "DELEGATE"

Congrats 🥳🥳🥳 You have Delegated GRT and now you are contributing to the security💪🏻 of the network while earning rewards!💰!

You can see your delegated amount and other details by clicking on your profile and selecting the delegating tab.

References

• Graph Docs

• Graph Explorer

If you learned something from this blog, do consider sharing your learnings with me through DM either on Twitter or LinkedIn or Lenster.

To keep learning about The Graph Protocol join me with The Graph Protocol India.

Happy Learning 🙌🏻

Keep BUIDLing 🧱🚀

Indexing Blockchain Data is really really hard and indexing transactions of something like Uniswap is a lethal task. But The Graph Protocol greatly reduces the complexity of this.

We will be learning how to build, deploy, and play with Subgraph for a simple Token Swapping Contract.

The following are the prerequisites for this tutorial:

• Basic Solidity and GraphQL understanding.

• Yarn

• Remix

• VS Code

Building the Token Swap Contract

This is the Token Swap Contract we will be using for our example.

The following are the main functions we will be focusing on in our subgraph:

• addLiquidity(uint256 _tokenAmount): This adds liquidity to the pool and emits GraphKitExchange__LiquidityAdded event.

• removeLiquidity(uint256 _amount): This removes liquidity from the pool and emits GraphKitExchange__LiquidityRemoved event.

• ethToTokenSwap(uint256 _minTokens): This swaps ETH to the Token and emits GraphKitExchange__ETHToTokenSwap event.

• tokenToETHSwap(uint256 tokenSold, uint256 minTokens): This swaps Token to ETH and emits GraphKitExchange__TokenToETHSwap event.

Having these above events is important as the Graph Nodes will be listening to these events and storing the data (defined in schema) as it gets emitted.

This is the Basic ERC20 Contract we will be using:

Deploy the Contracts

Now deploy these contracts using Remix on Polygon Munbai Testnet.

Head to your Remix IDE and follow the steps:

1. Connect with the Injected Provider and select Polygon Mumbai Testnet as the network.

2. Get some TEST MATIC on Mumbai Testnet from the Faucet, here.

3. Deploy Token.sol

   1. Copy the above contract and paste it into the Remix file.

   2. Then select the contract and enter the constructor parameters. I have entered MEGABYTE,MB and 100000000000000000000

   3. Hit Transact.

1. Copy the above GraphKitExchange code and paste the content of GraphKitExchange.sol in the Remix File.

2. Copy the Token.sol Contract Address

   

3. Select the GraphKitExchange.sol, paste the Token Contract Address, and hit Transact.

   

4. Verify the contracts on the Mumbai Scan

   Learn how to do it here.

5. Keep both the contract addresses handy, we will be using them shortly.

   Here are mine though:
   Token Contract: 0xB2887fA56b2601cB5877A99188c3f23731F671F5

   Exchange Contract: 0xd8F178e60F3A7434F0F4E2519e6C2B89575f8123

Congrats your contracts are ready 🔥

Let's deploy the Subgraph for the same 🚀

Build the Subgraph

To build the Subgraph, these are the steps that need to be followed:

• Create a Subgraph on Subgraph Studio.

• Install the Graph Protocol CLI

• Initialize your Subgraph⁠

• Deploying a Subgraph to Subgraph Studio

Before building the subgraph, if you wanna revisit the concepts of Subgraph check this out 👇🏻

https://twitter.com/megabyte0x/status/1689177201147805696

Create a subgraph on Subgraph Studio

1. Head to https://thegraph.com/studio

2. Create Subgraph on Polygon Mumbai Testnet

1. Keep the Subgraph Slug and Deploy Key handy.

Install the Graph Protocol CLI

You need to install graph-cli to use the Subgraph Studio from your system.

Follow the steps for installing it:

1. Open up your terminal.

2. Paste the following command and hit ENTER:

    yarn global add @graphprotocol/graph-cli
   

Initialize your Subgraph⁠

It's time to start working on your Subgraph:

1. Create a new directory.

   mkdir tokenSwapSubgraph

2. Initialize the subgraph [Paste your subgraph slug]

   graph init --studio <SUBGRAPH_SLUG>

3. Choose ethereum as the protocol

4. Enter the subgraph slug name

5. Name the directory.

6. Select mumbai as the Ethereum Network

7. Enter the Contract Address for GraphKitExchange.sol contract.

8. Use the default start block.

9. Enter the name of the contract, here is GraphKitExchange

10. Select true for the index contract event as entities

11. Type y for entering a new contract address (for Token.sol)

12. Type n for providing local ABI path.

13. Enter the name of the contract, here is Token

Here's how it will look in your terminal 👇🏻

1. Go to your subgraph directory

   cd graphkitexchange

   In the directory, you can see the following files:

   

   In the src directory you will see that it auto-generated the mappings for your subgraph as per the events in your contracts.

   

Your Subgraph is ready now. It's time to deploy it.

Deploy the Subgraph

We are almost done! Let's deploy our subgraph.

1. Authenticate your Graph Studio Key [Get Deploy Key from your subgraph studio]

    graph auth --studio <DEPLOY KEY>
   

2. Deploy your subgraph with your subgraph slug

    graph deploy --studio graphkitexchange
   

3. Enter the v0.0.1 as the version for your subgraph

4. In the end, you will see this 👇🏻

   

   Here you got the subgraph endpoint, https://api.studio.thegraph.com/query/48418/graphkitexchange/v0.0.1

Whoo!!! That's a lot of work! But congrats 🤩 You deployed your subgraph for a Token Swapping Contract.

Play with the Subgraph using Subgraph Studio

So, it's time to use a decentralized, most effective and inexpensive way of querying the blockchain data.

I'll be using a Subgraph Playground for the same. [Not a frontend dev... hehe]

Creating Txn on the contracts

Before using the subgraph we need to create some transactions so we can query them.

Follow the steps to approve GraphKitExchange's contract address on Token Contract.

1. Open your Token.sol contract on Mumbai Scan, and head towards the Contract Tab. Here's mine.

2. Click on the Write tab below Contract tab. Since you have already verified the contract, you will be able to Write transactions on it using the Etherscan UI.

3. Connect your Metamask with the Etherscan by clicking on Connect to Web3

4. Now head to the approve function and open the modal.

5. Enter the address of the GraphKitExchange contract address and the amount in wei

   

6. Click on Write and confirm the transaction.

Follow these steps to create your first transaction on the GraphKitExchange Contract:

1. Open your GraphKitExchange.sol contract on Mumbai Scan, and head towards the Contract Tab. Here's mine.

2. Click on the Write tab below Contract tab. Since you have already verified the contract, you will be able to Write transactions on it using the Etherscan UI.

3. Connect your Metamask with the Etherscan by clicking on Connect to Web3

4. Click on addLiquidity and enter the 5 Matic and 5 MB (in wei) into the respective fields.

   

5. Click on Write and confirm the transaction.

6. You will see a View Transaction button, click on it and copy the transaction hash

Voila! We are good to go with our subgraph.

Querying the Subgraph

Now we have a transaction ready in your GraphKitExchange Contract waiting to be queried by us.

Let's do this, by following these steps:

1. Head to your deployed Subgraph and select the playground. Mine is https://thegraph.com/studio/subgraph/graphkitexchange/playground

   

2. Now paste this into the query

    query MyQuery {
      graphKitExchangeLiquidityAddeds 
    (where: {transactionHash: "Your Transaction Hash"}){
        _ethAmount
        _lpAmount
        _tokenAmount
        _user
      }
    }
   

   💢

   In "Your Transaction Hash" be sensible and paste your transaction hash 😂

   

3. Now click on that YOUTUBE PLAY BUTTON

   

   As you can see on the right side we got this 👇🏻

    {
      "data": {
        "graphKitExchangeLiquidityAddeds": 
          [{
            "_ethAmount": "5000000000000000000",
            "_lpAmount": "5000000000000000000",
            "_tokenAmount": "5000000000000000000",
            "_user": "0x1cb30cb181d7854f91c2410bd037e6f42130e860"
          }]
        }
    }
   

   It has the same data we emitted in our GraphKitExchange__LiquidityAdded but we didn't require to have the node setup or to some centralised node provided for this query.

   Querying with The Graph Protocol is superfast, decentralized and inexpensive.

4. TASK: Use the rest of the functions and query the subgraph for the events they emit.

Reference Links

• Uniswap Book [V1 Part -1]

• Uniswap Book [V1 Part -2]

• Uniswap Book [V1 Part -3]

• Graph Docs

I hope you have learned something today with this quite long blog.

If you have any queries, DM me on Twitter, Lenster or LinkedIn.

Happy Learning 🙌🏻

Keep Building 🧱🚀

In this tutorial, we will learn how to deploy Hyperlane on Polygon zkEVM Testnet, Polygon Mumbai Testnet and Sepolia.

There are 5 steps we need to follow so LFG🚀

Prerequisites

• Yarn

• Git and GitHub Knowledge

• Understanding of Blockchain

• Solidity Experience (BONUS)

Before moving forward, if you like to understand Hyperlane in-depth (which you should!) check this out:

https://blog.megabyte0x.xyz/a-z-of-hyperlane

Setup Keys

When you deploy Hyperlane Protocol it includes Smart Contracts, Validators and Relayers therefore we will be requiring Key Pair for each of them.

Keys for Deployment

To deploy smart contracts you will need to have a key pair with the funds for all the chains you will be deploying.

To create the key pair, follow the steps:

• Open your Terminal and enter the following command

    cast wallet new
  

  This will generate a new key pair for you, which will look like this 👇🏻

  

  ⚠

  THIS IS A TESTING WALLET.

• Save your Public Address and Private Key.

• Fund your Address with the tokens of all the networks.

  • For ETH on Polygon zkEVM Testnet and Polygon Mumbai Testnet use Polygon Faucet.

  • For ETH on Sepolia use Alchemy Faucet.

Keys for Validators

For this tutorial, we will be using the default Hyperlane's Multisig ISM. Multisig ISM is a module that takes several signatures from validators before completing the transaction. Therefore, we will be using 4 addresses with threshold one.

You can take any 4 of your Public Addresses, and keep them handy for later use.

Make sure to have a Private Key secured for the Public addresses you will be using.
You can generate Key Pairs using the above method.

Setting up the Repo

The Hyperlane Core team provided us with a repository that you can use to deploy Hyperlane on your preferred chain.

Follow these steps to set up the Hyperlane Deployment repo:

• Open your terminal at your preferred directory.

•     git clone https://github.com/hyperlane-xyz/hyperlane-deploy.git
  

•     cd hyperlane-deploy
  

•     yarn install
  

Adding the custom chain

Hyperlane's core team has provided a few chains in the SDK. You can check them out here.

To add a chain apart from the provided chains, follow these steps:

• Open config/chains.ts There you will find the configuration example for adding new chains.

• Add the following configuration for the Polygon zkEVM Testnet:

      polygonzkevmtestnet: {
        name: 'polygonzkevmtestnet',
        chainId: 1442,
        protocol: ProtocolType.Ethereum,
        nativeToken: {
          name: 'ether',
          symbol: 'ETH',
          decimals: 18,
        },
        rpcUrls: [
          {
            http: 'https://rpc.public.zkevm-test.net',
          },
        ],
        blockExplorers: [
          {
            name: 'Polygon Scan',
            url: 'https://testnet-zkevm.polygonscan.com',
            apiUrl: 'https://api-zkevm.polygonscan.com/api',
          },
        ],
        isTestnet: true,
      },
  

Adding the Validator Keys

For this tutorial, we are using the default Multisig as our Interchain Security Module.

Follow these steps, for setting up the keys:

• Open config/multisig_ism.ts. There you will find the configuration example for adding new chains and their keys.

• Add the keys for your validator:

      polygonzkevmtestnet: {
        threshold: 1,
        type: ModuleType.LEGACY_MULTISIG,
        validators: [
          '0xabcabcabcabcabcabcabcabcabcabcabcabcabca',
          '0xabcabcabcabcabcabcabcabcabcabcabcabcabca',
          '0xabcabcabcabcabcabcabcabcabcabcabcabcabca',
          '0xabcabcabcabcabcabcabcabcabcabcabcabcabca',
        ],
      },
  

• threshold is 1 which means only one of the validator's signatures is required.

Woohoooo!!! You are done with the setup for the deployment of HYPERLANE on Polygon zkEVM testnet with remotes Mumbai and Sepolia.

Deploying the Hyperlane

To deploy Hyperlane, run the following command on your terminal.

DEBUG=hyperlane* yarn ts-node scripts/deploy-hyperlane.ts --local polygonzkevmtestnet \
  --remotes mumbai sepolia \
  --key 0xbeda2b3910bae7dbfb4e65e9c0931f001066d4f0df257b77ad55093fa271bde2

In the above command,

• we are running the deploy-hyperlane.ts script

• with polygonzkevmtestnet as local chain and

• mumbai and sepolia as remotes. Since mumbai and sepolia are already provided by the Hyperlane SDK we don't need to add the configurations again.

• the value after key param is your private key to the address that contains funds for all the networks.

After running the command, wait for a few minutes till your terminal looks like this 👇🏻

Congrats!!! You just Deployed Hyperlane on Polygon zkEVM Testnet.

But to test this out, you will need to run your Validators and Relayers for all the chains you deployed (local + remote). To learn how to setup Validators and Relayers check them out 👇🏻

Thanks for going through the whole blog, I hope you learned something today.

Let me know if you have any doubts on Twitter, Lenster or LinkedIn.

Happy Learning 🙌🏻

Keep Building 🧱🚀

Even with the vast network of blockchain, with 1000s of nodes and 100s of chains (L1, L2, L3....) the users are getting restricted in utilizing the complete potential of the decentralized network. Reason? Some application works on ETH, some on Polygon, some on Gnosis, and so on and on!

In the ever-growing network of Blockchain Networks, or different blockchain networks developers are required to build chain-agnostic applications.

No dependency on one chain, and no restriction for any user.

Now solving this interoperability issue between different chains requires devs to build robust and more importantly secure designs, which is a highly technical and resourceful process, and to save devs from going through such pain Hyperlane comes into the picture.

In this article, we are going to learn almost all about Hyperlane and it works, so grab a coffee ☕️ and LFG 🚀

What is Hyperlane?

Hyperlane is a Permissionless Interoperability Protocol that helps devs send arbitrary data across chains⛓

Read in short here:

https://twitter.com/megabyte0x/status/1686628441888804864

"Permissionless" means no one requires any sort of permission from the Hyperlane Team to use Hyperlane SDK, Contracts, or even while deploying on new chains as I did👇🏻

"Interoperability" means sending between different chains. Imagine initiating a transaction on ETH on certain to close a position on Polygon.

Hyperlane is a complete modular protocol that helps devs to customize it according to their application requirements.

The following are the key components of Hyperlane:

• Mailbox

• Interchain Security Module [ISM]

• Interchain Gas Payment [IGP]

• Agents

You can either learn about all of them in deep one by one or go directly to the last section for a quick view with examples.

Mailbox

Mailbox is an on-chain API to send and receive interchain messages.

You can also check this out:

https://twitter.com/megabyte0x/status/1686979539291762688

Mailbox is the middle-man [but CODE] which helps devs to connect between different chains and leverage it to build something out of the box.

Their contracts are required to be present on every chain supported by Hyperlane.

Mailbox Interface has two functions that are required to be present in the cross-chain contracts, those are the following:

• dispatch

• process

dispatch

This is used to send the data from the origin chain to the destination chain.

It accepts several params:

• _destinationDomain (uint32): domain for the destination chain as per the Hyperlane Docs or the deployer.

• _recipient Address (bytes32): address of the recipient.

• _messageBody (bytes): Raw bytes content of message body

It works by following these steps:

• First, check whether the message length exceeds the 2KiB length.

• It formats the _messageBody using Message.sol according to the needs.

• Message.sol provides a function .id() that returns keccak256(_message). This _id is saved into the "incremental" Merkle Tree.

• The Merkle Tree is used to verify fraud proofs in Hyperlane's Staking and Slashing Protocol.

process

This is used on the destination chain to receive the message.

It accepts the following two params:

It works by following these steps:

• _message is the formatted message from the Message.sol

• _metadata is the specific Arbitrary metadata provided by the relayer used by ISM to verify _message

• Then it checks whether this _id is in the array of delivered messages or not. If it is, then it reverts with "delivered" else add it to the array of delivered messages.

• Then it gets the ISM Address for the recepientAddress.

• If the recipient has defined a specific ISM it returns that else uses the default ISM for the chain.

• It uses the ISM address to verify messages received by the Mailbox.

• After all verification, it emits the message received event using the IMessageRecepient.sol

Learn more about Mailbox here.

Interchain Security Modules

ISM verifies the particular messages delivered on the destination chain are actually sent from the origin chain.

You can also check this out:

https://twitter.com/megabyte0x/status/1687471625724383232

ISM is used in the Mailbox, to verify the message Mailbox received from the relayer before executing txns.

Developers can define specific ISM for their applications or can use pre-built ISMs provided by the team, using the ISpecifiesInterchainSecurityModule.sol

ISMs are:

Each ISM has two main components:

verify

It takes two params:

• message(bytes): Message that needs to be verified.

• metadata(bytes): Off-chain Arbitrary bytes provided by the Relayers.

moduleType

It signals relayers about the type of module to be included in the metadata.

Implementation

Implementation of a specific ISM in an application is done by using the ISpecifiesInterchainSecurityModule.sol

There are different prebuilt ISMs provided by the team:

• MultisigISM

• RoutingISM

• AggregationISM

• OptimisticISM

• WormholeISM

• HookISM

Learn more about ISM here.

Interchain Gas Paymaster

On-chain API to pay Relayer(s) to deliver the message on the destination chain.

You can also refer to this:

https://twitter.com/megabyte0x/status/1687818750635261954

An interchain message requires two transactions:

1. Txn on the origin chain to send the message.

2. Txn on the destination chain to receive the message.

When users send the message from The Mailbox on the Origin Chain to the Relayer, they also need to send the gas fee amount to the Relayer to cover the fee on the Destination Chain. This gas fee is calculated with IGP and paid to the Relayer simultaneously.

IGP Provides us with two functions:

• payGasFor()

• quoteGasPayment()

payForGas

It takes these params:

• _messageId

• destinationDomain

• gasAmount

• refundAddress

When the user sends the above parameters, the following are the next steps:

• It first gets the gas fee required on Destination Chain by calling quoteGasPayment()

• If the required amount is less than the msg.value, then go forward else revert.

• It calculates the overpaid amount.

• If the overpaid amount is more than 0, then send the amount to the refundAddress, else move forward.

• Emits Event of GasPayment.

quoteGasPayment

It takes the following parameters:

• _destinationDomain

• _gasAmount

When it receives the above parameters, it follows like this:

• It first gets the token exchange rate and the gas price for the Destination Chain.

• Then it calculates the gas fee on the Destination Chain.

• At last, calculates the number of native tokens required on the Origin Chain and returns it.

Complete Workflow

This is the complete workflow of Interchain Gas Payment on the Origin Chain to deliver the message on the Destination Chain:

Learn more about Interchain Gas Payment here.

Agents

Off-chain actors that power Hyperlane.

You can also refer to this:

https://twitter.com/megabyte0x/status/1688514083287678977

There are three Agents in Hyperlane Protocol:

Since Hyperlane is a Permissionless Interoperability protocol, you can take the role of any agent and contribute to the security of the network.

Validators

They sign the current Merkle root which they receive from the Mailbox.latestCheckpoint()

Validators are supposed to sign the checkpoint after it reaches the finality to maintain the security of the network.

After signing the checkpoint, validators post signatures on the available storage so that the Relayers can aggregate them.

Relayers

Relayers are responsible for delivering messages to the recipient.

It works as follows:

1. observe Mailbox for the new messages.

2. Use Mailbox to get the ISM implemented by the recipient.

3. aggregate the metadata for the ISM.

4. deliver the message.

Relayers can also make configurations for the messages they want to deliver:

• A sender/recipient whitelist.

• A sender/recipient blacklist

• Getting paid on-chain after delivering.

The relayers get incentivized during the time they process the message with the gas fee.

Watchtowers

They are the snipers in the Hyperlane protocol. They look for frauds and convicts (malicious validators) happening in the validator network and kill them by slashing the validator stake. Watchtowers are incentivized when they submit the correct report of fraud.

Learn more about Agents here.

Story Time

Jim wants to send an arbitrary message (data) to Dwight from Polygon zkEVM to Ethereum with Hyperlane.

You can also refer to this:

https://twitter.com/megabyte0x/status/1688875226745253888?s=20

The following steps will be required to transfer the data:

1. Jim sends the message data, recipient address, and chain where the recipient is to the Polygon zkEVM Mailbox contract.

2. Mailbox emits an event that gets indexed.

3. Validators sign the latest checkpoint.

4. The signature gets stored in the database.

5. During the above process, Jim pays the gas fee using IGP.

6. When the gas fee is transferred to the Relayer.

7. The relayer sends the message and metadata on the ETH Mainnet.

8. The messageBody sent to ISM to get verified.

9. The message gets delivered to Dwight on the ETH Mainnet.

Whoo!!🤩 This was quite a lot of workflow and solidity contracts understanding.

You can connect with me on Twitter, Lenster or LinkedIn.

Happy Learning 🙌🏻

Keep Building 🧱🚀

Indeed, in the current scenario, few NFT marketplaces cater to non-web3 users, primarily due to the poor User Experience (UX) they have to face.

A significant barrier to entry for these users is the complexity of the Web3 ecosystem, including the need to understand concepts such as wallets, private keys, and gas fees. Moreover, the onboarding process can be tedious and confusing, with users having to set up and manage wallets and acquire cryptocurrency to interact with the marketplace. To address these issues and make NFT marketplaces more accessible to non-web3 users, it's essential to focus on improving UX.

In this guide, you’ll learn how to create a marketplace on Polygon and make it easy for non-crypto natives to use the marketplace by allowing them to log in with their emails and transfer NFTs with a **single click.

Reddit’s success with NFTs so far

Reddit is perhaps the best example of a company that brought NFTs to the masses. So far, they’ve brought NFTs to 7+ million people.

Reddit’s avatars were a massive success, partly because most customers don’t even know they’re using NFTs. They think of them as digital collectibles.

Reddit made the experience of claiming (and now buying) NFTs seamless. Users don’t need to know anything about Metamask, don’t need to hold any crypto, and don’t need to worry about remembering their seed phrases.

If we want NFTs to reach even more people, we should learn from Reddit’s success: Making NFTs simple for non-crypto native users will increase adoption.

That’s why I’ve created this guide: anyone can easily copy what worked for Reddit—specifically offering email-based login and payments via credit card. We’ll be doing this using Polygon (great for low-cost transactions) and [Paper] (SDKs for NFT commerce).

Avoid using Metamask as the only wallet for your DApp

Here the main reasons why you should avoid betting on MetaMask alone:

1. Limited Web3 knowledge can make average users hesitant to use MetaMask.

2. Installing and connecting the wallet to your DApp may confuse many users.

3. Managing private keys can be complex, posing significant concerns for users and the product. Since there is no solution for recovering a private key once it is lost or stolen, this presents a considerable issue.

Reasons for bad UX in most DApps

Every DApp aims to achieve decentralization to harness blockchain technology's potential fully. To do so, they often rely on traditional wallets that offer security and decentralization. However, like the Blockchain Trilemma, these DApps may need help with scalability.

For users who manage to create a wallet and store their private keys "safely," the next challenge arises when dealing with funds. Users must on-ramp crypto tokens and then spend them to interact with the DApp, significantly hindering new user onboarding.

Several other factors contribute to a poor user experience, such as needing to sign every interaction, always having the wallet accessible, and more. These issues can create an overall negative experience for users.

An alternative approach for login in DApps

Instead of relying on externally owned accounts (EOAs), developers can create smart contracts that act as user accounts and execute transactions on behalf of the user. This approach can improve user onboarding and the overall user experience of the DApp.

Several Ethereum improvement proposals (EIPs) try to define the concept of using smart contracts as wallets. After nine years of research, EIP-4337 was officially approved for account abstraction (AA).

AA offers customizable logic for wallet creation, transaction gas payment, and alternative tokens instead of Ether for gas fees. One such option is creating a wallet using an email address, where the user's email generates a private key. This key is then divided using cryptographic functions and shared between the user's device and the application service providers. The service provider can then pay for transaction gas, sign transactions, and assist users with private key recovery.

Paper's Solution to bad UX

The Paper offers an Embedded Wallet SDK that helps address user experience issues by providing the following features:

1. Create user wallets using email or social logins.

2. Sign messages or call blockchain methods without requiring prompts or gas fees.

3. Enable users to access or recover their wallets on any device.

4. Allow users to connect to other apps through WalletConnect.

Paper helps developers create seamless user experiences and scale their apps without setting up their own infrastructure.

Let's BUIDL (🧱,🚀) our own marketplace

Today, we will build an NFT marketplace to minimize friction for onboarding non-Web3 users. We'll achieve this by providing the option to create a wallet using any email and enabling gasless NFT transfers.

Functionalities

We will be implementing the following functionalities in our marketplace:

1. Email login for the DApp

2. Single click for buying and transferring the NFT.

Tech Stack

We build the marketplace with the following technologies:

1. React.js

2. Ethers.js

3. Paper's Embedded Wallet SDK

Prerequisites

• NPM or Yarn installed in your system.

• Basic understanding of React.js

Environment Setup

To set up the initial code (contract + UI) [Thanks to OMGWINNING for this], open your terminal in your preferred directory and enter the following commands:

git clone https://github.com/megabyte0x/NFT-Marketplace-Starter_Code.git

cd NFT-Marketplace-Starter_Code

npm install

Create a new file in the root directory named .env and paste the following content:

REACT_APP_ALCHEMY_API_URL="<Paste Alchemy URL HERE>"
REACT_APP_PRIVATE_KEY="<Paste your Private Key here>"
REACT_APP_PINATA_KEY="<Paste Pinata key here>"
REACT_APP_PINATA_SECRET="<Paste Pinata Secret key here>"
REACT_APP_PAPER_SECRET="<Paste Paper SDK secret key here>"

Obtain the required values by signing up on Alchemy, Pintata, and Paper.

npm install @paperxyz/embedded-wallet-service-sdk

Finally, start the development server with the following command:

npm start

Your development environment is now ready!

Initializing the Paper SDK

Create a file in the src folder named paper.js. This is where we will initialize the SDK.

Copy and paste the following code:

import { PaperEmbeddedWalletSdk } from "@paperxyz/embedded-wallet-service-sdk";

import { UserStatus } from "@paperxyz/embedded-wallet-service-sdk";

export const sdk = new PaperEmbeddedWalletSdk({
  clientId: process.env.REACT_APP_PAPER_SECRET,
  chain: "Mumbai",
});

export const socialLogin = async () => {
  try {
    await sdk.auth.loginWithPaperModal();
    return sdk.getUser();
  } catch (e) {
    console.log(e);
  }
}

export const socialLogout = async () => {
  try {
    await sdk.auth.logout();
  } catch (e) {
    console.log(e);
  }
}

export const getUser = async () => {
  const user = await sdk.getUser();
  return user;
}

export const getSigner = async () => {
  let signer;
  const user = await getUser();
  if (user.status === UserStatus.LOGGED_OUT) {
    return;
  }
  try {
    signer = await getUser().then((user) => {
      return user.wallet.getEthersJsSigner();
    });
  } catch (e) {
    console.log(e);
  }
  return signer;
}

• sdk initializes Paper's Embedded Wallet SDK by passing our Paper's Secret Key and the chain we will be using, "Mumbai".

• socialLogin is the function that opens the modal for social login using email.

• socialLogout is the function to log out of the user.

• getUser is the function that retrieves information about the user, such as their wallet and wallet address.

• getSigner is a function that returns the Ethereum signer for signing transactions.

Now that we initialized our SDK, let's connect it to the rest of the code.

Enabling email login

Since Navbar is the component that will be helping us connect the wallet so, let's go to src/components/Navbar.js

Copy and paste this:

import { Link } from "react-router-dom";
import { useEffect, useState } from 'react';
import { useLocation } from 'react-router';

import { socialLogin, socialLogout, getUser } from "../paper.js";

import { UserStatus } from "@paperxyz/embedded-wallet-service-sdk";

function Navbar() {

  const [connected, toggleConnect] = useState(false);
  const location = useLocation();
  const [currentAddress, updateAddress] = useState('0x');
  const [currentUser, updateUser] = useState(null);

  function updateButton() {
    const ethereumButton = document.querySelector('.enableEthereumButton');
    ethereumButton.classList.remove("hover:bg-blue-70");
    ethereumButton.classList.remove("bg-blue-500");
    ethereumButton.classList.add("hover:bg-green-70");
    ethereumButton.classList.add("bg-green-500");
  }

  async function connectWithPaperWallet() {
    try {
      await socialLogin().then((user) => {
        if (UserStatus.LOGGED_IN_WALLET_INITIALIZED === user.status) {
          setUser();
        }
      });
    } catch (e) {
      console.log(e);
    }
  }

  async function logout() {
    try {
      await socialLogout().then(() => {
        setUser();
      });
    } catch (error) {
      console.log(error);
    };
  }

  async function setUser() {
    try {
      await getUser().then((user) => {
        if (user.status === UserStatus.LOGGED_OUT) {
          toggleConnect(false);
          updateUser(null);
          updateAddress('0x');
          return;
        }
        updateUser(user);
        updateAddress(user.walletAddress);
        toggleConnect(true);
        updateButton();
      })
    } catch (error) {
      console.error(error);
    }
  }

  useEffect(() => {
    setUser();
  }, [currentUser]);
}

export default Navbar;

Here, we've defined several state variables and a few functions to connect the wallet using Paper's SDK.

• updateButton() updates the UI for the Connect Wallet button.

• connectWithPaperWallet() uses the socialLogin function defined in paper.js to open a modal where users can sign in using their email. If the user signs in successfully, it will update the state of currentUser and currentAddress.

• The logout() function uses the socialLogout function defined in paper.js to log out of the current user. This ensures that when the user clicks the logout button, their session will be terminated, and their wallet will be disconnected from the DApp.

• Similarly, the setUser() function is called whenever either connectWithPaperWallet() or logout() is called. This function sets the state variables such as currentUser, currentAddress, and connected. It retrieves the latest user information and updates the state variables accordingly. This updates the UI with the user's connection status and ensures a smooth user experience.

• useEffect initiates when the currentUser changes, retrieving the latest changes in the user state and updating the state variables accordingly.

Next, let's create the returning component in this:

//....

  }, [currentUser]);

return (
    <div className="">
      <nav className="w-screen">
        <ul className='flex items-end justify-between py-3 bg-transparent text-white pr-5'>
          <li className='flex items-end ml-5 pb-2'>
            <Link to="/">
              <div className='inline-block font-bold text-xl ml-2'>
                NFT Marketplace
              </div>
            </Link>
          </li>
          <li className='w-2/6'>
            <ul className='lg:flex justify-between font-bold mr-10 text-lg'>
              {location.pathname === "/" ?
                <li className='border-b-2 hover:pb-0 p-2'>
                  <Link to="/">Marketplace</Link>
                </li>
                :
                <li className='hover:border-b-2 hover:pb-0 p-2'>
                  <Link to="/">Marketplace</Link>
                </li>
              }
              {location.pathname === "/sellNFT" ?
                <li className='border-b-2 hover:pb-0 p-2'>
                  <Link to="/sellNFT">List My NFT</Link>
                </li>
                :
                <li className='hover:border-b-2 hover:pb-0 p-2'>
                  <Link to="/sellNFT">List My NFT</Link>
                </li>
              }
              {location.pathname === "/profile" ?
                <li className='border-b-2 hover:pb-0 p-2'>
                  <Link to="/profile">Profile</Link>
                </li>
                :
                <li className='hover:border-b-2 hover:pb-0 p-2'>
                  <Link to="/profile">Profile</Link>
                </li>
              }
              <li>
                <button className="enableEthereumButton bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded text-sm" onClick={connectWithPaperWallet}>{connected ? "Connected" : "Connect Wallet"}</button>
              </li>
              <li>
                {connected && <button className="enableEthereumButton bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded text-sm" onClick={logout}>Logout</button>}
              </li>
            </ul>
          </li>
        </ul>
      </nav>
      <div className='text-white text-bold text-right mr-10 text-sm'>
        {currentAddress !== "0x" ? "Connected to" : "Not Connected. Please login to view NFTs"} {currentAddress !== "0x" ? currentAddress : ""}
      </div>
    </div>
  );
}

export default Navbar;

Here, we've created a basic Navbar to help navigate the "Marketplace", "List My NFT", and "Profile" pages. It also includes a dynamic Connect Wallet Button that will initiate the connectWithPaperWallet function and Logout Button that will trigger the logout function.

Single Click to buy and transfer the NFT

Let's move to the src/components/NFTPage.js file.

Copy and paste the below code:

import axios from "axios";
import { useParams } from 'react-router-dom';
import { useState } from "react";
import { ethers } from "ethers";

import Navbar from "./Navbar.js";

import { getSigner, getUser } from "../paper.js";

import MarketplaceJSON from "../Marketplace.json";

export default function NFTPage(props) {

    const [data, updateData] = useState({});
    const [dataFetched, updateDataFetched] = useState(false);
    const [message, updateMessage] = useState("");
    const [currAddress, updateCurrAddress] = useState("0x");
    const [recieverAddress, updateRecieverAddress] = useState("0x");

    async function getNFTData(tokenId) {
        const signer = await getSigner();
        const user = await getUser();

        const addr = await user.walletAddress;
        //Pull the deployed contract instance
        let contract = new ethers.Contract(MarketplaceJSON.address, MarketplaceJSON.abi, signer)
        //create an NFT Token
        const tokenURI = await contract.tokenURI(tokenId);
        const listedToken = await contract.getListedTokenForId(tokenId);
        let meta = await axios.get(tokenURI);
        meta = meta.data;

        let item = {
            price: meta.price,
            tokenId: tokenId,
            seller: listedToken.seller,
            owner: listedToken.owner,
            image: meta.image,
            name: meta.name,
            description: meta.description,
        }
        updateData(item);
        updateDataFetched(true);
        updateCurrAddress(addr);
    }

    async function buyNFT(tokenId) {
        try {
            const signer = await getSigner();

            updateMessage("Buying the NFT... Please Wait (Upto 1 min)")

            const funcInterface = new ethers.utils.Interface(["function executeSale(uint256 tokenId) public"]);
            const dataToSend = funcInterface.encodeFunctionData("executeSale", [tokenId]);

            let tx = {
                to: MarketplaceJSON.address,
                value: ethers.utils.parseEther(data.price),
                data: dataToSend
            };
            const txResponse = await signer.sendTransaction(tx);
            const txReceipt = await txResponse.wait();
            console.log("Transaction sent:", txReceipt.transactionHash);

            alert('You successfully bought the NFT!');
            updateMessage("");
        }
        catch (e) {
            alert("Upload Error" + e)
        }
    }

    async function transferNFT(tokenId) {
        try {

            const signer = await getSigner();

            //Pull the deployed contract instance
            let contract = new ethers.Contract(MarketplaceJSON.address, MarketplaceJSON.abi, signer);

            updateMessage("Transferring the NFT... Please Wait (Upto 1 min)")
            //run the executeSale function
            let transaction = await contract.transferNFT(tokenId, recieverAddress);
            await transaction.wait();

            alert('You successfully transferred the NFT!');
            updateMessage("");
        }
        catch (e) {
            alert("Upload Error" + e)
        }
    }

    const params = useParams();
    const tokenId = params.tokenId;
    if (!dataFetched)
        getNFTData(tokenId);
}

The NFTPage component is a separate page that includes two functions, one for buying NFTs and one for transferring NFTs. Let's understand how each function works in detail:

1. getNFTData(): This function fetches the data of a specific NFT using its tokenId.

2. buyNFT(): This function transfers the NFT and price from the seller to the buyer. It uses the signer to make transactions and encodes the data for the contract. sendTransaction() (provided by Paper's Embedded Wallet SDK) initiates the transaction, which improves the UX, as users don't need to sign any transactions.

3. transferNFT(): This function transfers the NFT. It brings in the signer and uses ethers.js for initiating transactions. By creating the instance of the contract with the signer and initiating the transaction using the traditional method with the contract, users can transfer NFTs with just a single click! All that is needed is to include Paper's Embedded Wallet SDK as a signer in the contract instance.

Next, let's create the component to return:

// ...
if (!dataFetched)
        getNFTData(tokenId);

return (
        <div style={{ "min-height": "100vh" }}>
            <Navbar></Navbar>
            <div className="flex ml-20 mt-20">
                <img src={data.image} alt="" className="w-2/5" />
                <div className="text-xl ml-20 space-y-8 text-white shadow-2xl rounded-lg border-2 p-5">
                    <div>
                        Name: {data.name}
                    </div>
                    <div>
                        Description: {data.description}
                    </div>
                    <div>
                        Price: <span className="">{data.price + " MATIC"}</span>
                    </div>
                    <div>
                        Owner: <span className="text-sm">{data.owner}</span>
                    </div>
                    <div>
                        Seller: <span className="text-sm">{data.seller}</span>
                    </div>
                    <div>
                        {currAddress === data.owner || currAddress === data.seller ?
                            <div className="text-emerald-700">
                                You are the owner of this NFT
                                <br></br>
                                <input type="text" placeholder="Enter the address of the buyer" className="bg-gray-800 text-white rounded-lg p-2 mt-2"
                                    onChange={(e) => updateRecieverAddress(e.target.value)}
                                ></input>
                                <button className="enableEthereumButton bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded text-sm" onClick={() => transferNFT(tokenId)}>Transfer this NFT
                                </button>
                            </div>


                            :
                            <button className="enableEthereumButton bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded text-sm" onClick={() => buyNFT(tokenId)}>Buy this NFT</button>

                        }

                        <div className="text-green text-center mt-3">{message}</div>
                    </div>
                </div>
            </div>
        </div>
    )
}

The component we return displays the details about the NFT using the specific tokenId. The exciting feature here is that the interface shows the "Transfer" button if the user is the owner or the seller of the NFT; otherwise, it displays the "Buy" button.

And after implementing everything, here's the result you'll get:

Now, restarting the whole DApp by closing the tab and terminal will work seamlessly with the UX your user wants.

Summary

Wohoo!!! You just created an NFT marketplace with far better UX than the current ones.

You can check out the complete code here:

Paper Provide several solutions to improve UX, like payment through credit cards.

Learn more about Paper's SDK here

Connect with me on Lens🌿[@megabyte0x.lens] or Twitter[@megabyte0x].

Also, feel free to share your learnings and reach out to me if you've any doubts or questions.

Happy building! 🛠️

WAGMI🚀

In today's post, let's learn about the chain interoperability (CI) requirements in Web3.

There has been a lot of recent fuss about cross-chain applications and protocols coming up with their chain/frameworks/libraries to help the devs build cross-chain applications and leverage the power of CI. But before anything, we should understand the requirements and advantages of CI. I will discuss a few significant areas in which interoperability will directly impact Web3.

Let's learn the fundamentals first 🙌

What is Chain Interoperability?

CI is the ability of blockchain networks to communicate and share data and resources to form a more extensive unified network.

Imagine a chain with good security and one with widespread decentralization coming together and sharing their properties. We will have a unified network that will be both secure and decentralized. This will encourage builders to build more cross-chain DApps using all the properties within a single network.

Benefits of Chain Interoperability in Web3

Let's review the benefits CI can bring.

Security

CI can increase blockchain security as the attacker will not target the security of one network but all the networks in that particular unified network. It also allows for sharing security protocols and best practices between different networks, enabling each network to benefit from the security features of other networks. Additionally, cross-chain communication can improve the verification of transactions and smart contracts, enhancing security by reducing the risk of malicious actors attempting to manipulate or tamper with the system.

For example, the Polkadot network allows interoperability between its parachains, which allows them to have their security mechanisms in addition to the security of the Polkadot network itself. This will benefit the overall network by sharing different security properties, which can increase the overall safety of the unified network.

Decentralization

CI allows different blockchains to operate independently while still being able to communicate and collaborate. This reduces the risk of single-point failure of the network and makes it more reliable for the developers and users. This also promotes that only a single entity or organization has significant control over the network.

For example, the Cosmos network enables interoperability between different blockchain networks through "zones" that can communicate with each other. These zones can be independent blockchains that operate independently, but they can also communicate with other zones through a shared hub called Cosmos Hub. This enables different blockchains to work independently while still being able to collaborate, reducing the risk of centralization.

Scalability

CI is vital for scaling blockchain networks. It helps reduce congestion (the number of transactions on a particular chain) and increases the transaction speed using resources and properties of different blockchain networks simultaneously. This is achieved through cross-chain transactions that allow for the execution of transactions across multiple blockchains.

For example, CI can improve the scalability of layer-2 solutions by enabling cross-chain communication. The IBC Protocol allows interoperability between different layer-2 solutions. This means that users on one layer-2 solution can execute transactions with users on another layer-2 solution, even if they are built on different blockchains.

Bridges: A Step Towards Interoperability

Let's check out bridges, what they are, and how they help with CI.

What are Bridges?

Bridges in the blockchain mean the same as in the real world. An object connecting two destinations. Bridges facilitate communication between different blockchains through the transfer of information and resources.

For Example, If you want to move your Ether from the Ethereum mainnet to Polygon Mainnet, you can use Polygon Bridge

Types of Bridges

There are two types of bridges.

Trusted Bridges

These centralized bridges will have an intermediatory between the user and the blockchain. An intermediary will first receive the user's transaction request before executing the transaction on the blockchain.

Trustless Bridges

These are decentralized bridges, only based on code, nothing in between. The user will have all power over their assets and can execute the transaction themselves. The security of this type of bridge will rely on the smart contract and the consensus of the underlying blockchain network.

Risks Associated with Bridges

Everything innovation comes with some risks so do bridges. Different types of risks are associated with each type of bridge.

In trusted bridges, there are censorship and custodial risks. The intermediaries can collab and pull the funds from the user wallets.

In trustless bridges, the main risk is software bugs because the technology is evolving, and there's a constant need to keep everything up to date.

Learn more about Bridges from here.

https://ethereum.org/en/bridges/

Protocols That Make Interoperability Possible

There are also protocols that facilitate CI; let's look at the most prominent ones.

Router Protocol

Router Protocol has its chain, which works on proof-of-stake. The validators of the chain not only validate the state changes of the router chain and monitor state changes on other chains. Applications on Router can write custom logic to trigger events in response to these external state changes. Additionally, with Router, applications can leverage a trustless network of relayers to update states on external chains.

You can learn Building Cross-Chain NFT using Router Protocol here 👇🏻

Hyperlane

Hyperlane is a permissionless interoperability solution that anyone can use permissionless on any chain layer 1, layer 2, rollup, etc.

It also provides the developer to build their security model and the ability to choose from a few sets of default security mechanisms.

Inter Blockchain Communication (IBC)

IBC is also a permissionless interoperability solution; it uses two layers to go cross-chain. The first is the app layer, in which standards define the application handlers to pass the data packets over the transport layer. The second one, TAO, is the infra layer for transporting, retrieving, and ordering data packets.

Connect with me on Lens🌿[@megabyte0x.lens] or Twitter[@megabyte0x].

Also, feel free to share your learnings and reach out to me if you've any doubts or questions.

Happy building! 🛠️

WAGMI🚀

Today we will write an NFT (ERC721) smart contract, allowing sending and receiving an NFT from different chains. To transfer our NFTs between chains, we will use Router Cross-Talk Library.

We will transfer an NFT from Avalanche Fuji Testnet to Polygon Mumbai Testnet.

If you are more of a video tutorial fan, then this is for you 👇🏻

Understanding the Fundamentals

Before we start, let's look at the basics, so we're all on the same page.

What is Chain-Interoperability?

Chain interoperability is the capability of different blockchain networks or systems to interact and exchange information and resources. In simpler terms, blockchain systems can work together as a unified network instead of operating in isolation.

For example, we could use one blockchain to store financial transactions and another blockchain to store information about a supply chain. If these two blockchains are interoperable, they can create a new application combining both benefits.

Chain interoperability is a complex aspect of blockchain technology, requiring a deep understanding of cryptography, consensus algorithms, and network protocols.

Implementing interoperability protocols like the Router Protocol and Cosmos Network provides a common language and infrastructure for transferring information and assets between networks, creating a more interoperable and connected blockchain ecosystem.

The continued advancement of interoperability standards and protocols will play a vital role in shaping the future of blockchain technology and its impact on various industries and society as a whole.

What is the CrossTalk Library?

Router's CrossTalk library is an extensible cross-chain framework that enables seamless state transitions across multiple chains. In simple terms, this library leverages Router's infrastructure to allow contracts on one chain to communicate with contracts deployed on some other chain.

It consists of 3 essential functions, which help build a cross-chain application together.

1. requestToDest sends cross-chain requests with a message from the source contract to the gateway contract on the source chain. The message will then be forwarded to the Gateway Contract on the destination chain.

2. handleRequestFromSource is to send the request (with some message) from the source contract (on the source chain) to the destination contract (on the destination chain), where it executes all the functions defined in it and then will return the data(if any).

3. handleCrossTalkAck is to receive the acknowledgment on the source chain from the gateway contract on the destination chain, which is in the boolean value stating whether the functions on the destination chain got executed.

Learn more about Cross Talk Library from here.

The following figure shows how we will implement CrossTalk Librabry in our contract.

Implementing the Contract 👨🏻‍💻

Now that we have learned the fundamentals let's start developing our contract.

Setting up the Environment

Before we can start programming, we need to set up our development environment.

Creating a Project

Create a project folder and initialize NPM.

$ mkdir crossERC721 && cd crossERC721
$ npm init -y

Installing Dependencies

Install dependencies and initialize a Hardhat project.

Drink some water while all the dependencies to install!

$ npm install --save-dev hardhat ts-node typescript chai @types/node @types/mocha @types/chai dotenv
$ npx hardhat

Select "TypeScript Project" and then press "Enter" three times. The result should look like the following figure; it will start installing dependencies.

Configuring Hardhat

Open the folder with an IDE (I am using VSCode) to configure Hardhat.

File hardhat.config.ts:

require("@nomicfoundation/hardhat-toolbox");
require("dotenv").config({ path: ".env" });
require("@nomiclabs/hardhat-waffle");

const PRIVATE_KEY = process.env.PRIVATE_KEY;
const ALCHEMY_POLYGON_URL = process.env.ALCHEMY_POLYGON_URL;
const POLYGON_SCAN_KEY = process.env.POLYGON_SCAN_KEY;
const AVALANCHE_URL = process.env.AVALANCHE_URL;
const AVALANCHE_SNOWTRACE_KEY = process.env.AVALANCHE_SNOWTRACE_KEY;

module.exports = {
  solidity: "0.8.18",
  networks: {
    mumbai: {
      url: ALCHEMY_POLYGON_URL,
      accounts: [PRIVATE_KEY],
    },
    fuji: {
      url: AVALANCHE_URL,
      accounts: [PRIVATE_KEY],
      chainId: 43113,
    },
  },
  etherscan: {
    apiKey: {
      polygonMumbai: POLYGON_SCAN_KEY,
      avalancheFujiTestnet: AVALANCHE_SNOWTRACE_KEY,
    },
  },
};

Setting up the Environment Variables

To set up the env variables in development, add them into the .env file.

File .env:

ALCHEMY_POLYGON_URL= "abcabc"
PRIVATE_KEY=abcbcabc
POLYGON_SCAN_KEY= abcabcabc
AVALANCHE_SNOWTRACE_KEY = abcabcabc
AVALANCHE_URL= "https://api.avax-test.network/ext/bc/C/rpc"

The missing pieces and where to find them:

• ALCHEMY_POLYGON_URL - dashboard.alchemy.com

• PRIVATE_KEY - your development account in MetaMask.

• POLYGON_SCAN_KEY - polygonscan.com/myapikey

• AVALANCHE_SNOWTRACE_KEY -snowtrace.io/myapikey

Congrats 🤩🎉 Your set up your environment for development.

Installing the Contract Dependencies

Install OpenZeppelin contracts and dependencies for cross-chain functionalities:

$ npm install @openzeppelin/contracts evm-gateway-contract @routerprotocol/router-crosstalk-utils

Finallyyy... done with DEPENDENCIESsss...

Writing the Contract Code 💪🏻

Create a new Solidity file at contracts/CrossERC721.sol.

Implementing the Contract Definition

First, we need to set up our contract definition. The contract will use different dependencies to facilitate the cross chain interaction.

File CrossERC721.sol:

// SPDX-License-Identifier: Unlicensed 
pragma solidity 0.8.18;

import "evm-gateway-contract/contracts/ICrossTalkApplication.sol"; import "evm-gateway-contract/contracts/Utils.sol"; import "@routerprotocol/router-crosstalk-utils/contracts/CrossTalkUtils.sol"; import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

contract CrossERC721 is ERC721, ICrossTalkApplication {}

Declaring the State Variables

File CrossERC721.sol:

// ...

contract CrossERC721 is ERC721, ICrossTalkApplication {
    // Address of the Owner of the contract.
    address public admin;

    // Address of the gateway contract on the chain will contract deployed. 
    address public gatewayContract; 

    // Gas limit required to handle cross-chain request on the destination chain
    uint64 public destGasLimit;

    // chain type + chain id => address of our contract in bytes
    mapping(uint64 => mapping(string => bytes)) public ourContractOnChains;

    // Transfer parameter which include tokenId and the address(in bytes) of the receiver on destination chain.
    struct TransferParams {
        uint256 nftId;
        bytes recipient;
    }
}

Implementing the Constructor

When we implement the constructor, we set the state variables in the constructor and mint an NFT (ERC721) to the msg.sender.

File CrossERC721.sol:

// ...

contract CrossERC721 is ERC721, ICrossTalkApplication {
    // ...

    /// @notice Constructor to initialize the contract.
    /// @param gatewayAddress - Address of the gateway contract on the chain on which we will deploy the contract
    /// @param _destGasLimit - Gas limit required to handle cross-chain request on the destination chain.
    /// @param tokenId - Token Id of the NFT to be minted for testing.
    constructor(
        address payable gatewayAddress,
        uint64 _destGasLimit,
        uint256 tokenId
    ) ERC721("CrossERC721", "cerc721") {
        gatewayContract = gatewayAddress;
        destGasLimit = _destGasLimit;
        admin = msg.sender;
        _mint(msg.sender, tokenId);
    }
}

Implementing the setContractOnChain Method

Implement setContractOnChain to map all the contract addresses of the contract on different chains. The mapping is used to verify the contract with which we will interact.

File CrossERC721.sol:

// ...

contract CrossERC721 is ERC721, ICrossTalkApplication {
    // ...

    /// @notice Constructor to initialize the contract.
    /// @param gatewayAddress - Address of the gateway contract on the chain on which we will deploy the contract
    /// @param _destGasLimit - Gas limit required to handle cross-chain request on the destination chain.
    /// @param tokenId - Token Id of the NFT to be minted for testing.
    constructor(
        address payable gatewayAddress,
        uint64 _destGasLimit,
        uint256 tokenId
    ) ERC721("CrossERC721", "cerc721") {
        gatewayContract = gatewayAddress;
        destGasLimit = _destGasLimit;
        admin = msg.sender;
        _mint(msg.sender, tokenId);
    }
}

Implementing the setContractOnChain Method

Implement setContractOnChain to map all the contract addresses of the contract on different chains. The mapping is used to verify the contract with which we will interact.

File CrossERC721.sol:

// ...

contract CrossERC721 is ERC721, ICrossTalkApplication {
    // ...

    /// @notice Function to map all the contract addresses on different chains.
    /// @param chainType - Type of the chain specified by the Router Protocol on which we will deploy the contract
    /// @param chainId - Chain Id of the chain on which the contract is deployed.
    /// @param contractAddress - Address of the contract on the chain
    function setContractOnChain(
        uint64 chainType,
        string memory chainId,
        address contractAddress
    ) external {
        require(msg.sender == admin, "only admin");

        // CrossTalkUtils.toBytes() is a function which converts the address to bytes.
        ourContractOnChains[chainType][chainId] = CrossTalkUtils.toBytes(
            contractAddress
        );
    }
}

Implementing the transferCrossChain Method

Implement transferCrossChain, the core function of our contract. It burns the NFT owned by msg.sender on the source chain and then sends the request of transferring using CrossTalkUtils.singleRequestWithoutAcknowledgement, which sends the request to the gateway contract on the destination chain.

File CrossERC721.sol:

        // ...

contract CrossERC721 is ERC721, ICrossTalkApplication {
    // ...

    /// @notice Function to transfer the NFT from the source chain to the destination chain.
    /// @param chainType - Type of the chain specified by the Router Protocol on which the nft needs to transferred.
    /// @param chainId - Chain Id of the destination chain.
    /// @param expiryDurationInSeconds - Expiry duration in seconds of the request.
    /// @param destGasPrice - Gas price required to handle the cross-chain request on the destination chain.
    /// @param _nftId - Token Id of the NFT to be transferred.
    /// @param _recepient - Address of the recipient on the destination chain.
    function transferCrossChain(
        uint64 chainType,
        string memory chainId,
        uint64 expiryDurationInSeconds,
        uint64 destGasPrice,
        uint256 _nftId,
        address _recepient
     ) public payable {
         require(
             keccak256(ourContractOnChains[chainType][chainId]) !=
                 keccak256(CrossTalkUtils.toBytes(address(0))),
             "ERR:CROSS_CHAIN_CONTRACT_NOT_SET"
         );

         TransferParams memory transferParams = TransferParams(
             _nftId,
             CrossTalkUtils.toBytes(_recepient)
         );

         require(_ownerOf(transferParams.nftId) == msg.sender, "ERR:NOT_OWNER");

         // Burn the NFT of the user on the source chain.
         _burn(transferParams.nftId);

         // Encode the transfer parameters to bytes for sending it as payload to the gateway contract.
         bytes memory payload = abi.encode(transferParams);

         uint64 expiryTimestamp = uint64(block.timestamp) +
             expiryDurationInSeconds;

         Utils.DestinationChainParams memory destChainParams = Utils
             .DestinationChainParams(
                 destGasLimit,
                 destGasPrice,
                 chainType,
                 chainId
         );

         // Call the singleRequestWithoutAcknowledgement() function 
         // to transfer the NFT from the source chain to the
         // destination chain without any acknowledgment.
         CrossTalkUtils.singleRequestWithoutAcknowledgement(
             gatewayContract,
             expiryTimestamp,
             destChainParams,
             ourContractOnChains[chainType][chainId],
             payload
         );
    }
}

Implementing the handleRequestFromSource Method

Implement handleRequestFromSource for the contract on the destination chain. Since we must deploy the contract on every chain we interact with, we must include the receiving function in the same contract. We mint the NFT for the receiver's address on the destination chain in this function.

File CrossERC721.sol:

 // ...

contract CrossERC721 is ERC721, ICrossTalkApplication {
    // ...

    /// @notice Function to handle the request from the gateway contract on the destination chain. It manages data received and calls the function(s).
    /// @param srcContractAddress is the contract address on the source chain.
    /// @param payload is the data received from the source chain in bytes.
    /// @param srcChainId is the chain id of the source chain.
    /// @param srcChainType is the chain type of the source contrac specified by the Router Protocol.
    function handleRequestFromSource(
        bytes memory srcContractAddress,
        bytes memory payload,
        string memory srcChainId,
        uint64 srcChainType
    ) external override returns (bytes memory) {
        require(msg.sender == gatewayContract, "ERR:NOT_GATEWAY_CONTRACT");
        require(
            keccak256(srcContractAddress) ==
                keccak256(ourContractOnChains[srcChainType][srcChainId]),
            "ERR:CONTRACT_NOT_FOUND"
        );

        TransferParams memory transferParams = abi.decode(
            payload,
            (TransferParams)
        );

        // Mint the NFT for the recipient address on the destination chain.
        _mint(
            CrossTalkUtils.toAddress(transferParams.recipient),
            transferParams.nftId
        );

        // Since we don't want to return any data, we will just return empty string
        return "";
    }
}

Implementing the handleCrossTalkAck Method

Implement handleCrossTalkAck, which handles the acknowledgment by the gateway contract after the transaction on the destination chain executes. Since we are using singleRequestWithoutAcknowledgement type of request, we will leave this function empty.

File CrossERC721.sol:

// ...

contract CrossERC721 is ERC721, ICrossTalkApplication {
    // ...

    /// @notice Function to handle the acknowledgement received by the gateway contract for the functions executed on the destination chain.
    /// Since we are not expecting any acknowledgement, we will just keep this function empty.
    /// @param eventIdentifier is the event identifier of the request.
    /// @param execFlags is the array of boolean values which specifies whether the function executed successfully or not on destination chain.
    /// @param execData is the array of bytes which contains the data returned by the function executed on the destination chain.
    function handleCrossTalkAck(
        uint64 eventIdentifier,
        bool[] memory execFlags,
        bytes[] memory execData
    ) external view override {}
}

CONGRATSSS, you wrote the cross-chain contract 🎉

You can find the complete contract on GitHub.

Deploying the Contract

We will deploy our contract on Polygon Mumbai Testnet and Avalanche Fuji Testnet.

For BONUS!!! we will verify it on their respective block explorers, PolygonScan and Snowtrace

Creating a Deployment Script

Create a file at scripts/deploy.ts with the following content.

File deploy.ts:

import { ethers } from "hardhat";

async function main() {
  const network = await hre.network;

  const gatewayContract =
    network.config.chainId == 43113
      ? "0x517f256cc48145c25c27cf453f6f5006e5266543"
      : "0x8EA05371Eb360Eb79c295375CB2cCE9191EFdaD0";

  const tokenId = network.config.chainId == 43113 ? 1 : 2;

  const CrossERC721 = await ethers.getContractFactory("CrossERC721");
  const crossERC721 = await CrossERC721.deploy(
    gatewayContract,
    1000000,
    tokenId
  );

  await crossERC721.deployed();

  console.log("CrossERC721 deployed to:", crossERC721.address);

  console.log("Sleeping.....");
  await sleep(40000);

  await hre.run("verify:verify", {
    address: crossERC721.address,
    constructorArguments: [gatewayContract, 1000000, tokenId],
  });
}
function sleep(ms: number) {
  return new Promise((resolve) => setTimeout(resolve, ms));
}

main()
  .then(() => process.exit(0))
  .catch((error) => {
    console.error(error);
    process.exitCode = 1;
  });

Executing the Deployment Script

Run the following commands in the terminal in the root directory:

$ npx hardhat run scripts/deploy.ts --network mumbai

SAVE the above👆 address and URL

0xB905345D930707C992ec768Cf748AaBc0D3207Da

https://mumbai.polygonscan.com/address/0xB905345D930707C992ec768Cf748AaBc0D3207Da#code

  $ npx hardhat run scripts/deploy.ts --network fuji

SAVE the above👆 URL

0xC0438dF8A5008Af185B36F4f2C38be410C9ce95d

https://testnet.snowtrace.io/address/0xC0438dF8A5008Af185B36F4f2C38be410C9ce95d#code

You deployed and verified your contract on both chains. Awesome!!! 🎉🎉

Interacting with the Contract

To interact with our freshly deployed contracts, open the two URLs you saved in different tabs in your browser.

On the MumbaiScan tab

1. click "Write Contract".

   

2. Click on "Connect to Web3" and connect your MetaMmask wallet with it.

3. Scroll down to "setContractOnChain".

4. Enter the values. Here the contractAddress value is the address on the Fuji Network.

   

5. Click "Write" and then "Confirm" the transaction.

On the SnowTrace tab

1. Click "Write Contract".

2. Click "Connect to Web3".

3. Scroll down to setContractOnChain

4. Enter the values.

   

5. Click "Write" and "Confirm" the transaction.

   We have set the contracts on both the source and destination chains.

6. Scroll to the transferCrossChain

7. Enter the values.

   

8. Click "Write" and "Confirm" the transaction.

9. Copy recepient and paste it into the destination chain (POLYGON MUMBAI) block explorer.

   

Hoorrayyy!!! 🎉🎉

You just transferred an NFT from Avalanche Fuji Testnet to Polygon Mumbai Testnet. You can do the same with NFTs on Polygon Mumbai Testnet.

PS: You can check out the whole project here👇🏻

So, we have created an ERC721 with the implementation of Router Protocol's Cross Talk Library which helped us to transfer our NFT from Avalanche to Polygon.

You can do the same with ERC20 and others, and make your application more SCALABLE, SECURE, and DENCTRALISED.

Connect with me on Lens🌿[@megabyte0x.lens] or Twitter[@megabyte0x].

Also, feel free to share your learnings and reach out to me if you've any doubts or questions for me.

Happy building! 🛠️

WAGMI🚀