Yokefellow - Governance & Future Structure
Raise / Use of Proceeds
The public structure for the YES sale, proceeds routing, use-of-proceeds buckets, and follow-through records.
Raise / Use of Proceeds
Rewritten as a stronger public-structure paper aligned to Yokefellow’s bucket model, governance posture, and platform-expansion plan.
| Operating rule. The raise should be shown through Yokefellow’s own bucket structure from sale through routing through follow-through. A vague raise page plus private bookkeeping is not good enough for the kind of system Yokefellow is trying to prove. |
|---|
1. What This Paper Is
This paper explains how Yokefellow should raise capital, how that raise should be shown through Yokefellow’s own structure, and how the resulting proceeds should be routed, tracked, and reported afterward. It is not the Whitepaper, not the YES Tokenomics Paper, and not the HQ plan. Its role is narrower and more practical: define the raise structure, define the proceeds architecture, and define the visibility rules that should keep the whole thing legible over time.
A raise matters too much to be handled as one vague announcement plus scattered later updates. If Yokefellow is serious about programmable participation, visible terms, and post-action proof, then one of the most important financial events in the company’s life should be shown through that same discipline rather than disappearing into ordinary startup fog.
2. The Core Raise Rule
Yokefellow should not raise through vague promises and then explain the money later through private bookkeeping and occasional storytelling. The raise should be visible through the same kind of public structure Yokefellow is asking other people to trust.
That means three things should be legible together: the sale itself, the routing of proceeds, and the later record of what those proceeds actually did. The raise is therefore not only a financing event. It is also one of the clearest product demonstrations Yokefellow can make.
3. What the Raise Is Funding
At a high level, the raise is meant to fund the labor, infrastructure, buildout, and shared assets required to move Yokefellow from a working core system into a stronger operating platform with broader first-party surfaces and stronger real-world capacity.
That includes continued work on the core Yokefellow app, first-party app buildout, developer and partner rails, technical infrastructure, AI systems, in-house engineering labor, HQ buildout and operating capacity, content and production capability, operator and partner formation, and other governed platform-expansion work tied to the roadmap.
The point is not only to fund one isolated launch moment. The point is to fund the capacity that lets Yokefellow keep building, demonstrating, documenting, operating, and expanding through repeatable structures.
4. What Is Being Raised
The raise should be described as the company’s YES sale structure within the fixed YES framework, not as open-ended token creation and not as an arbitrary token event. YES already has a fixed yearly emission structure, a bounded supply schedule, and a defined role inside Yokefellow as the native participation rail across buckets and apps.
The raise paper should therefore keep the hierarchy clear. Yokefellow is the system. YES is the token used within that system. The raise is a company-controlled sale structure inside that fixed YES framework. This paper is about how that sale should be shown and how its proceeds should be governed, not about changing the protocol-level YES cap itself.
5. What This Sale Does Not Mean
This paper should also be explicit about what the raise is not claiming. It is not a paper for open-ended issuance. It is not a promise that participation in the raise automatically means ownership in Yokefellow itself. It is not a claim that every future app, bucket, or right on the platform becomes part of one undifferentiated raise package merely because the company is raising money. And it is not a substitute for the actual sale terms, disclosures, restrictions, or legally required documentation that govern the live sale when launched.
The practical rule is simple: this paper defines the structural model of the raise. The live sale still depends on the controlling terms, disclosures, eligibility conditions, and lawful sale materials that are actually posted with it.
6. Why the Raise Must Use Yokefellow’s Own Structure
Buckets are already Yokefellow’s core programmable funding and participation surfaces. They are where purpose, terms, offerings, records, and later proof are supposed to become legible together. A raise that ignores that structure would weaken the platform’s main thesis at the exact moment Yokefellow is asking people to believe it most.
If Yokefellow says participation should be legible before action and verifiable afterward, then the company’s own raise should be one of the strongest examples of that rule. The raise should not vanish into a generic treasury statement. It should be shown through sale buckets, proceeds buckets, updates, receipts, and proof in a way other people can actually follow.
7. The Sale Bucket Layer
The first layer is the sale bucket or sale-bucket family. This is the public entry surface for the raise. It should tell people what is being sold, why the raise exists, what the raise is meant to accomplish, what participants are entering, what disclosures govern that path, what later reporting the raise commits to show, and what governance or approval structure applies before and after Congress becomes active.
In most cases, a raise of this kind should be shown through a splash-style posture rather than treated like an endless open surface. A company raise usually has a target, a round logic, or a controlled sale window. That kind of structure fits splash better than vague perpetual openness. Multiple sale buckets or staged sale buckets may still be used where rounds, tranches, or visibly distinct sale windows make sense, but each one should remain legible as part of one coherent raise record rather than a scattered set of unrelated fundraising pages.
The sale bucket is not where all later operating spend should remain parked forever. Its job is to present the raise cleanly, collect participation under visible rules, and provide the public record of how the sale itself progressed.
8. The Proceeds Layer
The second layer is the proceeds architecture. This is where Yokefellow has to do better than a normal startup “use of funds” paragraph. The money raised should not disappear into one vague treasury explanation. It should be routed into named use-of-proceeds buckets so people can see what capital is meant to support and what kind of record each destination is expected to carry later.
That means the raise should map into a real bucket architecture rather than a generic sentence about operations, growth, and marketing. Some proceeds should go to organization-level buckets. Some should go to project buckets. Some may later go to event buckets. The correct question is not whether every dollar needs its own page. The correct question is whether every material use category has a visible destination and a readable record.
This is where the paper becomes stronger than the current draft. It should not stop at saying “use proceeds buckets.” It should explain the actual bucket families that make the routing structure intelligible.
9. The Core Proceeds Architecture
At the organization level, Yokefellow already has the clearest bucket families for company-wide routing: Reserve Fund, OPEX, and CAPEX. Those should be treated as the primary organization buckets for raise proceeds unless and until a better governed structure is adopted later.
Reserve Fund should function as the bridge and stability bucket. OPEX should function as the recurring operating bucket. CAPEX should function as the durable buildout and equipment bucket. Those three categories already create a cleaner structure than one vague company treasury because they distinguish bridge capital, recurring use, and durable asset buildout instead of blurring them together.
Bucket family map
The table below is the clearest way to show the default proceeds families. Final names and allocations can still be locked later, but the structure should read something like this.
| Bucket family | Primary purpose | Typical examples | Public record should show |
|---|---|---|---|
| Reserve Fund | Bridge and controlled staging | Timing gaps, planning deposits, controlled holding before deployment, transition routing | Why funds are parked here, what they are waiting on, when they moved onward |
| OPEX | Recurring operating support | Labor, contractors, recurring software and services, support, administrative operating cost | Periodic use summaries, material spend classes, continuing operating purpose |
| CAPEX | Durable buildout and asset acquisition | Servers, storage, studio gear, fixtures, network equipment, durable hardware | What was acquired, why it matters, and where it strengthened capacity |
| Project Bucket | One material initiative with its own record | HQ buildout, core-platform hardening, Auction House, Lounge, Dapp Maker | Milestones, updates, receipts, proof, and current execution status |
| Event Bucket | One event or showcase with a defined window | Builder workshops, partner demos, public showcases, launch events | Event purpose, budget logic, outputs, closeout, and proof |
10. Organization Buckets and What They Should Mean
Reserve Fund should not be treated as a hiding place for vague future use. It should be the working-capital bridge and controlled staging bucket. It can hold funds that need to sit between raise collection and later deployment, help seed planning work before a project bucket fully opens, support timing gaps between commitment and execution, and preserve operating flexibility where the company needs a visible bridge rather than immediate final spend. But it should remain legible as a bridge bucket, not a place where accountability goes to die.
OPEX should hold recurring operating use: in-house labor, contractors, recurring software and service costs, support work, administrative operating spend, and other ongoing costs required to keep Yokefellow building and operating. OPEX is where the company shows that recurring platform work has a real support base rather than being hand-waved as invisible overhead.
CAPEX should hold durable buildout and asset acquisition: servers, storage, network equipment, studio gear, furniture and fixtures, durable hardware, space-improvement components, and other longer-lived purchases that strengthen the company’s capacity over time. CAPEX matters because HQ and platform capacity are not only salary stories; some of the raise is supposed to become durable operating capability.
11. Project Buckets and Why They Matter
Organization buckets alone are not enough. They are necessary, but they are too broad to carry every major buildout story by themselves. The raise should also route into project buckets where a particular initiative is important enough to deserve its own visible plan, updates, receipts, and proof.
Yokefellow HQ should almost certainly be its own project bucket because it is not merely a recurring operating line item. It is a capital-and-capacity project with a distinct physical program, distinct milestones, and a distinct proof surface. The HQ paper already describes it as the company’s physical headquarters, infrastructure center, builder and operator formation site, production base, and demonstration home. That kind of work should not disappear into generic OPEX.
The core platform itself may also justify its own project bucket when the company wants readers to follow platform hardening, contracts, indexer work, SDK and docs work, trust surfaces, support surfaces, and other core-system expansion as a named buildout track rather than as undifferentiated engineering labor.
Major first-party apps should be split into their own project buckets once they are material enough to deserve their own progress record. Auction House, Lounge, Dapp Maker, and later first-party surfaces should not all be forced into one blurred “app development” line if the company wants backers and future partners to be able to follow how platform expansion is actually unfolding.
The same logic applies to event work. If Yokefellow uses raise proceeds for a meaningful public event, builder formation event, partner showcase, or other distinct milestone moment, that work should be shown through its own event bucket rather than buried inside broad operations. One project per project. One event bucket per event. That is the cleaner architecture.
12. Routing Rules
The raise should therefore follow a visible routing discipline. The sale bucket collects the raise under the live sale terms. From there, proceeds move into the approved destination buckets under a posted proceeds map. That map should identify which categories route into Reserve Fund, OPEX, CAPEX, HQ, platform, app, or event buckets and should make clear whether the routing is fixed, range-based, milestone-based, or governed for later allocation within named bounds.
The important thing is that a material use category should not require private interpretation to understand where the money went. If the company says the raise supports HQ, core platform work, and first-party app expansion, the public should be able to see those destinations as actual bucket paths rather than reading one paragraph and guessing how the company later interpreted it.
Not every spend has to flow directly out of the sale bucket. In fact, that would usually make the record worse. The sale bucket should show the raise. The destination buckets should show responsibility. Transfers between them should be part of the public record.
13. Public Record Standards for Each Bucket
Every destination bucket should answer four practical questions. What is this bucket for. What kind of spending or buildout belongs here. What kind of updates and proof should appear here later. And what does “done,” “advanced,” “still pending,” or “reconciled” mean in this context.
That means each bucket should carry a readable policy or governing explanation, stable reference docs where needed, regular updates while meaningful work is still happening, receipts where receipts help show follow-through, and proof that helps a reader understand what capital turned into in practice.
The record should not pretend that every outcome is instantly onchain or instantly self-proving. Some follow-through is operational, offchain, physical, or process-based. But that makes the record requirement more important, not less important. If part of the value of the raise is the company’s ability to build real infrastructure, physical space, content capability, or partner formation, then those things need readable proof surfaces instead of private explanation.
14. Updates, Docs, Receipts, and Proof
Yokefellow already has the cleanest public record categories for this work: updates, docs, receipts, and policy. The raise paper should use that same structure instead of inventing a weaker one.
Updates should show movement: what changed, what advanced, what was delayed, what milestone was reached, what routing decision was made, what has become live, or what remains blocked. Docs should hold stable reference material such as the raise paper, posted proceeds map, milestone plans, HQ program documents, or other durable explanations that people may need to read more than once. Receipts should show concrete follow-through where receipts actually help prove it. Policy should hold the governing rules of the raise, routing, reallocation limits, and reporting posture.
The distinction matters because many companies blur all of these together. Yokefellow should not. The whole point is to make the record more legible than ordinary startup bookkeeping theater.
15. What Transparency Should Actually Mean Here
A raise shown through Yokefellow should follow stricter transparency rules than a normal vague raise page. At minimum, the public should be able to see the sale structure, the destination-bucket structure, the progress of the raise, the intended use categories, the routing logic, the reporting cadence, and the later updates and receipts tied to actual use.
Just as importantly, the public should be able to tell what is still planned, what is funded but not yet executed, what is in progress, what is complete, and what changed from the original plan. “Transparency” should not mean only that an old page still exists somewhere. It should mean a reader can follow the actual shape of the raise and the actual shape of the spend without having to reconstruct it from scattered fragments.
16. Partial Fill, Overfill, Delay, and Reallocation Rules
A serious raise paper should also say what happens when reality does not follow the clean middle case. If the raise is only partially filled, the public should be able to see the priority order of proceeds routing and what categories get funded first, deferred, or scaled down. If the raise exceeds its base target, the public should be able to see what additional categories, acceleration paths, or reserve posture become eligible rather than discovering later that “extra funds” simply vanished into an unstructured company pool.
The same standard applies to delays and reallocation. If a destination bucket is not ready to spend yet, that status should be visible. If a project changes shape, a routing adjustment should be posted as an update under a rule the public can understand. Reallocation does not have to be impossible, but it should not be casual, invisible, or retroactively explained as if no change happened.
This is one of the most important improvements the paper can make. A raise becomes much easier to trust when readers know not only the base intended path, but also the posted rules for underfill, overfill, delay, and later adjustment.
17. Congress and the Governance Stages of the Raise
This paper should be read in two governance stages. Before Congress is constitutionally active, the raise can still be structured through buckets, internal approval, and public company discipline. After Congress becomes active, Congress should govern how the company’s yearly YES sale is publicly structured within the fixed YES emission schedule, which governed buckets are used to present that sale, what governed purposes those proceeds are directed toward, and how those proceeds are routed through governed use-of-proceeds buckets.
That does not mean Congress changes the protocol-level YES cap. It means Congress becomes the governing authority over the public sale structure and proceeds-routing architecture inside that fixed framework. The raise paper should say this clearly so readers understand both the current posture and the later constitutional posture without confusing them.
18. What Should Be Locked Before Launch
The exact live raise does not need to pretend every detail is final today, but the paper should be explicit about which fields still need to be locked before launch. Those include the exact sale size or round structure, the final sale bucket names, the final use-of-proceeds bucket names, the destination ranges or percentages, the reporting cadence, the priority rules for partial fill, the rules for overfill and reallocation, and the closeout or reconciliation posture for each material destination bucket.
Leaving those as governed fields does not weaken the paper. Hiding the fact that they still need to be finalized would weaken it. The structure should be stable now even where some live numbers, names, and timing details are still waiting to be fixed.
19. Why This Raise Structure Fits Yokefellow
This raise structure fits Yokefellow because buckets are already the public surfaces where funding, participation, rights, proof, and operator responsibility are supposed to become explicit. The system is built to keep support from scattering into disconnected tools and disconnected records. A raise should follow the same rule.
That means the raise itself becomes part of the product proof. It shows that Yokefellow can do more than describe a better participation system. It can use that system for one of the most important things a platform has to do: raise capital, route it visibly, and keep showing what happened afterward.
20. Closing Frame
Yokefellow should raise capital through the same kind of structure it is asking others to trust. The sale should be shown through a real sale bucket or sale-bucket family. The proceeds should be routed through organization buckets and project buckets that actually correspond to the work being funded. Reserve Fund, OPEX, and CAPEX should provide the company-level routing backbone. HQ, core-platform work, first-party app work, and major event work should become their own visible project or event buckets when material enough to deserve separate records.
The result is a stronger model than ordinary “use of funds” language. The fixed YES framework defines the outer limit. The sale structure defines what is being sold. The proceeds map defines where the money is supposed to go. The bucket record defines who carries what responsibility. The updates, docs, receipts, and proof define what happened afterward. That is the raise structure that actually fits Yokefellow.