The open-source frontend ecosystem is one of the most valuable yet under-monetized spaces in tech. Thousands of developers spend countless hours building high-quality UI components, design systems, and libraries that power products used by millions, yet receive little to no direct compensation.
Even within ecosystems like shadcn, where 100+ community registries exist, creators continuously ship premium-grade components for free. Despite the immense value being created, there is no native infrastructure that allows developers to monetize their work in a way that reflects real user demand.
HxUI Protocol is a crowdfunding and governance protocol built on Solana, designed to turn open-source UI development into an incentive-aligned economy.
At its core, HxUI Protocol enables communities to directly fund and prioritize what gets built.
HxUI Protocol currently powers 100xUI on devnet, our premium shadcn-based component registry. Through this, users can influence the development roadmap in a permissionless way:
Users can purchase HxUI tokens or earn HxUI Lite tokens by adding 100xUI components via the shadcn CLI to their projects
These tokens are used to vote on candidate components.
Multiple components compete for attention in an open market of demand.
A component is only released if:
It secures the highest votes in the current cycle among competing candidates, with others rolling over to the next cycle. It surpasses a minimum vote threshold, ensuring fair developer compensation.
HxUI aims to become the Gumroad for UI, where creators do not have to guess what will sell. Demand is visible upfront, and the community funds what it wants to see built.
-
HxUI Program (Devnet Deployment)
Solana explorer -
100xUI (Live Implementation)
100xUI is a premium shadcn-based component registry.
HxUI Protocol for 100xUI is implemented at 100xUI Vote component (Devnet) to monetize the registry. -
HxUI LiteSVM Test Sandbox (Replit)
55 tests passed. Run the tests using the Run button after remixing the project, and verify the results in the console. -
HxUI Protocol Source Code (20+ instructions)
Github
HxUI Protocol is built as a set of on-chain instructions that manage the full lifecycle of a component, from creation to selection and release.
Below is a breakdown of the system through its core instructions.
This instruction is invoked by the admin and acts as the bootstrapping step for the HxUI protocol. It is executed once to initialize all core program state accounts and token mints required for the system.
It sets up the following accounts:
HxUI Config
Stores global program parameters such as the delegated admin, tokens_per_vote, and price_per_token, etc.
HxUI Drop Time
Defines a future drop time (e.g., in days or weeks), after which a winner can be drawn from the active candidate components. It acts as a milestone to ensure users have sufficient time to participate before a component is chosen.
HxUI Free Mint Counter
Tracks and enforces global rate limits for free HxUI Lite token minting.
HxUI Mint
Initializes HxUI Token-2022 mint used for paid HxUI tokens, which users purchase to vote on active candidate components.
HxUI Lite Mint
Initializes HxUI Lite Token-2022 mint used for free HxUI Lite tokens, distributed to users adding components via the shadcn CLI. Minting is rate-limited.
HxUI Vault
An account that stores proceeds from HxUI token sales, which can later be withdrawn by the admin.
This admin-only instruction defines a future drop time (e.g., in days or weeks), after which a winner can be drawn from the active candidate components.
Once the drop time has passed, a winner may be drawn using the draw_winner instruction by users or the admin via the 100xUI Voting Page, based on the highest number of votes among active candidates that meet the minimum vote requirement.
The drop time acts as a milestone indicating when the system becomes eligible to select a winner; it does not restrict or stop voting. Users may continue to vote even after the drop time.
This instruction must be invoked before selecting a winner, ensuring users are informed in advance and have sufficient time to participate and influence outcomes.
No winner can be selected before the drop time. Once a winner has been drawn, the current cycle is considered complete, and a new drop time must be created to begin the next cycle. No additional winners can be selected within the same cycle.
This instruction initializes a new candidate account containing the metadata of a proposed UI component. Once created, users can vote for this candidate using HxUI or HxUI Lite tokens, until its status is active.
Candidate Account:
Stores all data related to the proposed component, including name, description, vote_count, its current status, etc.
A candidate can have one of the following 4 statuses:
-
Active
The component is live and eligible to receive votes. -
Winner
The component has won a past drop cycle and has been (or is expected to be) released. -
ClaimableWinner
The component has won a drop cycle with a claim-back offer enabled.
This offer can be enabled at any time while the candidate is active to increase voting pressure and help it overcome low traction.
Users can reclaim 50% of their spent HxUI tokens during the claim-back window. -
Withdrawn
The component has been removed by the admin and is no longer eligible for voting.
Users can reclaim 100% of their spent HxUI tokens during the claim-back window.
This instruction allows users to purchase HxUI tokens by exchanging SOL. These newly minted tokens can then be used to cast votes for preferred active candidate components to influence the next drop.
This instruction allows users to cast one or more votes for active candidate components using purchased HxUI tokens. A user may allocate votes across any number of candidates.
When voting with HxUI tokens, the program will either create a new vote receipt account or update an existing one for the given user–candidate pair.
Vote Receipt Account:
A vote receipt account tracks the total amount of HxUI tokens a user has spent on a specific candidate. There is exactly one vote receipt account per user per candidate.
The vote receipt account’s rent-exempt balance is funded by the HxUI vault, which holds the proceeds from HxUI token sales.
For more details, see: Why and How does the HxUI vault afford the rent-exempt balance for vote receipt accounts?
This instruction allows users to register for minting free HxUI Lite tokens. It creates a Free Mint Tracker account to track the individual rate limit for minting free tokens per user.
Free Mint Tracker Account:
This account stores the next_mint_timestamp and an unregistered boolean to manage a user’s eligibility for free minting. It ensures users can only mint after the allowed interval defined in the HxUI Config free_mint_cooldown, and tracks whether they have opted out of the free minting system.
This instruction is invoked when a user adds a 100xUI component to their project using the shadcn CLI. It mints free_tokens_per_mint HxUI Lite tokens, as defined in the HxUI Config, to the user’s associated HxUI Lite token account (ATA). These tokens can then be used to vote on active candidate components.
Minting is permitted only if the following conditions are met:
- The user has an active Free Mint Tracker account (created during registration for free minting via 100xUI ).
- The user has an associated HxUI Lite token account (ATA), which can be created during registration.
- The user has not exceeded the personal rate limit defined by their Free Mint Tracker account.
- The global minting limit has not been reached, as defined in the HxUI Config
free_mints_per_epoch.
This instruction allows users to vote for an active candidate component using HxUI Lite tokens.
Unlike HxUI token voting, no vote receipt accounts are created when voting with HxUI Lite tokens.
This instruction allows a user to deregister from minting free HxUI Lite tokens,
Once deregistered, the user is no longer eligible to mint free HxUI Lite tokens. They may also close their Free Mint Tracker account and claim the associated rent-exempt balance (referred to as the deposit), but only after the cooldown period defined in the HxUI Config free_mint_cooldown from their most recent mint.
This instruction allows a user to cancel a pending deregistration request.
Upon cancellation, the user regains eligibility to mint free HxUI Lite tokens by adding components.
This instruction allows a user to close and claim the rent-exempt balance from their Free Mint Tracker account.
The balance can only be claimed after the user has deregistered and once the cooldown period defined in the HxUI Config free_mint_cooldown has passed since their most recent mint.
This instruction selects a winner based on the highest number of votes among active candidate components that meet the minimum vote requirement defined in the HxUI Config min_votes_to_be_winner.
It can be invoked by users or by the admin, but only after the drop_timestamp defined in the HxUI DropTime account has passed.
Once a candidate is selected as the winner, the corresponding component is expected to be dropped by the admin.
This instruction allows the admin to remove an active candidate component. This action is expected to be used sparingly and only in exceptional cases, such as technical limitations in building the component or insufficient user traction.
If users have spent paid HxUI tokens voting for the withdrawn candidate, the admin must open a claim-back window using open_claim_back_window instruction for a considerable duration. During this period, users can reclaim their HxUI tokens using the claim_back_tokens instruction.
After the claim-back window has closed, users can no longer reclaim their tokens. The admin may then clean up any remaining (unclaimed) vote receipt accounts, transferring their rent-exempt balances back to the vault.
This admin-only instruction opens a claim-back window for a candidate with status Withdrawn, or ClaimableWinner, until a specified timestamp.
During this window, users can reclaim their spent HxUI tokens on the specific candidate using the claim_back_tokens instruction:
- Withdrawn candidate: Users can reclaim 100% of the HxUI tokens they spent.
- ClaimableWinner: Users can reclaim 50% of the HxUI tokens they spent.
Tokens can only be claimed during the claim-back window.
This instruction allows users to reclaim 100% of the HxUI tokens they spent on a candidate if the candidate is Withdrawn, or 50% of the HxUI tokens if the candidate is a ClaimableWinner. Tokens can only be claimed during the claim-back window opened by the admin. Invoking claim_back_tokens also closes the corresponding vote receipt account and returns the rent-exempt balance to the HxUI vault.
Note:
- Votes cast using HxUI Lite (free) tokens are not refundable, as no receipt accounts are created to track such usage.
- Vote receipt accounts cannot be closed by the admin until the claim-back window has closed.
This admin-only instruction allows the application of incentive mechanisms to a candidate component, instead of withdrawing it due to low traction.
Currently, the program supports a single offer type: Claim back if winner. Under this offer, users who vote for the candidate using paid HxUI tokens are eligible to reclaim 50% of the tokens they have spent or will spend if the candidate is ultimately selected as the winner.
The claim-back process for this offer follows the same pattern as token recovery upon withdrawal, using the claim_back_tokens instruction.
Once this offer is applied to a candidate, it cannot be reverted.
This admin-only instruction is used to close vote receipt account associated with a non-active candidate. The admin can build transactions with multiple close_vote_receipt instructions to clean up all vote receipt accounts for a given candidate.
Closing a vote receipt account transfers its rent-exempt balance back to the HxUI vault, which can later be withdrawn by the admin.
When can vote receipt accounts be cleared:
- Active candidate: Never.
- Winner candidate: Immediately after a winner is selected.
- Withdrawn candidate and ClaimableWinner: Only after the claim-back window has been opened and subsequently closed.
This admin-only instruction is used to close a non-active candidate account, clearing all associated state and history for that candidate and reclaiming the rent-exempt balance back into the HxUI vault.
Note:
- Only a non-active candidate can be closed, and only if the candidate's vote receipt count (
receipt_count) is 0.
This admin-only instruction allows withdrawal of funds from the HxUI vault, which holds the proceeds from selling HxUI tokens.
A portion of the vault balance is reserved to cover the rent-exempt requirements of all potential vote receipt accounts that could be created from the current circulating supply of HxUI tokens. The remaining (unreserved) balance can be withdrawn immediately.
This admin-only instruction allows the admin to update the global program parameters stored in the HxUI Config account, such as pricePerToken and tokensPerVote and to delegate a new admin.
Using Privy allows seamless onboarding of traditional Web2 users through embedded wallets with familiar authentication flows, reducing the friction typically associated with wallet setup. This aligns with the long-term vision of 100xUI, enabling anyone to participate without prior blockchain experience.
This design avoids friction for users by eliminating the need to pay additional rent when voting for new candidates or managing receipt account cleanup themselves.
The HxUI vault funds the rent-exempt balance required to create vote receipt accounts (one per user–candidate pair) for votes cast using paid HxUI tokens.
This is possible because the system guarantees that the cost incurred by a user per vote with HxUI tokens is always greater than the minimum rent-exempt balance required to create a vote receipt account.
As a result, a portion of the user’s spend is implicitly reserved by the vault to cover the rent for these accounts.
The vault maintains a reserved amount, which is:
The total rent required to exempt all possible vote receipt accounts that can be created from the current circulating supply of HxUI tokens.
- This reserved portion cannot be withdrawn immediately
- The remaining balance is freely withdrawable by the admin
The reserved amount becomes withdrawable only after:
- Vote receipt accounts are closed via:
claim_back_tokens(user-driven), orclose_vote_receipt(admin cleanup)
- The rent-exempt balance is returned back to the vault
Current configuration:
-
price_per_token = 0.001 SOL -
tokens_per_vote = 2 -
Cost per vote =
0.001 × 2 = 0.002 SOL -
Minimum rent-exempt balance of vote receipt account (space = 21) =
0.00103704 SOL
✅ Invariant holds:
Cost per vote ≥ rent-exempt requirement
Let’s say Alice buys 10 HxUI tokens for 0.01 SOL.
- Maximum votes possible =
10 / 2 = 5 - Maximum vote receipt accounts = 5
Vault state:
- Proceeds from HxUI token sales =
0.01 SOL - Reserved =
0.0051852 SOL - Withdrawable =
0.0048148 SOL
Now, if Alice casts 5 votes across 5 new candidates:
- 5 vote receipt accounts are created
- Rent is paid from the vault (already reserved)
Once the candidate lifecycle completes (Winner / Withdrawn / ClaimableWinner):
- Vote receipt accounts are closed via:
claim_back_tokens(user-driven), orclose_vote_receipt(admin cleanup)
- The rent-exempt balance is returned back to the vault and becomes withdrawable.
The separation of mints is done to clearly distinguish between paid participation and free participation in the voting system.
Let’s assume a single unified mint, called a Hybrid HxUI Mint:
- Alice buys 1 token (paid)
- Alice mints 1 token for free
- Total balance = 2 tokens (indistinguishable in origin)
Now, if Alice casts a vote:
- A vote receipt account must be created to track spending and enable refunds (e.g., if the candidate is withdrawn), without being able to distinguish whether the tokens were bought or minted for free.
- However, the cost incurred by Alice may be less than the rent-exempt balance required for the vote receipt account.
This breaks a core invariant of the system:
Cost per vote ≥ rent-exempt balance requirement
Because free tokens introduce value without economic backing, the protocol cannot reliably fund the rent for receipt accounts.
This is why HxUI Lite votes are non-refundable, as no receipt account is created to track their usage.
-
Ship to Mainnet
Complete audits, optimizations, and deploy the HxUI Protocol to Solana mainnet. -
Help UI Creators Earn
Empower UI libraries and 100+ shadcn registries to monetize their work through the HxUI Protocol on Solana. -
Make Web3 Invisible for Users
Onboard traditional Web2 users seamlessly into the Web3 ecosystem by upgrading 100xUI to use Privy’s embedded wallets.
(100xUI already uses Privy for external wallet connections.) -
Grow the Ecosystem
Expand adoption through developer communities and social channels.