HyperBukit whitepaper

BUKIT Token Whitepaper — Version 1.1, as built

Date: October 2026
Network: Solana
Published by: Hyperbukit LLC, a Florida limited liability company

This version describes the platform as it runs at launch. It replaces Version 1.0 (July 2026), which described a design that has since changed. Where this paper and the live site disagree, the site and the chain are the record, and this paper will be corrected.

Abstract

Most people carry a list of experiences they want to have, and most of that list never gets done. The reason is rarely a lack of desire; it is coordination, cost and access. HyperBukit is a platform built to close that gap. Users keep a Bukitlist of goals, and the platform connects those goals to real-world events run by independent hosts.

The core mechanic is the event bucket: an escrow that pays the host only when enough people have committed before a deadline. If the goal is not met, everyone is refunded in full and nothing is taken. For events funded with Bukit, that rule is enforced by a smart contract on Solana. For events paid in dollars, the same rule is enforced by the platform through Stripe, with cards held or saved until the event fills.

Bukit (BUKIT) is the platform's utility token, closer to an arcade credit or a ticket than to a financial instrument. It carries no promise of profit, no ownership and no dividend. Its supply was minted once, at 100,000,000, and can only shrink: every filled Bukit event burns a share of its fee, and every redemption burns the whole price.

1. Introduction: the bucket list problem

Ask people what is on their bucket list and they answer at once. Ask why they have not done it yet, and the answer is a mix of three frictions:

• Coordination. Many experiences, such as a group sailing trip, a party bus or a niche clinic, only make sense for the organizer if enough people show up. Motivated people rarely find each other in time.
• Risk. Hosts carry the risk of an event that does not sell; attendees carry the risk of paying for something that is cancelled, with a slow or unclear refund.
• Discovery. People do not know an event exists that matches what is on their list.

Ticketing platforms are built around the host: an undersold event either runs at a loss or is cancelled by hand. Crowdfunding introduced threshold funding, which is close to HyperBukit's model, but the rule is enforced by a company's policy.

HyperBukit's premise: an event should happen when enough people have committed to it, and the outcome should follow a published rule, not anyone's discretion. For Bukit events, the rule is code anyone can inspect. Once a bucket meets its goal, nobody — not the host, not HyperBukit — can stop it from paying out.

The bucket list framing is deliberate. A ticket is a transaction; a step toward a goal on your own list is a reason to show up.

2. Platform overview

2.1 The Bukitlist

A personal list of goals, kept with an email account or a Phantom wallet. A goal's notes, steps and pictures are private by default; making a goal public shares it, with the owner masked, in the Suggested tab.

2.2 Event discovery

Explore shows events near you and events that match the goals on your list. A goal and a matching event link to each other.

2.3 Two roles

• Attendees get tickets: free, by card or Apple Pay, or with Bukit.
• Hosts are independent people and organizations who run the event. HyperBukit provides the listing, the escrow, the tickets and the check-in; the host provides the experience.

2.4 Four ways to fund an event

A host may also chain one event to another (Bucket Domino): the second event lists right away but sells nothing until the host opens it, after seeing interest in the first.

2.5 Tickets and check-in

Every ticket gets its own QR code, sent by email where an address is known and available as an Apple Wallet pass. Free and card tickets carry a secret code, so a QR cannot be rebuilt from public data. The host or a co-host scans each ticket at the door and marks it arrived.

2.6 Wallets

HyperBukit uses Phantom. On an iPhone, the site opens in the Phantom app's own browser, where it can sign. People without a wallet can use every free and dollar feature with an email account.

3. The event bucket

3.1 The flow

1. A host creates an event with a goal (a token amount, or a minimum number of attendees, or both), a funding deadline, and optionally a capacity.
2. Attendees commit to tickets before the deadline.
3. The bucket resolves one of three ways:
   • Fills. The moment the goal is met, the bucket can be settled and the host is paid, less the fee in section 5.3. Settlement is permissionless: anyone may trigger it, and the program decides the amounts and the recipient.
   • Misses its deadline. Every deposit becomes refundable in full, with no fee. HyperBukit's crank returns deposits automatically; any attendee can also claim their own.
   • Is called off by the host before it fills (section 3.4). Every deposit becomes refundable at once.

3.2 Fill conditions

The program compares its own records — the deposited total and the number of depositing wallets — against the goal and the attendee minimum fixed at creation. Neither is supplied by whoever calls it. A bucket that met its goal can always be settled, even after the deadline, so a funded event never strands its money.

3.3 Leaving before the bucket fills

A host chooses at creation, before any deposit, whether attendees may withdraw early ("Allow refunds before the bucket fills"). The choice is recorded on chain and cannot be changed afterwards. Where it is allowed, an attendee may take their whole deposit back, with no fee, until the bucket reaches its goal; from that moment, withdrawals close for everyone. Where it is not allowed, commitments are locked until the bucket resolves.

The reason for locking at the goal: a host, and every other attendee, needs the running total to be real. Before the goal, freedom to leave costs nobody anything; after it, the event is happening and the money is committed.

3.4 Calling an event off

A host may call off an event that has not yet met its goal. On a split-funded event, HyperBukit's treasury, acting as the event's fill authority, can do the same on the host's instruction. Calling off marks the bucket refunded, closes it to new deposits, and lets every attendee take their deposit back at once, in full.

Once a bucket has met its goal, nobody can call it off. That is the promise attendees rely on: a met goal pays the host, and no host or platform can take that back. Before the goal, a host calling off leaves every attendee exactly where a missed deadline would have, only sooner.

3.5 Deadlines

• A Bukit bucket's funding deadline must be at least 1 hour in the future. The program enforces this, from a configurable floor.
• Free and dollar events need at least 15 minutes' lead time.
• Card sales close 15 minutes before an event's funding deadline.

3.6 Split-funded events and the fill floor

The chain cannot see card payments, so on a Both event the host delegates the fill decision for that one bucket to HyperBukit's treasury. The delegation is recorded on chain at creation. The treasury may release the bucket only before its deadline, only to the host, and only when the combined minimum is met.

Every authorized fill names the token amount the tickets were priced on (min_current_amount). If a last-moment withdrawal leaves less in the bucket than that, the fill fails instead of paying the host short, and it is retried once the numbers agree.

3.7 Card tickets

A card ticket is charged at once, held (authorized and captured only if the event fills), or saved and charged only if it fills, depending on how far away the event is. If a saved card is declined when the event fills, the guest has 48 hours to pay another way. If that leaves the event short at its deadline, the event waits out those 48 hours instead of refunding everyone: the host is told and can cover the shortfall, resell the ticket (sales reopen for the window), or let it run out, in which case every guest is refunded in full.

4. The Bukit token

4.1 What it is for

• Event participation. Bukit is deposited into event buckets to get a ticket.
• Redemptions. The Redemption Center exchanges Bukit for physical items. Paying burns the tokens.
• Rewards. Small amounts are paid for using the site (section 5.2).

Bukit is not an investment, an ownership stake in Hyperbukit LLC, a right to profits or dividends, or a general-purpose payment instrument.

4.2 How to get Bukit

• Deposit SOL on the site at a fixed internal rate of 1 SOL = 100 BUKIT. There is no deposit fee; the whole amount is credited at that rate, paid from the treasury float. One deposit is capped at 1,000 SOL. This is one-way: HyperBukit does not buy Bukit back.
• The open market. A SOL/BUKIT pool on Raydium exists since 4 October 2026. Hyperbukit LLC does not operate it, does not make a market and does not quote prices there.
• Rewards and referral credit, paid from the same float.

There is no fiat purchase of Bukit. Dollars on HyperBukit pay for card tickets and support payments, never for tokens.

4.3 Legal positioning

• No promise of return: holding Bukit entitles no one to profit, interest or a share of revenue.
• No ownership: Bukit is not equity or membership in any entity.
• No platform buy-back: the only exit is a third-party market HyperBukit does not control.
• Not money transmission: Bukit is an access mechanism inside one platform.

Regulatory treatment of utility tokens varies by jurisdiction. Nothing here is a legal opinion (section 11).

5. Token economics

5.1 Supply: minted once

The mint authority is retained, not renounced. No further minting is planned; any minting would need the Ledger to sign and would be visible on chain to anyone. Since nothing new is minted, every burn shrinks the supply for good.

An earlier mint (0 decimals, held on a server key) was retired on 11 August 2026: relabelled HyperBukit (Retired) / BUKITOLD, its mint authority revoked, and its four holders given the new token one for one.

5.2 Where the supply is

There is no team, investor, pre-sale or farming allocation. Everything not in circulation is held by Hyperbukit LLC, 99% of it offline. The float is topped up from the Ledger by a Ledger-signed transfer when it runs low; a compromise of the server key can reach only the float. Live figures are on the dashboard.

Bukit enters circulation only from the float, through three paths:

• SOL deposits at the fixed rate (section 4.2).
• Earn rewards: 0.1 BUKIT per qualifying action, at most 1 BUKIT per person per day.
• Referral credit on split-funded events, paid in Bukit, capped per payout.

5.3 The fill fee and the burn

When a Bukit bucket fills, the program keeps back a fee before paying the host. Today the fee is 3%: 1% is burned and 2% goes to the treasury, so the host receives 97%. A bucket that does not fill pays no fee.

The burn uses the SPL Token program's own Burn instruction, not a transfer to a "dead" wallet, so the mint's reported supply is always exact and anyone can verify it.

The fee is set in an on-chain configuration that the program bounds (section 9):

• The fee can never exceed 40% of a fill.
• The burn share can be anything from 0% up to the whole fee; the treasury receives the rest.
• A change is announced at least 14 days before it takes effect and is visible on chain. The aim is for the community to vote on it.

5.4 Fees at a glance

5.5 Supply over time

Supply cannot grow, so the direction is fixed: down, by every fill's burn share and every redemption. How fast depends only on activity. Circulating supply moves the other way as the float pays deposits and rewards, which is why the dashboard shows both.

6. Liquidity

A SOL/BUKIT pool on Raydium (pool GmwiaLkGn2dezFfUctRuTgUdc6bFSU6JEPeRzpPSW5yy) was seeded on 4 October 2026. It is small. Its price is set by trading, not by HyperBukit, and can differ from the internal deposit rate. There is no farming or liquidity-reward program.

Providing liquidity carries impermanent loss: if the price moves, a provider's position can end up worth less than holding the two tokens. Hosts paid in Bukit can convert through the pool or through Jupiter; HyperBukit links to them and is not a party to the swap.

7. Technical architecture

7.1 Why Solana

Fast finality and fees of a fraction of a cent make per-ticket, on-chain deposits practical. Solana's SPL Token standard and its exchange ecosystem (Raydium, Jupiter) are what the token and the escrow build on.

7.2 Deposits

A SOL deposit is one transaction the server builds and the user signs: SOL goes to the treasury wallet, and the server then pays the matching Bukit from the float. Each purchase is recorded by its transaction signature, so a replay cannot pay twice. The server refuses a deposit the float cannot fill, before anything is signed.

7.3 The escrow program

One Anchor program, GkiS88a14Ax2SX5FNZbUFhfDhDqXMauxQriy9izyy8Wf, holds every event bucket. Its accounts:

• Config: the admin, the fee recipient, the fee split and the deadline floor.
• EventBucket: per event: the host, the mint, the goal, the deadline, the attendee bounds, the running total, the attendee count and the status.
• AttendeeRecord: per wallet per bucket: the amount and the attendee number.
• FillAuthority: optional, per bucket: the delegate allowed to settle a split-funded event.
• Gate: optional, per bucket: keeps a chained event closed until its host opens it.
• WithdrawPolicy: optional, per bucket: present only if early withdrawal is allowed.

Its fifteen instructions:

• Setup: initialize_config, update_config.
• Bucket: create_event_bucket, set_fill_authority, set_gate, open_gate, allow_withdraw.
• Money in: deposit.
• Money out:
  • fill_and_release (permissionless);
  • fill_and_release_authorized (the delegate, with the fill floor);
  • withdraw (an attendee, before the goal, where allowed);
  • cancel_bucket (the host or the delegate, only while short of the goal);
  • refund (after a miss or a call-off).
• Clean-up: close_bucket, close_attendee_record, which return rent once a bucket is settled.

On a fill, the program splits the vault in one transaction: the burn, the treasury share and the host's share. Each is computed by the program from its own records. An attendee record is closed on refund, so it cannot be refunded twice.

7.4 Card payments

Card and Apple Pay tickets run through Stripe. Hyperbukit's own events take payment on the LLC's Stripe account; other hosts are paid through Stripe Connect accounts of their own. Every card movement (charge, capture, refund) is recorded once, keyed by Stripe's own id, so a repeated webhook cannot act twice.

7.5 Operations

A scheduled crank, run every few minutes by a Cloudflare worker, settles filled events, returns deposits after a miss or a call-off, charges saved cards and sends the mail. A health endpoint reports the cluster, the configuration, the float and the crank's last run.

8. Transparency

The dashboard at hyperbukit.com/dashboard reads the chain directly:

• total supply, cold storage, the treasury float and the amount in circulation;
• Bukit burned all-time, the current burn rate, and net flow over seven days;
• events filled and the Bukit price.

Pool figures are read on Raydium itself. Every fill, refund and burn is a public Solana transaction anyone can look up on an explorer.

9. What is fixed, and why

9.1 What "fixed" means here

Some rules are compiled into the escrow program's code. They change only through a program upgrade, which needs the LLC's Ledger to sign and is public on chain. The upgrade authority will never be set to "final". A frozen program could never fix a bug, and an upgrade is visible to anyone watching.

Within the code, the configuration admin may move a few parameters, but only inside bounds the code enforces. At launch the admin is the deploy key; it moves to the Ledger once a Ledger-signing tool exists. Every change is announced before it takes effect; community voting on the parameters is the aim.

9.2 Fixed in the program, and the reasons

• The fee can never exceed 40% of a fill. 40% is about the most that ticketing platforms take today. The ceiling means the protocol can never take more of an event than the incumbents take of a ticket, so it cannot become more extractive than the market it replaces.
• The burn share runs from 0% to the whole fee.
  • 0% makes a fee-free event possible.
  • A high burn is a lever to shrink supply if the token's environment ever calls for it.
  • Where the split sits inside the cap is the governed, announced parameter.
• A met goal cannot be stopped. cancel_bucket works only while the bucket is short of its goal. Above it, nobody can call it off. Below it, calling off returns every deposit at once, so nobody is worse off than after a missed deadline.
• A split-funded fill cannot pay the host short. The fill floor (section 3.6) makes a fill fail rather than settle below the amount the tickets were priced on.
• The withdraw choice is made once, per bucket. Whether attendees may leave before the goal is fixed before the first deposit and cannot be added or removed afterwards. That way nobody's terms change after they commit.
• There is no refund instruction after a fill. The vault has paid the host. A refund after that is the host's own transfer, which HyperBukit records but the program never sees.
• There is no on-chain pause. The app can stop offering new buckets, but it cannot freeze money already committed. Every refund and fill path stays open to the people it belongs to.
• One attendee record per wallet per bucket. The app may count several tickets on one record; the program counts wallets toward the attendee minimum.

9.3 Fixed in the token

• Supply: 100,000,000, minted once. The mint authority is retained on the Ledger, not renounced, so a future decision to mint would need hardware-wallet approval and would be public.
• Freeze authority: none, permanently.
• The retired mint has its mint authority revoked, and its metadata authority sits on the Ledger, so it can never be relabelled as the live token.

9.4 Not fixed

• The fee rate and split, inside the bounds above. Changed by the config admin and announced at least 14 days ahead.
• The fee recipient and the deadline floor. Changed by the config admin.
• The card processing fee. A platform setting, not on chain; changed only with notice in the Terms.
• The program code itself. Changed only by a Ledger-signed, public upgrade.

10. What is live

• The Bukitlist, goal matching, public profiles, follows and comments.
• Free, Dollars, BUKIT and Both events, with co-hosts, Bucket Domino, discount codes and referral rewards.
• A QR code per ticket, email delivery, Apple Wallet passes, and door check-in.
• SOL deposits at the fixed rate, earn rewards, and the Redemption Center.
• The escrow program described in section 7.3, and the public dashboard.

Changes will be published as new versions of this paper.

11. Legal disclaimer

Bukit is a utility token for access and participation on HyperBukit. It is not a security, not an investment product and not a promise of financial return. Purchasing, holding or using Bukit gives no ownership interest, no profit share and no claim on Hyperbukit LLC's revenue or assets, and Bukit should not be acquired with an expectation of profit from the efforts of others. HyperBukit is not responsible for conversions users or hosts make on third-party exchanges. Fees and parameters can change within the bounds in section 9, with notice. Past supply, burn or issuance activity says nothing about the future. Regulatory treatment varies by jurisdiction, and each user is responsible for the laws that apply to them. Nothing in this document is legal, financial, tax or investment advice. The Terms of Service at hyperbukit.com/terms govern use of the platform.

12. Glossary

• Bukitlist: a user's list of goals.
• Event bucket: the escrow for one event, holding deposits until it fills, misses its deadline or is called off.
• Goal: what a bucket needs to fill: a token amount, an attendee minimum, or both.
• Fill: settlement of a bucket that met its goal; the host is paid, less the fee.
• Call off (cancel_bucket): the host ending a bucket that has not met its goal; every deposit becomes refundable at once.
• Withdraw policy: the per-bucket choice, fixed at creation, of whether attendees may leave before the goal.
• Fill authority: the delegate, HyperBukit's treasury, allowed to settle a split-funded bucket once the combined minimum is met.
• Fill floor (min_current_amount): the amount an authorized fill must find in the bucket, or it fails.
• Gate: the lock that keeps a chained event closed until its host opens it (Bucket Domino).
• Treasury float: the 1,000,000 BUKIT working balance that pays deposits and rewards.
• Crank: the scheduled job that settles, refunds and charges on time.
• BUKIT: the SPL utility token of HyperBukit.
• SPL Token: Solana's standard token program.
• PDA (program-derived address): an account address derived from a program and seeds, with no private key; only the program can act for it.
• Basis points (bps): hundredths of a percent; 100 bps = 1%.
• Raydium / Jupiter: a Solana exchange pool and a swap aggregator, operated by third parties.
• Ledger: the hardware wallet that holds the mint authority, the program's upgrade authority and 99% of the supply.