Yokefellow Spaceflight: A Concept Preview for a Future Goal-Based Bucket

Yokefellow Spaceflight is a concept preview for a future Splash bucket aimed at funding a commercial spaceflight or comparable edge-of-space experience for a selected Yokefellow participant.

Current status: Concept Preview Deposits: Disabled Participation: Disabled Selection: Disabled Winner NFT: Not currently issued Prize / travel benefit: Not currently offered

This bucket is not active yet. No participant selection, prize, travel benefit, spaceflight seat, NFT claim, or comparable experience is currently being offered.

The purpose of this preview is to explain how a future active version could work if Yokefellow later finalizes the provider path, legal terms, eligibility rules, funding rules, selection method, NFT redemption path, and operating policy.

The basic ideaCopy link

A future active version would work like this:

• A participant deposits YES into the Spaceflight bucket.
• The bucket immediately captures that deposit as participation.
• The deposit creates ticketed participation records.
• The bucket uses the received YES to work toward a USDC target.
• When the target is met under the published rules, the round locks.
• A winner is selected using a verifiable method tied to onchain variables.
• The winner receives a Spaceflight Winner NFT.
• That NFT becomes the redemption object for the prize or comparable experience.

In plain terms:

Deposit YES → receive tickets → bucket works toward target → winner is selected → winner NFT is issued → winner redeems through the published fulfillment path.

Why this is a Splash bucketCopy link

Yokefellow Spaceflight is designed as a Splash bucket because Splash is the goal-based mechanic.

A Splash bucket has a defined target. It stays open while participation moves the bucket toward that target. Once the target or close condition is reached, the bucket moves into a closeout posture instead of remaining open forever.

For Spaceflight, the concept target is:

1,250,000 USDC

That target is not a live fundraising amount. It is a planning estimate for a future campaign structure.

A real active version would need to confirm the provider, experience cost, travel costs, safety requirements, legal structure, taxes, administration, contingency, and other campaign costs before participation opens.

Splash matters here because this campaign has a clear finish line. The bucket is not meant to run as an indefinite support program. It is meant to work toward a defined campaign budget and then resolve into selection, proof, fulfillment, and closeout.

What happens when someone deposits YESCopy link

For this concept, the active version would use immediate capture.

That means a deposit would not sit as loose, withdrawable bucket credit waiting for the participant to spend later. The deposit would be captured into the Spaceflight participation path immediately.

That matters because this bucket would be a ticketed participation bucket. The act of depositing would be the act of entering the round under the active terms.

Before deposits are enabled, the public policy would need to state clearly:

• Deposits create tickets. YES deposits become ticketed participation records.
• Deposits are captured immediately. The deposit enters the active round instead of remaining loose credit.
• Captured deposits are not casual balance. They become part of the round’s participation ledger.
• Tickets stay in the round. The ticket record is preserved for selection and proof.
• Failed-round rules must be defined. Refunds, cancellation, rollover, or fallback treatment must be published before launch.

This rule is important because users should know what their deposit does before they act.

How tickets would be trackedCopy link

Tickets would be created from captured YES deposits.

The simplest version is:

1 YES = 1 ticket

If a participant deposits 25 YES, the round records 25 tickets for that participant. If another participant deposits 100 YES, that participant receives 100 tickets.

The platform can aggregate tickets by wallet or profile while still preserving the ticket ranges underneath.

Example:

• Alice deposits 25 YES and receives tickets 1 through 25.
• Bob deposits 100 YES and receives tickets 26 through 125.
• Carmen deposits 10 YES and receives tickets 126 through 135.

That creates a clean ticket range system. Each participant can see their ticket count and ticket numbers, while the full round can still be reconstructed and verified.

Before selection, the system can publish or commit to an entries hash. That hash represents the ticket ledger for the round: which wallets received which ticket ranges and how many total tickets exist.

The important point is simple:

Tickets are not vague points. They are derived from captured deposits and preserved as a round record.

How the bucket works toward the USDC targetCopy link

The Spaceflight bucket would receive YES, but the campaign target is denominated in USDC.

That means the bucket needs a conversion mechanism.

In a Splash bucket like this, the bucket can use the YES it receives to create or adjust market orders so the bucket’s YES is sold toward the USDC target.

The active system should calculate:

• how much USDC remains to reach the target
• how much YES the bucket has available
• what price would need to be used for the bucket’s YES sale to meet the remaining target

Example:

• Campaign target: 1,250,000 USDC
• Already raised: 250,000 USDC
• Remaining target: 1,000,000 USDC
• Bucket YES available: 2,000,000 YES
• Needed average sale price: 0.50 USDC per YES

In that example:

1,000,000 USDC ÷ 2,000,000 YES = 0.50 USDC per YES

The bucket can then keep or repost a maker order priced around the remaining target logic, subject to the actual market rules, liquidity, fees, and operator controls.

This does not guarantee execution. It means the bucket’s market posture is tied to the target instead of being random.

The bucket is trying to sell the YES it has received at a price that moves the campaign toward completion.

A future active policy should explain:

• how pricing is calculated
• when orders are posted
• when orders are replaced
• whether partial fills count
• what happens if liquidity is thin
• whether operator review can pause or adjust the process

What counts as reaching the targetCopy link

The target should not be treated as reached merely because enough YES was deposited.

The cleaner rule is:

Tickets come from captured YES deposits. Target completion comes from confirmed USDC raised by the bucket.

That distinction matters.

A user may deposit YES. The bucket may receive YES. Tickets may be created from the captured deposit. But the campaign target is only satisfied when the bucket’s sale process produces enough USDC, or when the active policy defines another valid target-completion condition.

That keeps participation tracking separate from funding completion.

How rounds would workCopy link

Spaceflight should use rounds.

A round is one complete cycle of participation, target progress, selection, winner NFT issuance, redemption, and closeout.

A future round could work like this:

• Round opens. The bucket publishes the round target, terms, eligibility rules, ticket rule, provider status, failed-round policy, and selection method.
• Deposits create tickets. Participants deposit YES into the active round. Deposits are captured immediately and converted into ticket ranges.
• Bucket works toward target. The bucket sells or attempts to sell captured YES toward the USDC target according to the Splash rules.
• Round locks. Once the target or close condition is reached, deposits stop. No new tickets are added after the lock point.
• Selection happens. The winner is selected from the final ticket ledger using the published selection method.
• Winner NFT is issued. The selected winner receives the Spaceflight Winner NFT for that round.
• Redemption begins. The winner follows the published fulfillment path.
• Closeout is posted. The bucket posts proof, final status, and outcome records.

A later round should not blur the record of the prior round. Each round should have its own ticket ledger, winner, NFT, proof, and closeout.

How winner selection would be verifiableCopy link

The winner selection method should be published before participation opens.

A clean version could use this structure:

1. The round closes and no more tickets can be added.
2. The platform creates an entries hash from the final ticket ledger.
3. A future onchain variable is selected as the randomness source.
4. The system combines the entries hash with the onchain value.
5. The result is converted into a winning ticket number.
6. The wallet holding that ticket wins the round.

The onchain variable could be a future block hash, future block number data, or another verifiable chain-derived value.

The important rule is that the input must be defined before selection so the operator cannot choose the randomness source after seeing the ticket ledger.

A simple formula could be:

winner index = hash(entries hash + selected onchain value) mod total tickets

Then the winning index maps to one ticket in the final ticket ledger.

Afterward, users should be able to verify:

• the final ticket ledger
• the entries hash
• the selected onchain variable
• the winning ticket calculation
• the wallet that held the winning ticket

The final active policy would need to state the exact method in more precise technical terms before launch.

The winner NFT and redemption pathCopy link

The active Spaceflight bucket should have one main offering:

Spaceflight Winner NFT

This offering should not be sold directly to the public. It should be issued only to the selected winner after the round is complete.

The NFT should represent the winner’s redemption right for that round, subject to all active terms and eligibility rules.

The NFT should carry or point to:

• round number
• bucket ID
• winner wallet
• winning ticket number
• selection proof
• redemption status
• provider or experience reference where shareable
• claim window if applicable
• transfer restrictions
• fulfillment conditions

The NFT should probably be non-transferable unless legal and provider review say otherwise.

A spaceflight or comparable experience may involve identity, health, safety, travel, provider approval, and legal eligibility. Those requirements usually do not fit cleanly with an unrestricted transferable claim.

The NFT is the carrier. The right is the redemption path. The terms define the limits.

Why immediate capture mattersCopy link

Immediate capture makes the round cleaner.

If deposits remained loose and withdrawable after tickets were assigned, the round could become confusing. A participant might receive tickets, then move funds away. The system would then need to decide whether those tickets still count, whether they should be removed, whether ticket ranges should be renumbered, and how that affects the entries hash.

Immediate capture avoids that problem.

The participant enters the round by depositing. The deposit creates tickets. The tickets stay in the round ledger. The bucket can then use the captured YES to work toward the target.

That does mean the deposit action is more serious. The user is not merely moving YES into a passive bucket. The user is entering a ticketed campaign round.

That is why the active bucket must explain the capture rule clearly before deposits are enabled.

What happens if the target is not reachedCopy link

A future active version must define this before launch.

Possible outcomes could include:

• the round remains open until the target is reached
• the round has a deadline and fails if the target is not reached
• captured deposits are refunded under a defined rule
• captured deposits are routed to a stated fallback purpose
• the operator cancels the round under defined conditions
• the round rolls into a later round under defined conditions

For Spaceflight, this cannot be left vague. A large campaign needs a failed-round policy before deposits open.

This concept preview does not choose the final rule. It shows that the rule must exist.

What this bucket is not right nowCopy link

Yokefellow Spaceflight is not currently active.

It is not currently:

• a raffle
• a sweepstakes
• a fundraiser
• a sale
• a contest
• a prize offer
• an NFT offering
• a travel offer
• a spaceflight offer

It does not currently accept public deposits. It does not currently issue tickets. It does not currently select winners. It does not currently issue a winner NFT. It does not currently create a redemption right.

The current bucket is a concept preview only.

What must happen before activationCopy link

Before this bucket could become active, Yokefellow would need to finalize:

• provider path or comparable experience path
• seat, flight, or experience pricing
• campaign budget
• eligibility rules
• geographic restrictions
• legal structure
• participation terms
• ticket rules
• deposit capture rules
• failed-round rules
• selection method
• winner NFT terms
• redemption process
• safety, medical, travel, and identity requirements where applicable
• tax handling
• proof and closeout standards
• operator responsibilities
• public policy page

Until that work is complete, the bucket should stay in concept preview status.

Why this mattersCopy link

Yokefellow is built to make participation legible before action and verifiable after outcome.

Spaceflight is an ambitious example because it forces the structure to be honest. A campaign like this cannot be explained only with excitement.

It needs:

• a bucket
• a target
• a deposit rule
• a ticket ledger
• a selection method
• a winner object
• a redemption path
• proof
• closeout

That is the point of the preview.

If a future Spaceflight round ever opens, the public should be able to see exactly what they are entering, how tickets are created, how the target is measured, how the winner is selected, what the winner NFT means, and what happens after selection.

Until then, Yokefellow Spaceflight remains a concept preview.