Narrative Trails - Letterboxing

Inspiration

We have been in awe of the great infrastructure developed by communities in the Dotsama ecosystem, which prompted the vision for Narrative Trails as a user-friendly non-defi dApp. Whilst our long-term ambition is to craft unique narrative-driven NFT-enhanced travel experiences, we decided to test the waters with a smaller initiative that could facilitate incremental development that would create the foundation for our final endeavor.

Shawn, our smart contract developer, came up with the idea for the dApp during a family road-trip across the US southeast. To break-up their drive and explore new places, he and his children engaged in the leisurely activity of “letterboxing” in the woods. In that particular occasion they found out that the log book inside the letterbox had been waterlogged (damaged by water). As a result, the records of all the box visitors, in the form of linocut stamp impressions, were quickly fading away and wouldn’t likely be enjoyed by the person who planted that letterbox. This planted the seed - letterboxing needs an NFT layer!

Narrative Trails has the ambitious goal of blurring the line between real-world and digital experience through immersive and fun adventures that are suitable for the crypto curious and web3 native alike. To make it a reality we are using RMRK multiresource NFTs to build an NFT layer for traditional letterboxing.

It should be noted that we started to build the dApp for the Polkadot North America Hackathon and were able to deliver a rough demonstration of the concept during that event. We have taken advantage of the Moonbeam Connected Contracts Hackathon to implement improvements on the user interface, integrate RMRK EVM updates into our code, and investigate how a multi-chain user experience would work. Moreover, we have outlined a unique approach to our use of Axelar’s service for multi-chain NFTs (when compared, for example, to the method used in the NFT linker example).

What it does

Users first task is to mint their own NFT stamp to represent their identity in the dApp and the letterboxing community. The stamp is created as a RMRK multi-resource NFT and it also serves as the NFT equivalent of their real-world notebook. Additionally, users can make letterbox NFTs that are the digital version of the letterbox they “plant” in the wild.

When a user finds a letterbox, their stamp’s primary resource is added to the letterbox NFT stamp. Conversely, the letterbox’s primary resource is added to the user’s NFT stamp. Thus, each user’s stamp collects the image of the letterboxes they find, and each letterbox accumulates the image of all users’ NFT stamps who found the letterbox.

Our contract and front-end code substantially improved, and the addition of a designer to our team has resulted in a very noteworthy improvement to our user interface in the areas we had time to complete during this past month.

In this instance, we have submitted code that shows our approach on cross-chain compatibility: instead of transferring NFTs and duplicating the core contract across chains we prioritize users’ interaction in the dApp giving them the freedom to pay for their stamp and gas using their preferred supported network. All NFTs and our main contract logic will exist on Moonbeam, with only gas, tokens and function calls coming from the other chain to be executed at our Moonbeam home. At present our dApp offers free access – with gas fees only to be paid for interaction by end users. In the near future we intend to add Axelar token transfer support for ERC-20 to accept Matic (Polygon) and other payment methods for any token fee as set in the primary Moonbeam contract. The end user can make calls to our main contract to mint a stamp or letterbox, and to complete the process of finding a letterbox (adding resources).

Our code for the Axelar portion of this hackathon is currently at the proof-of-concept stage, so we acknowledge that there are security issues with the exact implementation we are including. Now that we have experimented with examples, talked it through with others, and got a proof-of-concept rolled out, we intend to rework our code with proper error handling and security in place. Low level calls can be risky, but we have a number of ways to limit the potential risks and plan to test any implementation thoroughly before rolling out code to Mainnet. You can read more about the way we approached it here: link

How we built it

We have deployed our contracts to Moonbase Alpha. They use RMRK’s EVM code (from the dev branch as of early September) which we will continue to monitor and re-deploy as that codebase stabilizes. Our front-end is deployed on Vercel with NextJS and Tailwind CSS. We have used Fleek for IPFS NFT Metadata and image storage. Figma was used to create our UI design.

We have separately deployed contracts demonstrating the proof-of-concept of our intended use of Axelar’s cross-chain capabilities. A “sender” contract is deployed to Polygon, and a “receiver” contract is deployed on Moonbase that interacts with the primary NFT contract mentioned above. Hardhat was our tool of choice for development and deployment of smart contracts.

Again, if you want to learn more about the details of the logic of our approach to cross-chain interactions you can view this link.

Challenges we ran into

Shawn is still new to, and actively learning the Solidarity programming language (and programming in general). Additionally, with Axelar being a novel technology, it took some time to understand both, theoretically and in practice. Given our desire to have the dApp eventually deployed to Mainnet as a cross-chain application, we spent a fair amount of time considering the approach and future implications of various approaches.

Time constraints due to working on this Hackathon in addition of juggling other work and personal commitments in our schedules is, of course, a challenge.

We are knowingly using code that is in active development (the dev branch of RMKR’s EVM code) and are committed to participating in that process. However, we must acknowledge that this presents some challenges in the context of the Hackathon timeline because, occasionally the codebase can go through significant changes which may lead to some unforeseen issues. For instance, in a previous iteration we used a function for the retrieval of full resource objects which returned an array, but in a later update to the codebase the retrieval of those resources became a multi-step process that (eventually) returned mappings instead of an array. Needless to say, these sort of changes required additional time and tinkering to work through as they had unexpected consequences on the front-end interactions with our contract.

We tested our Axelar proof-of-concept successfully on testnet, but later during the recording of our submission video, the same contracts and interaction encountered an issue with the gas limit being set far too low at execution by Axelar. Unfortunately, we did not have enough time to resolve or come to an explanation of the issue prior to our submission. Post-hackathon, we intend to continue to improve those contracts and will resolve the issue.

Accomplishments that we're proud of

We are proud of every bug we squashed, and of the progress we made on our dApp in the last month. A few highlights include:

• a user interface that is coming along quite nicely with steady improvements to user experience and visual appeal

• more server side rendering and exploration of performance improvements for future scaling of our Find Letterbox page

• better use of events and other general improvements to our smart contract code

• the ability to mint a letterbox on our Moonbeam contract from Polygon

We also had fun and learned a lot working together, which is always something to celebrate.

What we learned

In the form of a partial list of things we learned or greatly improved our knowledge of:

• Axelar

• Figma

• NextJS

• Solidity

What's next for Narrative Trails - Letterboxing

The team intends to continue to work on the dApp and look for ways to stay engaged in the community while we strive toward launch.

A few key items on the horizon:

• Implement the cross-chain functionality demonstrated in code into our front-end and user experience.

• Complete the design of the dApp user interface, and implement it in production

• Add map and geo search features on “Find Letterbox”, kill the spoilers (stop showing which stamps display)

• Implement our QR code related processes for the letterbox planting and finding process in the real world

• Keep improving and refining our project as the ecosystem continues to develop (eg. RMRK EVM implementation stabilizes and dev merges to main branch)

• Ensure appropriate security and error handling in our contracts, and conduct more robust testing

• Whatever else we need to accomplish to get a dApp we are proud of deployed on Mainnet

Built With

• axelar
• fleek
• hardhat
• ipfs
• javascript
• nextjs
• solidity
• tailwinds
• vercel