Case studies, Project Gojira, Web3 and NFT

Jirasan: unifying four NFT collections under one brand

Four collections, multiple wallets, and the flows to get every holder to a single place they could act from.

Overview

Project Gojira (PG) is an Ethereum-native NFT project that grew from a tight-knit community into one of Web3’s most respected holder ecosystems. Over several years, PG launched four distinct collections, each with its own supply, utility tier, floor price and holder base.

By 2023, the community had accumulated real complexity. Holders sat on tokens from multiple eras, held across multiple wallets, with no unified view of what they owned or what they were entitled to. PG’s answer was Jirasan, a new brand built to unify everything, and the product experience had to get every holder there.

The four PG collections

Genesis: the original PG collection. Rarest supply, highest floor value, and the most coveted tier in any claim calculation
Gen 2: the community expansion collection. Broader access, strong holder loyalty, and the backbone of PG’s active holder base
Jiraverse: PG’s third and final collection, a metaverse-focused drop including VX and 3D character models tied to existing Genesis and Gen 2 characters
JiraVox: augmented-reality voxel character models minted alongside Jiraverse, playable in the PG mobile experience and unique to original character holders

The challenge

Four collections. Multiple wallets. No way to see the full picture, or act on it. A typical long-term PG holder might have Genesis tokens in one wallet, Gen 2 tokens split across two more, and Jiraverse tokens in a cold wallet they rarely connected. The collections were not linked, they were islands.

Holders could not see their total PG footprint in one place, they had to manually check each wallet on OpenSea or Etherscan
There was no clear signal for what a given set of holdings entitled someone to claim under the new Jirasan brand
Secondary market buyers had no way to know if a PG token had already been used in a claim, they risked buying into zero utility
Support overhead was mounting as community members asked what they held and whether they had already claimed
Holding value was diluted by confusion, a holder with significant assets had no interface to manage or act on them

Multi-wallet aggregation

Connecting every wallet, surfacing every holding, before a single claim decision is made. On connection, all PG-collection holdings for that address are fetched and displayed. A persistent "add another wallet" prompt stays visible throughout the flow, and each new connection appends to the aggregated view so the user never loses their prior context. The UI then collapses all wallets into a single holdings summary, broken down by collection with wallet source attribution on hover.

A key design decision was separating wallet management from the claim action itself. Users could add, remove or swap wallets at any point without restarting the flow.

Claim flow

From holdings to Jirasan NFT, a tiered claim system that rewards every level of the community. Review your holdings, select the destination wallet for the new token, build your Jirasan profile, then confirm against a full claim summary.

Tier I, Genesis holder: highest rarity claim, unlocks the rarest Jirasan identity NFT and early access to all subsequent drops
Tier II, Gen 2 holder: strong community tier, unlocks a Jirasan character NFT specific to the Gen 2 lineage
Jiraverse: broader access tier, unlocks a Jirasan companion NFT and participation in community reward pools
Holding across two or more collections triggers a bonus multiplier, additional Jirasan reward tokens or early access to the exchange pool

Claim Validator

Before you buy a PG token on the secondary market, know if it has already been claimed. A holder could claim their Jirasan NFT then sell the original PG token, and the buyer would receive a token carrying no claim utility. There was no on-chain signal for "this has already been used."

Enter any PG token ID across all four collections
The system queries the claim contract to check whether that token ID has been used in a Jirasan claim
Result is immediate: unclaimed (safe to buy), claimed (no remaining utility), or partially claimed
Each result includes the claim date, the tier claimed, and the destination wallet
Batch validation returns a table view, so bulk buyers can filter out already-claimed tokens before a sweep

Token exchange

Once a holder claimed their Jirasan NFT, the ecosystem did not stop there. Each eligible token surfaces a contextual exchange menu of what it can be swapped for: new NFT characters, companion drops, and ecosystem reward tokens. Before confirming, users see a side-by-side comparison of what they are giving up against what they are receiving.

One design constraint: exchanges had to feel irreversible without feeling punitive. The preview step was critical, and it reduced post-exchange regret significantly in early testing.

Dashboard

With four flows live, the dashboard became the most important surface in the product. It needed to surface everything relevant without becoming an overwhelming data dump: a portfolio panel across all connected wallets with claim status badges and floor value estimates, priority-ordered action cards that show the next most relevant action rather than everything at once, a chronological activity feed serving as a personal audit trail, and the validator as a persistent widget in the sidebar.

Reflection

Design challenges: multi-wallet state management, keeping the holdings snapshot accurate as wallets were added and removed mid-flow, was the hardest UX problem. Exchange transactions that burn tokens needed firm but non-intimidating confirmation gates. Partial claim logic had to be communicated without confusing users about their eligibility. On-chain latency meant designing loading states that felt alive during slow confirmation windows.

Key insight

Web3 product design is fundamentally trust design. Every screen, the validator, the claim preview, the exchange comparison, was answering a version of the same question: can I trust what this is telling me? Getting that right required radical transparency at every decision point, and zero ambiguity about what was irreversible.

Outcome

4 NFT collections unified
10+ wallets per user supported
One dashboard for all flows
No dead claim risk on secondary purchases

What we did

Product Design, Prototyping