In some of the provided Axelar examples we noticed how duplicate contracts were deployed across all chains that were intended to have compatibility. For instance, looking at NFT-linkers, our understanding is that NFTs are created on the receiving chain and burned on the source. These use cases would likely serve an individual who might want to move a token from one chain to another to sell it on a specific marketplace that is inaccessible on the other chain.

Certainly, it is beneficial to illustrate use cases about moving an actual token from chain to chain. However, these methods did not fit our aims. We are aware our limited knowledge on this topic had an influence on our decision to deal with this issue through a different angle. Hence, we are keen to elaborate our views and modus operandi below.

Firstly, our dApp is intended to be fun, interactive, and educational, without necessarily focusing on any financial use case. Currently, our NFT assets (user’s stamp and letterbox stamps) are unlikely to bear any financial value per se as they are designed to celebrate individuals’ creativity and represent digital artifacts to the likes of souvenirs, memories, and family photos. We realise there is potential for them to become reputational assets in some communities, but we don’t foresee (or intend to encourage) their sale on secondary marketplaces. This is an important contextual distinction that affected our methodology.

Secondly, the relatable story of a person getting off an international flight and finding themselves caught short and without available coins in the local currency to access the airport restroom, described in a video by Axelar, really resonated with us. In fact, we fear a new user of the Moonbeam ecosystem landing on our dApp for the first time may feel as frustrated as the traveler needing to exchange money to benefit from a service. Our view is that there is no need for the interaction to take place on the chain in which users hold currency. After all, the traveler’s experience would have greatly improved from being able to use their usual currency to gain access to the restroom abroad, but they don’t have an expectation that the plumbing return their bathroom interaction to their home country, nor do they want to find, upon entering the restroom using their home currency, that they will be transported back to a restroom in that country and then returned abroad after the job is done.  Similarly, we think our users will be content to have their stamp and letterbox NFTs remaining on Moonbeam and will be more concerned about paying with a currency they have rather than seeing the NFT delivered back to the chain of that payment currency. Therefore, we have intentionally omitted to include NFT transfers from chain to chain.

Thirdly, we considered how duplicating contracts and moving tokens may have other drawbacks, such as additional complexity for us on the front-end as well as extra upkeep, deployment costs and more complexity to deal with. Instead, our efforts concentrated around accomplishing the necessary steps for calling our Moonbeam contracts from the chain users hold currency in, e.g., from Polygon. Since these are both EVM chains, and we know the users’ wallet address, we can easily deliver their NFT in that very same wallet, without the token leaving the Moonbeam network (which does not require an existential deposit to keep a wallet active). Referencing the example of moving simple text from one chain to another we experimented with a sender and receiver contract by moving the function call with appropriate parameters from the source (e.g.: Polygon) to the destination (Moonbeam).

For this Hackathon we present a rough proof-of-concept, acknowledging there is still a fair amount of work to be done to ensure security and reliability of these interactions and to generally clean up our code. We are aware of the risks that may occur with low level calls across contracts and have specific plans in place to significantly mitigate those hazards. Additionally, we have intentionally excluded token payment transfer for the time being but would implement that in the future upon pursuing Axelar as our final solution to cross-chain compatibility in the Mainnet deployment of the completed dApp.

Our solution.

A function call (eg. mintLetterbox) is made on Polygon (“PolygonSender.sol”), then is sent through → Axelar gas receiver and routing process → and arrives on Moonbase (MoonbeamReceiver.sol) which processes the payload and makes calls to our primary Moonbeam contract (LetterboxV3-1.sol).

Given the proof-of-concept status of our cross-chain contracts we have not yet implemented the functionality on the front-end, but our end plan is as follows:

We will notify users in the dApp that Moonbeam is where our NFTs will be housed and add a list of additional supported chains, suggesting they can select their preferred payment chain when connecting their wallet. Once connected, our back-end will check the chain id and route the contract calls to the appropriate helper (”sender”) contract as needed. Aside from the call for our four key interactions (minting of stamp, minting of letterbox, stamp to letterbox and letterbox to stamp) all display processes will query the Moonbeam contract.

Our code for this proof-of-concept can be found here:

PolygonSender: https://github.com/shawn-nt/AxelarNarrativeTrailsExperiment-polygon/blob/main/contracts/PolygonSender.sol

Deployed on Polygon Mumbai at: 0x9B7241067588D71DA884a41F4a9FB3D344e7cf05

MoonbeamReceiver: https://github.com/shawn-nt/AxelarMoonbeamReceiver/blob/main/contracts/MoonbeamReceiver.sol

Deployed on Moonbase Alpha at: 0xc97018d6dD5ee3e3EAecde7f5378ceD549cAC3FB