The launchpad category had a participation problem disguised as a technology problem
The Web3 launchpad market had grown substantially, with the top fifteen platforms collectively facilitating billions of dollars in raises across ICOs, IDOs, and IEOs. The underlying demand was clear. The participant experience across most of those platforms, however, had not kept pace with that growth. Most launchpads were built and maintained with a developer-first lens, where the priority was functional correctness rather than usability. Information architecture reflected the structure of the smart contract layer rather than the decision-making sequence of the participant. Steps were present but not connected by any guiding logic. Users were expected to hold context independently across a process that gave them little indication of where they were, what had been completed, and what came next.
The vesting model presented a structural problem on the project side. Standard vesting implementations locked tokens until scheduled unlock events, at which point large volumes entered the market simultaneously. The resulting price shocks damaged post-sale token performance and created a predictable pattern that eroded participant confidence in the period following a successful raise. A more liquid approach to vesting was a clear product opportunity, and one that the market had not yet addressed in a way that worked for both projects and participants.
The launchpad market had demonstrated strong demand for Web3 sales. What it had not consistently delivered was an experience that matched the quality of that demand with an equally considered product design.
A visual system built for trust in a category defined by complexity
Most Web3 launchpad interfaces were organized around system capabilities rather than user tasks. Navigation structures exposed backend categories. Data was surfaced in its raw form rather than translated into what a participant actually needed to know. The visual and information design language across the category was dense and developer-oriented, with little evidence of user-centered design thinking applied to the end-to-end experience. The direction taken here was the opposite. The visual system was built around clarity and legibility, and the information architecture was organized around the participant's task sequence rather than the platform's feature set.
As part of the platform's incentive model, a collection of NFTs was designed and airdropped to early participants. These gems, as they were named, were not a project sale or a speculative asset. They were utility NFTs issued by the platform itself, each carrying a defined set of participation privileges redeemable across upcoming sales. The collection required its own visual identity within the broader brand system. Each gem tier was distinguished by color, shape, and rarity classification, with the visual hierarchy designed so that the rarity and relative value of a gem registered quickly once a participant had familiarized themselves with the collection. Each gem's specific properties and privileges were accessible through a dedicated detail view that presented all relevant information in a structured format, covering voucher count, eligible privileges, token standard, and on-chain contract address.
Designing the sale experience around where the user was in the process, not where the protocol was
The participation flow was decomposed into its smallest meaningful units before any interface work began. Every screen had to answer one question, what does the participant need to know or do right now, and what is the single clearest next action available to them. The result was a flow structured around the participant's progression state rather than around the sequence of smart contract operations happening beneath the interface.
The whitelisting step was built as a guided multi-step wizard collecting the participant's name, email, country of residence, wallet address, and intended allocation amount. The committed amount served a deliberate purpose beyond eligibility verification. Aggregating intended allocations ahead of the sale gave project teams a data-grounded basis for forecasting participation volume before the sale opened. Once a participant's application was reviewed, their whitelisted wallet address was surfaced persistently on the sale page, giving them a clear anchor for the transaction they were about to make and removing the error vector of submitting from an unrecognized address.
The sale page separated the participation interface from the project information through a persistent two-panel layout. Token price tiers, allocation limits, accepted currencies, network, and a live progress indicator showing funds raised against soft and hard cap targets were all visible without scrolling. The project's description, team, documents, and full token details including the audit report and compliance certifications were available through a tabbed structure below. Participants had access to everything they needed to evaluate the opportunity and complete the transaction from a single coherent page.
The token selection step translated raw on-chain parameters into a directly actionable interface. Entering a USD amount returned the equivalent token quantity in real time. The participant's current account balance across relevant assets was displayed inline, removing the need to leave the page and check a separate wallet application. The primary action button reflected the participant's exact state at every point in the flow, from Connect Wallet through Give Permission to Use USDT to the final purchase confirmation, so the next step was always the most prominent element on screen.
Redefining early participation through gamification and NFT-gated privileges
The most structurally novel element of the platform was the NFT gem system. The core problem it addressed was behavioral. In a standard launchpad, all applicants join the whitelist queue under identical conditions, with no structural advantage for those who engaged early or participated in previous sales. Gem holders were placed at the top of the whitelist queue, giving them first access when the sale opened, while standard participants waited through a timed window before their turn began. The gem system redefined that dynamic entirely.
The gem collection was structured across four tiers, Regular, Special, Limited, and Partners. Regular and Special gems carried two to three vouchers. Limited gems carried five. Partners gems had unlimited uses. The tier structure was communicated through visual design, with gem color, shape, and rarity badge providing a clear hierarchy across the collection. When a participant connected a wallet holding a gem, the NFT indicator in the wallet bar became active. Opening it surfaced the gem, the remaining voucher count, and a single activation action. The smart contract handled the privilege assignment and voucher decrement transparently, with no visible complexity surfaced to the participant.
The gems were airdropped to early participants as a direct incentive for initial platform engagement. Participants who received a gem ahead of the first sale arrived with an asset that gave them a concrete advantage, a top position in the queue, access to the lowest available price tier, and freedom from the minimum allocation floor that applied to standard participants. The gamified nature of ownership changed the engagement pattern in ways a simple priority tier would not have. Participants tracked their remaining vouchers across sales, anticipated upcoming launches with a specific asset they planned to activate, and returned at higher rates than non-gem holders. Exclusivity and scarcity, embedded in the NFT mechanics, drove retention more effectively than any access-based alternative would have.
On the tokenomics side, a significant amount of research and design went into identifying a novel approach to vesting that addressed the market price shock problem at a structural level. The solution was built on ERC-6551, and was, to the best of our knowledge, the first application of this standard to the vesting problem in the launchpad space. The mechanism was designed to give participants a liquid position throughout the vesting period without introducing the market pressure associated with bulk token unlocks, preserving the economic intent of vesting while removing its most damaging consequence for post-sale token stability.
Giving project teams a forecast instrument, not just an approval queue
The whitelist management dashboard was designed to serve two functions simultaneously. The first was compliance and operational governance, giving project teams a filterable, searchable view of all applicants with inline approve and reject actions, and the tooling to enforce regulatory requirements directly within the workflow. Country-level filtering allowed teams to exclude jurisdictions where token sales are legally restricted or prohibited. Wallet address verification enabled the rejection of flagged or blacklisted addresses. The application structure, which tied each submission to a single verified identity through email, name, and wallet address in combination, provided a mechanism for identifying and rejecting duplicate submissions from the same individual attempting to participate across multiple wallet addresses. Status tracking across total, approved, pending, and rejected applications gave teams a clear audit trail across the full applicant pipeline. Compliance was not a policy layer added after the fact. It was built into the data model and the interface from the start.
Collecting committed allocation amounts from applicants during the whitelisting process meant that by the time a project team was reviewing applications, they had a real-time aggregate of intended participation volume. During the sales on the platform, this figure tracked within a reliable margin of the actual funds raised. That accuracy gave teams a practical instrument for pre-sale decision-making. Soft cap and hard cap targets could be reviewed against committed volume before the sale opened. Token supply available for the sale, the amount to be burned, and the allocation limits per participant could all be adjusted based on observed demand rather than projections. The whitelist dashboard turned the approval process into a pre-sale forecasting instrument, a product strategy decision embedded in the data architecture from the initial specification.
Scope of work delivered
The platform successfully facilitated a number of Web3 sales, raising over one million dollars in combined funding. The gem system produced measurable retention across successive launches, with gem holders returning at higher rates and activating their privileges in each sale. Every sale page surfaced full tokenomics, audit reports, compliance certifications, token allocation breakdowns, and live sale progress in a format designed to reduce cognitive load rather than demonstrate technical depth. The full scope of work delivered covered brand identity, the NFT gem collection, the participant-facing sale flow, the whitelisting wizard, the project detail page system, the whitelist management dashboard, and smart contract coordination for the sale mechanics.