Role
Product Designer
Timeline
August - September 2025
Skills
Product Design, Product Strategy ,Prototyping
Four collections. Multiple wallets. No way to see the full picture — or act on it.
Holders couldn't 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 Jirasen 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 DMed the team asking what they held and whether they'd already claimed
Holding value was diluted by confusion — a holder with significant assets had no interface to manage or act on them
The design brief was clear: build a platform where a holder could connect all their wallets, see exactly what they held, understand what they were entitled to, and complete the full claim journey — without needing to leave the product or ask anyone for help.
Multi-Wallet Aggregation
Connecting every wallet, surfacing every holding — before a single claim decision is made.
Connect primary wallet
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 — the holdings snapshot and tier eligibility would update in real time with each change.
Claim Flow
From holdings to Jirasen NFT — a tiered claim system that rewards every level of the community.
Claim tier mapping
Tier I — Genesis Holder
Holding one or more Genesis tokens. Highest rarity claim. Unlocks the rarest Jirasen identity NFT and early access to all subsequent drops.
Tier II — Gen 2 Holder
Holding Gen 2 tokens without Genesis. Strong community tier — unlocks a Jirasen character NFT specific to the Gen 2 lineage.
One of the trickier UX decisions: what happens when a user connects a wallet mid-claim? Rather than blocking the flow, we allowed wallet additions up until the signing step — at which point the eligibility and tier would recalculate before presenting the final confirmation.
Claim Validator
Before you buy a PG token on the secondary market — know if it's already been claimed.
As Jirasen's claim window opened, a new risk emerged in the secondary market. A holder could claim their Jirasen NFT, then sell their original PG token. The buyer would receive the token — but it would carry no claim utility. There was no on-chain signal for "this has already been used."
User enters any PG token ID (across all four collections) into the validator input
The system queries the claim contract to check whether that token ID has been used in a Jirasen claim transaction
Result is displayed immediately: Unclaimed (green — safe to buy), Claimed (red — no remaining utility), or Partially Claimed (amber — some utility remains if multi-collection)
Each result includes the claim date, the Jirasen tier that was claimed, and the destination wallet — providing full transparency
The validator was intentionally standalone — accessible without wallet connection. Any prospective buyer, trader, or curious community member could use it before committing capital, without having to authenticate first.
Batch validation
Power users buying in bulk could paste multiple token IDs for a batch check — returning a table view with per-token status, so they could quickly filter out already-claimed tokens from a potential sweep.
The validator was one of the most requested features in community feedback after launch. It shifted the trust dynamic in the PG secondary market — buyers could now make informed decisions, and sellers of unclaimed tokens had a verifiable way to demonstrate their token's value.
Token Exchange
Claimed your Jirasen NFT? Exchange your role or tier for other assets in the ecosystem.
Once a holder claimed their Jirasen NFT, the ecosystem didn't stop there. PG planned to continuously expand the utility layer — introducing new NFT types, female characters, companion drops, and reward tokens. The exchange flow was the mechanism for existing Jirasen holders to participate in all of it.
Exchange mechanics
The exchange entry point shows all Jirasen tokens in the connected wallet(s), with current tier, rarity attributes, and any pending exchange offers displayed inline.
Browse available exchanges
Each eligible token surfaces a contextual exchange menu — a curated list of what that specific token can be swapped for. Offers include new NFT characters, companion drops, and ecosystem reward tokens.
Preview and compare
Before confirming, users see a side-by-side comparison of what they're giving up vs. what they're receiving — rarity attributes, estimated floor value, and any locked utilities — to make the exchange decision confident.
Sign and confirm
Single-signature transaction. Post-exchange, the original Jirasen token is burned or transferred to a treasury, the new asset appears in the dashboard, and an exchange receipt is logged in the activity history.
One design constraint: exchanges had to feel irreversible without feeling punitive. The preview step was critical — showing rarity comparisons side-by-side, with a deliberate confirmation gate, reduced post-exchange regret and community complaints significantly in early testing.
Dashboard
A single place to manage everything — holdings, claims, exchanges, and history.
With four flows now live, the dashboard became the most important surface in the product. It was the screen a holder would return to every time they wanted to check their status, act on a new offer, or verify a transaction. It needed to surface everything relevant without becoming an overwhelming data dump.
Exchange mechanics
Portfolio panel
A live view of all PG and Jirasen holdings across all connected wallets — grouped by collection, with floor price estimates, claim status badges, and token-level detail on expand. Filters by collection type, claim status, and wallet.
All four PG collections in one list
•Claim status badge per token (Unclaimed / Claimed / Partial)
•Per-wallet attribution on hover
•Floor value estimates pulled from marketplace data
Progressive Complexity
Surfacing the next most relevant action for each user — not everything at once. If unclaimed eligible tokens exist, the claim CTA is prominent. If exchange offers are available, they appear as a secondary action. If nothing is actionable, the panel shows community activity instead.
Priority-ordered action cards (claim first, exchange second)
One-click entry into each flow from the dashboard
Expiry timers on time-limited offers
Empty state with community discovery fallback
Activity feed
A chronological log of every claim, exchange, and wallet connection — serving both as a personal audit trail and a transparency layer for the community.
Claim receipts with token IDs and Jirasen tiers
Exchange history with before/after snapshots
Wallet management log (added / removed)
Validator shortcut
The claim validator lives as a persistent widget in the dashboard sidebar — so authenticated users can look up any PG token's claim status without leaving their account view. Secondary market research and portfolio management in the same surface.
Inline validator — no page navigation required
Recent lookups saved in session for quick comparison
Deep link to full validator for batch use
One design constraint: exchanges had to feel irreversible without feeling punitive. The preview step was critical — showing rarity comparisons side-by-side, with a deliberate confirmation gate, reduced post-exchange regret and community complaints significantly in early testing.
What this project taught me about designing trust in Web3 ecosystems.
What worked
The confidence-before-commitment framing — surfacing integration requirements early dramatically reduced install drop-off
Progressive complexity — one interface that served both business users and solution architects without compromising either
Treating the agent card as an atomic unit — it scaled from the marketplace grid to platform-wide adoption
Design challenges
Multi-wallet state management: keeping the holdings snapshot accurate as wallets were added/removed mid-flow was the hardest UX problem
•Explaining irreversibility: exchange transactions that burn tokens needed firm but non-intimidating confirmation gates
•Partial claim logic: communicating that some tokens in a wallet could be claimed while others couldn't — without confusing users about their eligibility
•On-chain latency: designing loading states that felt alive during slow blockchain confirmation windows
Future directions
A mobile-native experience — the dashboard was web-first, but PG's most active community members lived on mobile
•Richer collection analytics — floor price trends, volume history, and rarity distributions embedded in the portfolio panel
•Notification layer — push alerts for new exchange offers, time-limited claim windows, or floor movements for held tokens
•Community-facing claim leaderboard — showing total community claim progress to create social momentum during the claim window
The deepest lesson from Jirasan was that 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 more than good UI. It required radical transparency at every decision point, and zero ambiguity about what was irreversible.
