# Cobuild Docs
> A new kind of organization is necessary for the intelligence age.
## The Cobuild Bill of Rights
A moral bill of rights for a world where thousands of communities can coordinate materially.
### I. The Right to Permissionless Opportunity
Anyone, anywhere can contribute, earn, and build without needing permission.
**Duty.** Design for open entry, legible contribution paths, and credible proof-of-work.
**Test.** Can a talented unknown from a low-income country realistically earn status + income without insider connections?
### II. The Right to Earn Ownership
Work should earn you a stake. Contributors deserve ownership in the networks they help build, not just payment, but voice.
**Duty.** Ensure that sustained contribution translates into governance weight and economic upside, not just one-off rewards.
**Test.** Can a builder who ships for two years credibly steer the direction of the network, or do early capital holders dominate forever?
### III. The Right to Verifiability
Important rules and outcomes must be checkable from public data.
**Duty.** Make allocation logic, treasury flows, and token mechanics inspectable and reproducible (or at minimum: auditable, with clear invariants).
**Test.** Can a third party reproduce "who got paid and why" without trusting Cobuild's servers?
### IV. The Right to Exit, Fork, and Rebuild
If governance, culture, or leadership fails, people can leave without begging and fork what they helped create.
**Duty.** Keep mechanisms for clean exit; avoid lock-in via proprietary data, closed IP, or opaque identity systems.
**Test.** Can a community credibly say: "If you disagree, fork us," and mean it?
### V. The Right to Voluntary Association
Your community should be chosen, not inherited. People deserve to opt into the cultures they belong to and opt out when they no longer fit.
**Duty.** Make communities discoverable, entry clear, and exit frictionless. No lock-in through guilt, sunk costs, or information asymmetry.
**Test.** Can someone who grew up in one community easily find and join another that better reflects their values?
### VI. The Right to Credible Commitments
Core invariants cannot be changed unilaterally, silently, or mid-game after people have committed time, work, and identity.
**Duty.** Define and lock core invariants at deploy time for fundraising and allocation. If upgrades exist, make them constrained, transparent, timelocked, and escapable. No admin keys that can seize funds, rewrite allocations, or drain treasuries.
**Test.** Can any key (team multisig, DAO, operators, UI) change issuance, cash-out, or treasury rules? If an upgrade happens, is there an enforced on-chain timelock long enough for users to exit or fork safely?
### VII. The Right to Distributed Power
No single constituency (founders, whales, operators, regulators, or mobs) should unilaterally steer outcomes.
**Duty.** Design for separation of powers across capital, operators, interfaces, and identity. Make chokepoints replaceable. Prefer mechanisms that aggregate many independent signals; discount correlated blocs (plutocracy and mobs) and make collusion expensive.
**Test.** If top holders collude, what can they force? If many accounts are really a few operators, do we count them as a bloc? If the default UI/RPC/indexer disappears or turns hostile, can users still fully participate? Is any single provider or jurisdiction a choke point?
### VIII. The Right to Informed Cultural Participation
Communities can build strong cultures, but members deserve clarity about what the culture asks of them and protection from manipulation disguised as belonging.
**Duty.** No dark patterns, no social blackmail, no engineered dependency loops. Coercion isn't only physical; it can be psychological, memetic, and economic.
**Test.** Can a newcomer easily understand what gets rewarded, what gets punished, and what's expected? Does the community rely on FOMO, shame spirals, or identity lock-in to retain members?
### IX. The Right to Trust-Minimized Coordination
No indispensable intermediaries for critical actions. Anyone can participate through alternative clients and compatible surfaces, without permission.
**Duty.** Data and state portability: export identity, contribution history, and account state. Open surface area: documented APIs, event streams, minimal proprietary dependencies.
**Test.** Can a third party build a client that fully participates without privileged keys? Can a member export their record and reuse it elsewhere? Does the trusted-dependency list shrink over time?
### X. The Right to Privacy and Pseudonymity
People can contribute, coordinate, and earn without being forced to reveal their identity, financial history, or social graph. Privacy is a civil liberty; pseudonymity is a safety tool.
**Duty.** Minimize data and disclose selectively. Support pseudonyms and privacy-preserving proofs, protect metadata, and avoid mandatory KYC. When accountability is required, use cryptographic receipts, slashing/staking, or opt-in disclosure.
**Test.** Can someone with safety or employment risk participate under a stable pseudonym? Can they prove eligibility (human/unique/member/contributor) without revealing who they are? Do the default UI, APIs, or analytics minimize metadata that could reconstruct identities and social graphs over time?
### XI. The Right to Due Process and Equal Protection
No one should lose access, reputation, funds, or standing through arbitrary or opaque decisions. Rules must apply consistently, with notice, evidence, and a path to appeal.
**Duty.** Define actions and penalties up front; publish the rule, evidence, decision-maker, and timeline; provide a non-single-gatekeeper appeal path; prefer reversible penalties.
**Test.** If an account is slashed, excluded, defunded, or labeled harmful: can they see the exact rule, the evidence, who decided, and how to appeal - without relying on private backchannels or personal relationships?
### XII. The Right to Subsidiarity and Local Autonomy
Decisions should be made at the smallest scope that can competently make them. Global rails should not become the arena for every cultural or political dispute.
**Duty.** Prefer local governance: community budgets, constitutions, and opt-in federations. Keep global decisions minimal. Make splitting and rejoining easy with forkable communities, portable identity/rep, and compatibility standards.
**Test.** When a controversy happens, can it be resolved by the affected community without dragging the entire network into a winner-take-all vote? Can two incompatible communities coexist on the same rails without one capturing the other?
### XIII. The Right to Self-Custody and Secure Property
People must be able to hold and move what they earn (funds, credentials, reputation) without relying on a custodian or a privileged administrator. A right you can't exercise under failure conditions isn't a right.
**Duty.** Default to self-custody and permissionless withdrawal via open standards and non-custodial accounts. Support safe key recovery (social recovery, multisig, delegated recovery) without mandatory KYC. Minimize catastrophic loss with clear trust boundaries and bounded upgrades.
**Test.** If Cobuild's main UI disappears, a team goes rogue, or a hosting provider deplatforms a service: can I still access my assets and records and exit safely? Can I rotate keys and recover without begging a centralized operator?
### XIV. Substrate, Not Sovereign
This network is a coordination substrate, not a moral authority. It should help communities build, not become the thing that tells everyone what to be.
**Duty.** Resist the pull toward platform-as-arbiter. Let communities define their own values; the rails enable coordination, not conformity. The protocol stays neutral; moderation and curation happen at the edges (clients, community spaces), with a plurality of interfaces.
**Test.** When a values conflict arises, does the network try to settle it, or does it provide tools for communities to go their separate ways?
### XV. Human Dignity and Non-Coercion
Subcultures get sovereignty, but not a license for coercion, dehumanization, or violence.
**Duty.** Cobuild is for building; not for harming. This can show up as ecosystem norms, interface policy, and community-level constitutions.
**Test.** If a group uses Cobuild rails to coordinate targeted harm, can the broader ecosystem respond without turning the whole system into arbitrary censorship?
### XVI. Net-Positive to Humanity
A network that only benefits its members has failed. The best subcultures create value that spills over: open culture, shared knowledge, public goods.
**Duty.** Design for positive externalities. Reward contributions that benefit people beyond the network, not just those who hold the token.
**Test.** If someone who never bought the token asked what this network gave to the world, would there be a good answer?
## Getting Started
## Why Cobuild \[A brief preamble on why we built Cobuild]
### The Firm
Companies were built for the 20th century, when the cost of coordinating individuals through markets was high.
Every project meant finding counterparties, discovering prices, and negotiating contracts.
The company was the workaround.
Instead of haggling over every task in the open market, people signed long-term employment contracts, got a manager, and were told what to do.
Inside the firm, the "price mechanism" was largely superseded by hierarchy: if a worker moved from project A to project B, it wasn't because the wage for B ticked up, it was because their boss said so.
[Coase's insight](https://onlinelibrary.wiley.com/doi/10.1111/j.1468-0335.1937.tb00002.x) was simple: **firms exist to save on transaction costs.**
As long as it's cheaper to organize work inside a company than through the market, firms grow; once internal bureaucracy becomes as costly as external contracting, they stop.
That incentive shaped the corporate structures we inherited.
### The Internet
For most of the 20th century, your labor market was your city.
You hired from the people who lived nearby, or you moved if you wanted a different job.
Coordination was local by necessity.
Then the internet arrived and shattered that constraint.
You could email, chat, and ship files across the world in seconds.
But inside most companies, very little changed: people still commuted to the same buildings, sat in the same meetings, and reported to the same managers.
The network was treated as a communication tool, not a new substrate for how work itself might be organized.
More importantly, the internet rewired how we find one another.
It made it normal to have a closest collaborator you've never met in person, a group chat that matters more than your office, a feed full of people who share your exact obsessions.
It turned the world into a search engine for affinity: you can find a thousand people who care about the same thing you do, anywhere on the planet.
But these networks of affinity are still weightless.
Compared to corporations, they are hamstrung.
We can trade ideas and motivation, but not hold assets, contracts, or shared upside.
Our real communities live online, but our money and authority live inside legacy firms and legal paperwork.
We can gather online as global tribes, but lack the technology to reach our full potential in the real world.
Spiritual networks trapped by old world coordination.
### Ethereum
On the web, data could be copied freely, but **ownership and incentives** lived in legacy systems built for simple agreements.
If you wanted rules ("if X happens, pay Y"), you needed lawyers, contracts, and courts.
Most agreements assumed a small, fixed set of parties: a customer and a company, a worker and a firm, anchored in the legacy legal and banking system.
Many-to-many agreements across borders meant stitching together a patchwork of accounts, entities, and contracts, and in practice almost never happened.
Those rules were written for a handful of counterparties at a time, not for networks of millions.
In 2009, Bitcoin introduced a different primitive: a shared ledger that anyone could verify, but no single actor controlled.
For the first time, you could have *native* digital assets.
Scarce, transferable units of value, without a central issuer.
Ethereum generalized that idea.
Instead of just tracking balances, you can put **code** on the ledger: smart contracts that hold assets and execute rules automatically.
"If a vote passes, release the budget"; "If these conditions are met, mint new shares."
No middle managers, no opaque legal plumbing, just shared logic everyone can inspect and no one can unilaterally override.
Blockchains turned the internet from a network where we could only *read and write information* into a network where we can also *own things together and coordinate how they move*.
A new substrate for building organizations that are natively global, programmable, and owned by the people who contribute to them.
### Abundant Intelligence
Even with the internet and blockchains, coordination still hit a hard bottleneck: **human judgment**.
Connecting the right people, evaluating work, and deciding where money should go all required scarce attention from managers, reviewers, and committees.
If you wanted high-signal allocation, you had to spend a lot of time reading, interviewing, and debating.
Most of the world's capital and opportunity was steered by a specialized few.
For the first time in history, *intelligence itself* is becoming a commodity.
That means the cognitive labor of coordination can be automated:
* Matching contributors to the right projects across the whole internet
* Scoring proposals against a community's values and past outcomes
* Auditing reputation and proof of work effortlessly
* Simulating different funding rules before putting money at stake
What used to require a foundation, an investment committee, or a full-time ops team can now be done by a few people with cheap, abundant intelligence.
Combine this with programmable money and shared incentives and you get something new: **organizations that can fundraise, align, and allocate at global scale without growing a giant management bureaucracy.**
The constraint is no longer "how many smart people can we put in one building?" but "what values beyond profit do we want to optimize for?"
### Meaning in the 21st Century
Industrial society asked people to find meaning outside their work through church, family, hobbies, while their days were spent in what Alan Watts called the commute-necktie-strangle scene, doing tasks disconnected from food, shelter, beauty, or community.
The Industrial revolution gave us material abundance, but it turned most people's working hours into lifeless routines that neither express their full gifts nor root them in the world.
People still want to give their best effort to something that matters and be known for more than their résumé or shopping cart.
Our incentive systems don't know how to offer that for most of us.
The question for the 21st century is whether we can build forms of coordination where earning a living and living your values stop being two separate tracks of life.
The next generation of great organizations won't look like companies selling products; they will look like communities co-creating culture.
Cobuild exists to give these communities the economic rails they need to sustain themselves.
### Our Opportunity
There's one economically dominant, albeit meaningless, global belief system today: consumerism.
Nothing else really has the legs.
Our idea is simple: build the economic engine for the next million belief systems.
Turn today's online networks of believers into organizations owned by their contributors, with real capacity for collective action in the world.
Put another way: **a coordination engine to build meaningful meritocracies at scale.**
A new type of organization is necessary for the intelligence age.
One that operates without borders, traditional hierarchies, and is uniquely internet native, onchain, and AI coordinated.
Cobuild is our attempt to build the coordination layer for these organizations.
Communities define their values: what they care about and what "good work" looks like.
Cobuild turns values into transparent rules, matching the right people and projects, and moving capital intelligently.
Resource allocation shifts from committee decisions to the real‑time expression of millions of people's values and intentions, encoded in logic that is shared, inspectable, and forkable.
If we succeed, more and more people will be able to earn and own by contributing to the cultures they actually believe in.
They'll do it using upgraded primitives that once only served corporations, but now empower million-person networks with meaningful goals beyond profit.
## Our Mission \[What we're building toward]
**Our mission is to increase community-driven impact in the world.**
Today's institutions weren't designed for the intelligence age.
The firm was a workaround for expensive coordination, where hierarchy replaced markets because finding and trusting strangers was slow and costly.
That constraint is gone.
The internet gave us global affinity.
Blockchains gave us shared ownership.
AI gave us abundant judgment.
We now have everything we need to replace the firm with the network.
### Our beliefs
**Networks, not firms.**
The best work happens in communities of shared belief, not corporate org charts.
We build infrastructure for networks to hold assets, make decisions, and reward contributors.
**Meaning, not just profit.**
People want to give their full effort to something that matters.
The next great organizations won't sell products; they'll co-create culture.
We give these communities economic rails.
**Bottom-up allocation.**
Markets work because they aggregate millions of small judgments into accurate prices.
Grants fail because committees can't scale.
We build market-like primitives that route capital to where organic attention and value already flow.
**Permissionless by default.**
Anyone can contribute. Anyone can earn. Anyone can build.
No gatekeepers deciding who gets to participate in the upside.
**Transparent rules, not opaque bureaucracy.**
Smart contracts let us encode allocation logic that everyone can inspect and no one can unilaterally override.
**Owned by builders, not just funders.**
We believe the best global movements will be owned by their builders as much as they're owned by the people contributing capital.
You should be able to earn a vote for your efforts and steer the energy of the movement you're contributing to.
### The bet
If we can allocate capital as accurately as markets do, but for work that doesn't have a price tag, fundraising becomes easy and millions of people can earn a living advancing missions they actually believe in.
We're building the coordination engine that enables this future.
## Cobuild with us \[Our vision for the future]
Our vision is a world where millions of people earn a living advancing missions they care about.
Our hope is that we can **rewrite civilization’s reward function away from maximizing profit and more explicitly toward human values.**
* Subcultures → sovereign, economically real networks
* Jobs → missions inside cultures you care about
* Firms → networks owned by participants
* Incentives → aligned with values, not just profit
* Cobuild → the coordination engine making this all actually work
The old world is stuck in a coordination trap; the new one is begging to be born.
We now have the tools to replace the Firm with the Network, the Job with the Mission, and the Manager with Crowd Intelligence.
Cobuild is for people who want to step out of the race to the bottom and build the next generation of organizations that maximize our shared humanity and values.
## $COBUILD \[Our network's token]
import { CobuildNetworkDiagram } from "../../components/CobuildNetworkDiagram";
$COBUILD is the token backing the Cobuild network. We plan to launch it soon.
Cobuild is a launchpad for the next generation of organizations, with $COBUILD at the center of the economy.
* Networks launched on Cobuild use $COBUILD as their base trading pair
* A percentage of newly minted tokens seed LP positions, adding first-party liquidity. Trading fees from this liquidity route to the Cobuild revnet.
* [Social-swaps](/allocation/reaction-markets) that buy tokens in-feed on Farcaster and Twitter pay a small fee to buy $COBUILD for the user.
* Any [TCR-based](/allocation/flows) governance use $COBUILD or tokens denominated in it
### Stack
Cobuild tokens are built on top of [Revnets](https://revnet.app/) - autonomous revenue networks that tokenize payments with locked issuance and cash-out terms across stages.
Revnets are built on [Juicebox](https://juicebox.money/), the programmable treasury protocol behind [ConstitutionDAO](https://en.wikipedia.org/wiki/ConstitutionDAO) - the historic crowdfund that raised $47M in under a week to bid on a copy of the U.S. Constitution.
This stack gives Cobuild tokens battle-tested, audited smart contracts that have processed hundreds of millions in onchain payments.
Learn more about our unique [token structure](/fundraising/staged-issuance).
## Getting Started
Ready to build with Cobuild? Here's how to get started.
### Join the Community
The best way to get started is to join our community channels:
* [Discord](https://discord.com/invite/PwWFgTck7f) — Chat with other builders
* [Farcaster](https://farcaster.xyz/cobuild) — Follow updates and discussions
* [X/Twitter](https://x.com/justcobuild) — Stay in the loop
### Explore the Docs
1. **[Why Cobuild](/introduction)** — Understand the problem we're solving
2. **[Our Mission](/our-mission)** — Learn what drives us
3. **[Capital Allocation](/allocation/our-perspective)** — See how we think about directing resources
4. **[Cobuild Tokens](/fundraising/why-crypto)** — Understand our token economics
### Start Contributing
Cobuild is built in the open. Check out our [GitHub](https://github.com/cobuildwithus) to see what we're working on and find ways to contribute.
## What is Cobuild
import { CobuildMechanismDemo } from "../../components/cobuild-mechanism-demo";
> **Cobuild** /ˈkōˌbild/ *proper noun* — A coordination engine to build meaningful meritocracies at scale.
Cobuild provides the economic rails for communities to fundraise, align members, and allocate capital transparently
to thousands of contributors all over the world.
> *cobuild* /ˈkōˌbild/ *noun* — A mission-aligned community owned by its contributors with capacity for large-scale collective action in the world.
### How a cobuild works
A token is launched with fair issuance and a shared treasury.
When tokens are minted, a percentage automatically goes to contributors. [AI](/allocation/rounds#how-it-works) and [in-feed](/allocation/reaction-markets) quadratic funding identify who's growing the network and split the rewards accordingly.
#### Fundraising
A community launches a token backed by a shared treasury with no governance except for four simple rules.
1. **Pay in (issuance)** — Anyone can pay the network in an accepted base asset. The contract mints tokens at the current issuance price; an optional split routes a fixed percent of new tokens to preset recipients. Funds remain in the treasury.
2. **Cash out (redemption)** — A holder burns tokens to reclaim treasury funds. A stage-defined cash-out tax keeps part of the redeemable value in the treasury, raising the future floor for remaining holders.
3. **Borrow (loans)** — Instead of cashing out, a holder can borrow from the treasury against their tokens. The borrowable amount is capped by that collateral's cash-out value.
4. **Split (builder funding)** — A share of all newly minted tokens is routed to builders growing the network.
When someone buys a product, tips a creator, or routes revenue through the network, the treasury grows and the floor rises for every holder. When you mint new tokens, you can decide what initiatives to fund with your builder share.
#### Allocating Capital
Builders are paid to grow the network with a share of newly minted tokens.
We use a combination of LLM-driven pairwise duels and quadratically weighted social signals to allocate capital.
When you like or comment on a builder's update, you're micro-purchasing tokens that go directly to them.
These engagement signals are quadratically weighted so many small endorsements beat a few large ones.
* Anyone can propose ideas for how to spend tokens
* Anyone can get paid to help realize the mission
* The best contributions are paid fairly and openly
Money in, money out, all visible onchain. Revenue grows the floor, engagement routes capital to builders, builders ship more, the network earns more. A flywheel that lets anyone fund or earn a living advancing missions they believe in.
## Just Cobuild, Co. Privacy Policy
**Effective Date:** December 6, 2025\
**Snapshot:** "Privacy-first approach for non-custodial streaming funding."\
**Commit Hash:** c7f998867b8ca5952fdaf776f4966af4f811dbff
This Privacy Policy (the "Policy") explains how Just Cobuild, Co., a Delaware C-Corporation ("Cobuild", the "Company", "we", "us", or "our") collects, uses, and shares data in connection with the cobuild platform, including the Interface, smart contracts, and related services (collectively, the "Services"). Your use of the Services is subject to this Policy as well as our [Terms of Service](/legal/terms).
##### High-Level Summary
* Cobuild is a US-based company operating cobuild, a non-custodial platform for continuous funding via streaming smart contracts. We comply with applicable US laws, GDPR, and CCPA.
* The Flow protocol is permissionless and not governed by Cobuild.
* We do not collect or store personal data such as first name, last name, street address, date of birth, email address, or IP address in connection with your use of the Services, unless voluntarily provided.
* We collect limited non-identifiable data, such as public on-chain data (e.g., wallet addresses), and minimal off-chain data (e.g., device type, browser version) for analytics, security, and improvements—not to track individuals.
* If you opt-in for emails (e.g., newsletters or updates), we store your email to send them; you can unsubscribe anytime. We do not link emails to wallet addresses or other data.
* We explore privacy enhancements like opt-out prompts and privacy-focused tools.
* Users can employ client-side privacy methods (e.g., VPNs, new wallets).
* Material changes to this Policy will be posted here with advance notice.
##### Data We Collect
Privacy is fundamental to our mission. We value transparency and collect only what's necessary. We do not require user accounts and avoid storing personal data. As noted in our Terms (Section 9), we currently do not use tracking cookies or similar technologies (if that changes, we'll update this Policy beforehand). **We honor "Do Not Track" (DNT) signals from browsers where feasible.** When you interact with the Services, we collect:
* **Publicly-available blockchain data.** When you connect your non-custodial wallet, we collect your public wallet address and on-chain activity (e.g., transactions, Farcaster activity) to enable features like streaming, voting, and compliance screening (e.g., for sanctions via OFAC checks). We may use third-party analytics providers. Wallet addresses are public and not personally identifying alone.
* **Information from localStorage and other tracking technologies.** We and our providers may collect data from localStorage, cookies (if implemented), or similar to personalize the Services (e.g., remembering imported tokens or preferences). This includes browser type, device language, operating system, and aggregated usage patterns. We analyze these collectively to improve UX.
* **Information from other sources.** We may receive wallet or transaction data from service providers for legal compliance (e.g., preventing illicit activity) or during grant-round escrow (limited custody exception per Terms Section 4.2).
* **Survey or usability information.** If you join a survey or study, we record provided biographical info (e.g., name, email, job title), responses, and interactions.
* **Correspondence.** We receive info you provide via email (e.g., [legal@justco.build](mailto\:legal@justco.build)), support channels, social media (e.g., X/Twitter), or surveys.
* **Biographical information.** For job applications, we collect details like name, email, resume, and work status.
* **Minimal telemetry.** As per our Terms, we collect anonymized data on Service usage for analytics and improvements, based on legitimate interests.
* **Third-party integrations.** The Services integrate with third parties (e.g., Juicebox, Farcaster, wallet providers). We do not control their data practices; review their privacy policies.
##### How We Use Your Data
We use data solely for:
* Providing and improving the Services (e.g., funding streams, interface personalization).
* Analytics and security (e.g., detecting exploits, aggregated insights for product vision).
* Legal compliance (e.g., sanctions screening, tax reporting if required).
* Communicating with you (e.g., support responses, opt-in emails).
* Marketing (only with consent; e.g., newsletters).
* Processing job applications or surveys.
Processing is based on: your consent (e.g., emails), contract performance (e.g., Service access), legitimate interests (e.g., security, improvements), or legal obligations.
##### Sharing Your Data
We do not sell data **or share it for cross-context behavioral advertising**. Sharing is limited to:
* **Service providers and affiliates:** Third parties (e.g., analytics tools, hosting) bound by confidentiality and data protection agreements.
* **Legal requirements:** To comply with laws, subpoenas, or authorities (e.g., OFAC).
* **Business transfers:** In mergers, acquisitions, or asset sales.
* **With your consent:** E.g., sharing on-chain data with indexers.
For GDPR: Processors are vetted; international transfers (e.g., to US) use standard contractual clauses or adequacy decisions.
##### Data Security
We use industry-standard measures like encryption, access controls, and secure protocols. Report vulnerabilities to [security@justco.build](mailto\:security@justco.build) (per Terms Section 10; discretionary rewards for good-faith disclosures). We are not liable for blockchain risks or third-party breaches (e.g., wallet providers like Juicebox, Farcaster). **We cannot guarantee absolute security due to inherent internet and blockchain risks.**
##### Your Choices and Rights
* **Opt-outs:** Unsubscribe from emails anytime; manage localStorage/cookies via browser settings.
* **Access and control:** Request access, correction, deletion, or portability of your data.
* **GDPR rights (if applicable):** Object to processing, withdraw consent, restrict use; lodge complaints with supervisory authorities. **We aim to respond within one month, extendable to two if complex.**
* **CCPA rights (California residents):** Know collected data, delete it, opt-out of sales (we don't sell). Non-discrimination for exercising rights. Submit requests via [legal@justco.build](mailto\:legal@justco.build); we'll verify and respond within 45 days.
* We do not use data for automated decision-making with legal effects. **Note: On-chain data (e.g., transactions) is public and immutable; we cannot edit or delete it.**
##### Data Retention
We retain data only as needed: e.g., technical logs for 6-12 months, correspondence until resolved, on-chain data as public. Deletion upon request or when no longer necessary, subject to legal holds.
##### International Data Transfers
Data may be processed in the US or other countries. We ensure safeguards like GDPR-compliant clauses for transfers outside EEA/Switzerland.
##### Children's Privacy
Services are for users 18+ (per Terms Section 2.1); we do not knowingly collect data from children under 13 **(or higher where required by law, e.g., 16 under GDPR)**.
##### Changes to This Policy
We may update this Policy; changes posted on cobuild with 30-day notice for material updates (per Terms Section 16). Continued use constitutes acceptance.
##### Contact Us
For questions or rights exercises: [legal@justco.build](mailto\:legal@justco.build) or Just Cobuild, Co., 131 Continental Dr Suite 305, Newark DE 19713 USA.
This Policy aligns with our Terms; in conflicts, Terms prevail.
## Just Cobuild, Co. Terms of Service
**Effective Date:** December 6, 2025\
**Snapshot:** “Non‑custodial coordination tools for community‑owned networks, including streaming grants, tokenized revenue networks, and AI‑assisted capital allocation.”\
**Commit Hash:** REPLACE\_WITH\_REPO\_COMMIT
> **Non‑binding summary for humans (not a contract).**\
> Cobuild gives you non‑custodial tools to interact with onchain smart contracts for things like streaming grants, Cobuild tokens, revenue networks, loans, Reaction Markets, and AI‑assisted allocation. You keep control of your wallet; we never take custody of your assets. Using these systems is risky: smart contracts can fail, AI can be wrong, tokens can go to zero, “floors” can disappear, loans can wipe your collateral, and social‑driven systems can be gamed. We are not your broker, bank, investment adviser, or fiduciary. Nothing here is investment, legal, or tax advice. Our liability is sharply limited and most disputes must go to individual arbitration with a class‑action waiver (with a 30‑day opt‑out).
***
### 1. Introduction & Acceptance
#### 1.1 Contracting entity
These Terms of Service (the **“Terms”** or this **“Agreement”**) govern your access to and use of products and services provided by **Just Cobuild, Co.**, a Delaware C‑Corporation (**“Cobuild,” “we,” “us,” or “our”**), including:
* Websites at `co.build`, `justco.build`, and their subdomains (the **“Sites”**);
* The Cobuild web app, dashboards, and other front‑end interfaces (each, an **“Interface”**);
* Any associated software, APIs, SDKs, developer tooling, integrations, documentation, and related services\
(together with the Interfaces, the **“Services”**).
#### 1.2 Acceptance
By accessing or using any Services in any way (including visiting a Site, connecting a wallet, or submitting a transaction), you:
* Acknowledge that you have read and understand these Terms; and
* Agree to be legally bound by them in full.
If you are using the Services on behalf of an entity, you represent and warrant that you have authority to bind that entity, and **“you”** includes both you and that entity.
If you do not agree to these Terms, **do not access or use the Services.**
#### 1.3 Arbitration & class‑action waiver (important)
Except for the limited circumstances described in Section 17.6, **Disputes** (as defined below) between you and Cobuild must be resolved by binding **individual** arbitration, not in court, and **not in a class or representative action**. You may opt out of arbitration within 30 days of first accepting these Terms (Section 17.5).
#### 1.4 Changes to these Terms
We may modify these Terms from time to time. For material changes we will:
* Update the “Effective Date” and/or “Commit Hash” above; and
* Provide notice through the Services (for example, banner, modal, or email if you’ve provided one) where required by law.
Unless a later effective date is stated, modifications take effect when posted. If you continue using the Services after changes take effect, you are deemed to accept the updated Terms. If you do not agree, you must stop using the Services.
#### 1.5 Contact
* Legal & general: **[legal@justco.build](mailto\:legal@justco.build)**
* Security & vulnerabilities: **[security@justco.build](mailto\:security@justco.build)**
Mailing address:\
Just Cobuild, Co.\
131 Continental Dr, Suite 305\
Newark, DE 19713, USA
Service of process (registered agent):\
Northwest Registered Agent LLC\
8 The Green, Suite B\
Dover, DE 19901, USA
***
### 2. Eligibility & Use Restrictions
#### 2.1 Age and capacity
You may use the Services only if:
* You are at least **18 years old** (or the age of majority in your jurisdiction, if higher); and
* You have the legal capacity to enter into a binding contract with Cobuild.
#### 2.2 Sanctions & restricted persons
By using the Services, you represent and warrant that you:
* Are **not** on any sanctions or restricted‑party list (including those maintained by OFAC, the U.S. Department of State, the EU, the U.K., or the UN); and
* Are **not located in, ordinarily resident in, or organized under the laws of** any jurisdiction subject to comprehensive sanctions or where your use of the Services would be illegal.
We may block, restrict, or terminate access where we reasonably believe you are a sanctions‑restricted person or using the Services on their behalf.
#### 2.3 Export controls
You agree to comply with all applicable export‑control and re‑export laws and regulations. You may not use, export, or re‑export the Services in violation of U.S. or other applicable export laws.
#### 2.4 Responsibility for compliance
You are solely responsible for understanding and complying with all laws and regulations that apply to you in connection with your use of the Services, including (without limitation) those relating to:
* Anti‑money‑laundering and counter‑terrorist‑financing;
* Sanctions;
* Securities, commodities, and derivatives;
* Consumer protection and unfair‑competition laws;
* Tax; and
* Data protection, privacy, and automated decision‑making (for example, GDPR and the EU AI Act).
***
### 3. Key Defined Terms
For purposes of these Terms:
* **Baseline Pool** – The portion of a Flow’s budget that is distributed evenly (or under simple rules) across approved Builders.
* **Bonus Pool** – The portion of a Flow’s budget that is allocated in a performance‑weighted way based on signals such as Reaction Markets, votes, or other metrics.
* **Builder** – An individual or entity that applies to receive funding or other support through Cobuild‑related programs (for example, Flows or Rounds) and meets posted eligibility criteria.
* **Cobuild Token** – A Token configured using Cobuild’s parameters (for example, staged issuance, splits, cash‑out floors, revenue routing, and loan features) and typically implemented on third‑party protocols such as revnets and Juicebox. A Cobuild Token’s behaviour is determined by its Smart Contracts, **not** by Cobuild as issuer or guarantor.
* **Revenue Network / Revnet** – Smart Contracts that route incoming payments into a shared onchain treasury and mint or redeem Tokens under predefined rules (for example, staged issuance, floors, and cash‑out taxes). In Cobuild's current implementation, Revnets are built on top of the open‑source **Juicebox protocol**, whose core contracts are deployed and governed by **Juicebox DAO** and independent maintainers, not by Cobuild. Revenue Networks may be deployed, governed, or upgraded by third parties and are not controlled by Cobuild.
* **Floor / Cash‑Out Floor** – The onchain redemption value per Token implied by the relevant Smart Contracts and treasury at a given time, **subject to** the contract terms, fees, available liquidity, and protocol risk. It is an internal mechanism of the Smart Contracts and **not** a guaranteed minimum market price or redemption right against Cobuild.
* **Ceiling / Issuance Price** – The price and schedule according to which new Tokens may be minted from a Smart Contract in a given stage. The ceiling is set by code and may differ substantially from secondary‑market prices.
* **Loan** – An onchain borrowing mechanism where a user locks or burns Tokens as collateral in exchange for a disbursement from a treasury, subject to fees, over‑collateralization, and a maximum duration. Loans are executed and enforced by Smart Contracts and **not** by Cobuild as lender, unless explicitly stated in a separate written agreement.
* **Reaction Market** – A system where social‑media actions (for example, likes, comments, reposts, follows) are treated as micro‑purchases that automatically allocate a User’s configured budget to builders or tokens.
* **Reaction Market Budget** – The amount of funds a User designates for automatic micro‑purchases in a Reaction Market, including per‑reaction amounts and caps.
* **AI Allocation Systems** – Automated systems, including large language models and other algorithms, used to filter, rank, or score proposals, builders, or content for purposes of allocating capital in Flows, Rounds, Reaction Markets, and similar programs.
* **Flow / Flows** – Cobuild’s “always‑on” streaming‑grants architecture: onchain Smart Contracts and curated registries for recurring stipends, typically combining a Baseline Pool and a performance‑weighted Bonus Pool.
* **Rounds** – Time‑bounded grant or bounty competitions that allocate a fixed budget according to market‑like and/or AI‑assisted signals.
* **Flow TCR / TCR** – Token‑curated registries used to manage lists of eligible builders or recipients. Inclusion or removal is decided according to onchain rules.
* **Stream** – The onchain mechanism by which funds accrue over time to approved recipients and may be claimed by calling the relevant Smart Contract.
* **Smart Contract(s)** – Autonomous programs deployed on public blockchains (for example, revnet contracts, Flows contracts, Juicebox treasuries) that control how funds move. Smart Contracts are separate from the Services and may be deployed, upgraded, or governed by third parties.
* **Interface** – Any Cobuild‑controlled website, application, or tool that lets users compose and submit transactions to Smart Contracts while retaining control of their private keys.
* **Grant‑Round Escrow** – Limited, program‑specific arrangements where Cobuild or an affiliate temporarily holds funds (for example, fiat or stablecoins) for a defined period (such as a grant round) pending KYC/AML checks, payment routing, or programmatic disbursement.
* **Tokens** – Digital assets (for example, ERC‑20s) minted or managed by Smart Contracts accessed through the Services. Unless clearly stated otherwise, Tokens are created and governed by those contracts and **not** issued or redeemed by Cobuild.
* **Sponsor** – Any User that contributes funds, commits a budget, or otherwise supports a Flow, Round, or similar program.
Capitalized terms not defined above have the meanings given elsewhere in these Terms.
***
### 4. Description of Services & Non‑Custodial Nature
#### 4.1 Non‑custodial Interfaces
Cobuild provides **non‑custodial** Interfaces that allow you to:
* Connect an EVM‑compatible wallet;
* Read data from public blockchains and other sources; and
* Construct and broadcast transactions to Smart Contracts.
Cobuild does **not**:
* Take custody, possession, or control of your digital assets at any time;
* Hold, recover, or reset your private keys, seed phrase, or wallet passwords; or
* Reverse, cancel, or modify blockchain transactions once they have been submitted.
Your relationship with your wallet provider (for example, MetaMask, Rabby, embedded wallets) is governed by that provider’s own terms and policies.
#### 4.2 Smart‑contract persistence and decentralization
Many Smart Contracts accessible through the Services:
* Are deployed to public blockchains (for example, Ethereum, L2s, and other EVM networks);
* Are **not** controlled by Cobuild once deployed; and
* May be used directly (without the Services) by anyone capable of interacting with those blockchains.
Where Cobuild or its contributors deploy or help deploy Smart Contracts, those contracts typically remain onchain even if Cobuild ceases to operate.
#### 4.3 Open‑source and third‑party code
Smart Contracts and some front‑end components may be open‑source or source‑available under their own licenses (for example, MIT, GPL, or similar). Your rights and obligations with respect to that code are determined by the applicable license, which may grant you broader rights than this Agreement.
The Services may also integrate or rely on third‑party software, infrastructure, and APIs (for example, RPC providers, indexers, analytics, Farcaster or X/Twitter APIs). These third‑party services are **not** controlled by Cobuild and are subject to their own terms and policies.
#### 4.4 Limited custody exceptions (grant‑round escrow, etc.)
Cobuild intends the Services to be non‑custodial. However, limited, clearly disclosed exceptions may apply, such as:
* **Grant‑Round Escrow or fiat rails** where Cobuild or an affiliate holds funds temporarily to:
* Conduct KYC/AML/sanctions checks;
* Aggregate or route contributions; or
* Facilitate off‑chain payouts or other operational steps.
Where such custody is used, it will be disclosed in the relevant UI or documentation, together with any additional eligibility, risk, or compliance terms.
#### 4.5 Upgrades, forks & contract addresses
Protocols and Smart Contracts accessible through the Services may be upgraded, replaced, forked, or deprecated by their respective communities or deployers. Contract addresses may change.
You are solely responsible for:
* Verifying that you are interacting with the intended Smart Contracts; and
* Understanding the impact of any upgrade, migration, or fork before transacting.
Cobuild is not responsible for losses arising from your interaction with incorrect, malicious, or deprecated contracts (including phishing addresses and spoofed interfaces).
#### 4.6 Third‑party protocols and integrations
The Services may integrate or interact with:
* Smart contracts operated by third parties (for example, Juicebox, revnets, DeFi protocols, bridges);
* Wallets, RPC providers, indexers, analytics tools, social platforms, and data services; and
* Infrastructure providers such as cloud providers and analytics vendors.
Third‑party services are **not** operated by Cobuild. Your use of them is governed by their own terms and policies. Cobuild disclaims all responsibility for:
* Third‑party outages, bugs, exploits, or security incidents;
* Changes in third‑party APIs or pricing; and
* Losses arising from your interactions with third‑party services or protocols.
The Services surface and interact with third‑party treasury and issuance protocols, including the **Juicebox protocol**. Juicebox's core smart contracts are deployed and governed by **Juicebox DAO** and its community. Cobuild does not operate the Juicebox protocol or Juicebox DAO, does not control upgrades to their contracts, and is not responsible for their acts or omissions. When you interact with Revnets or treasuries built on Juicebox, you are interacting directly with those third‑party protocols, not with Cobuild.
#### 4.7 Cobuild Tokens & Revenue Networks
Through the Interfaces you may interact with Cobuild Tokens and Revenue Networks (for example, revnet or Juicebox‑based treasuries). These Smart Contracts may implement features such as:
* Staged issuance and time‑varying mint prices (ceilings);
* Onchain redemption or “cash‑out” mechanics referencing a contract treasury (floors);
* Token splits and auto‑issuance to specified recipients; and
* Loan functionality that allows Users to borrow against collateralized Tokens.
These mechanics are implemented solely in the relevant Smart Contracts. Cobuild does **not**:
* Custody or guarantee any treasury assets;
* Guarantee that any redemption, “floor,” or loan functionality will be available at any particular time or price; or
* Guarantee that Smart Contracts will behave as expected or be free from bugs, exploits, or governance changes.
Even where Tokens are branded with Cobuild‑related names, they are minted, priced, and redeemed (if at all) solely by Smart Contracts. Cobuild is **not your counterparty** to any Token mint, purchase, redemption, or loan transaction unless explicitly stated in a separate written agreement.
#### 4.8 Social and third‑party integrations (Reaction Markets)
Some Services connect to third‑party platforms (for example, Farcaster or X/Twitter) to read or act on your posts, likes, comments, or follows in connection with Rounds or Reaction Markets. If you enable such integrations:
* You authorize Cobuild to read certain content and metadata from your connected accounts; and
* You authorize Cobuild to initiate onchain transactions from your configured Reaction Market Budgets in response to your social actions, subject to the limits you set in the Interface.
You are responsible for:
* Configuring and monitoring your budgets and caps; and
* Understanding that ordinary social actions (for example, “like,” “repost”) may result in **real onchain spending** from your budgets.
Cobuild is not responsible for losses arising from misconfigured budgets, compromised social accounts, or third‑party platform changes.
Your use of third‑party platforms is governed by their own terms. Cobuild is not liable for their acts or omissions.
***
### 5. Funding, Streaming & Token Mechanics
#### 5.1 Streaming grants (Flows & Streams)
Where the Services support streaming grants or Flows:
* Funds accrue over time as defined in the relevant Smart Contracts; and
* Recipients may claim accrued amounts at any time by calling those contracts with a compatible wallet.
Eligibility criteria, stream parameters, and program logic are defined in Smart Contracts and/or program documentation and may change via protocol or community governance outside Cobuild’s direct control.
#### 5.2 Token issuance and sales
Tokens referenced in the Interfaces are generally:
* Minted and governed by independent Smart Contracts (for example, revnets built on Juicebox); and
* Acquired by sending assets to those contracts, **not** to Cobuild.
Except where expressly stated in a separate written agreement:
* Cobuild does **not** sell Tokens to you;
* Cobuild does **not** broker trades or act as your agent; and
* All transactions are **unsolicited** and initiated solely by you.
Token functionality (including any floors, ceilings, splits, auto‑issuance, or loan features) is defined by the underlying Smart Contracts and not guaranteed by Cobuild.
For Cobuild Tokens and Revenue Networks built on Juicebox, all issuance, redemption, cash‑out, and treasury‑accounting logic is implemented and executed solely by the underlying **Juicebox / Revnet smart contracts**. Those contracts are part of the Juicebox protocol, governed by Juicebox DAO and its community processes. Cobuild does not:
* issue, burn, or redeem Tokens on your behalf,
* control or custody the assets in Juicebox treasuries, or
* unilaterally change issuance, redemption, or floor mechanics for any Juicebox‑based Token.
#### 5.3 Revenue Networks
The Services may allow you to route a portion of your revenue, tips, or other payments into Smart Contracts that mint Tokens or otherwise credit individuals or communities (**“Revenue Networks”**). For example, you can:
* Configure a percentage of product sales to be sent to a treasury that mints a community’s Token; and/or
* Share minted Tokens with your customers.
By configuring or using any Revenue Network features, you acknowledge that:
* Any routing of funds into a treasury is a transaction with Smart Contracts, not Cobuild;
* Any “buybacks,” “revenue splits,” or “rewards” described in the Interface are implemented solely in those Smart Contracts and may fail or behave unexpectedly; and
* You are solely responsible for any tax, accounting, consumer‑protection, employment, or other obligations arising from using Revenue Networks in your business.
#### 5.4 Cash‑Out Floors, Redemption & Secondary Markets
Some Smart Contracts implement redemption or “cash‑out” functionality that allows Token holders to burn Tokens in exchange for a share of a treasury, often subject to a fee or “cash‑out tax.” These mechanics may be described as a **“floor,” “cash‑out floor,” or “redemption value.”**
You acknowledge and agree that:
* Any such floor is a **mechanical output** of the relevant Smart Contracts and is **not** a guarantee from Cobuild;
* Redemptions may be limited, disabled, throttled, or unavailable at any time due to configuration, upgrades, governance, bugs, exploits, lack of liquidity, network conditions, or other factors;
* Secondary‑market prices on AMMs or other venues may trade **below** or above any onchain redemption value;
* Cobuild does not promise that you will be able to redeem Tokens at any particular price, or at all, and does not backstop shortfalls in treasuries or liquidity; and
* In many cases these treasuries and floors are implemented by third‑party protocols such as the **Juicebox protocol**, governed by Juicebox DAO. Changes, bugs, or governance actions in those protocols can directly affect your ability to mint, redeem, or access treasury assets, and Cobuild has no control over those protocol‑level decisions.
Any references in the Services or docs to a “floor” or “cash‑out value” are descriptive of Smart‑Contract mechanics only, **not** a guarantee of return, downside protection, or capital preservation.
#### 5.5 Loans and collateral
Some Smart Contracts implement Loan functionality that allows Users to borrow assets from a treasury by locking or burning Tokens as collateral.
Unless expressly stated in a separate written agreement:
* Cobuild is **not** the lender and does not underwrite, approve, or advise on Loans;
* All Loan terms (including maximum borrow amounts, fees, durations, collateralization and default mechanics) are enforced automatically by Smart Contracts and may change through upgrades or parameter changes beyond Cobuild’s control;
* If you fail to repay a Loan in accordance with its terms, you may **permanently lose some or all of your collateral and any associated upside**; and
* Loan costs may be economically significant and may exceed returns you could earn elsewhere.
You are solely responsible for evaluating whether any Loan is appropriate for you and for monitoring your positions. Cobuild does not provide margin calls, personalised monitoring, or individual advice.
#### 5.6 Reaction Markets & social‑driven micro‑buys
Reaction Markets treat social‑media engagement as micro‑purchases:
* You pre‑configure budgets and per‑reaction amounts;
* When you engage (for example, like, comment, follow) through enabled flows, Smart Contracts may automatically mint or buy tokens and route them to creators or builders.
By enabling Reaction Markets you acknowledge that:
* Your configured budgets represent **real funds** that can be spent automatically as you interact on supported platforms;
* Engagement signals may be noisy, manipulated, or gamed by others (for example, bots, sybils, engagement‑farms);
* Cobuild does not guarantee that Reaction Markets will allocate capital fairly or in line with your subjective preferences; and
* Cobuild may suspend or adjust Reaction Market features without notice if we believe they are being abused or if required by law.
You are responsible for monitoring your budgets and disabling integrations if you no longer wish your social behaviour to trigger purchases.
***
### 6. Fees, Refunds & Taxes
#### 6.1 Network fees
Any blockchain transaction you submit requires payment of network fees (for example, gas). You are solely responsible for:
* Ensuring you have sufficient balance to cover gas and other network costs; and
* The outcome of transactions you authorise (including failed or reverted transactions).
Cobuild cannot refund gas costs under any circumstances.
#### 6.2 Protocol and administrative fees
Smart Contracts and programs may charge:
* Protocol‑level fees (for example, platform fees, Loan source fees, redemption fees, treasury fees); and/or
* Cobuild **Variable Fees** for operating grant rounds, Flows, or other Services.
Where Cobuild charges a Variable Fee:
* It will be disclosed in the relevant Interface, docs, or program description; and
* Unless expressly stated otherwise, it will **not exceed 5%** of the funds processed for that program.
Protocol‑level fees are set by Smart Contracts or communities and may change outside Cobuild’s control.
#### 6.3 No refunds (except as required by law)
Except where required by applicable law or card‑network rules:
* All gas fees, protocol fees, and Cobuild fees are **non‑refundable**; and
* Application bonds, challenge bonds, and similar staking amounts forfeited by contract are **not refundable** by Cobuild.
#### 6.4 Taxes
You are solely responsible for:
* Determining whether and how any transaction, Loan, reward, stream, or Token interaction is taxable; and
* Reporting and paying any applicable taxes to the appropriate authorities.
Cobuild does not provide tax advice and does not withhold taxes on your behalf unless required by law.
***
### 7. User Responsibilities & Prohibited Conduct
#### 7.1 General obligations
As a condition of accessing or using the Services, you agree to:
* Use the Services only as permitted by these Terms and applicable law;
* Provide accurate, current, and complete information when you choose to provide information;
* Maintain the security of your wallet, devices, and credentials; and
* Notify us promptly at [security@justco.build](mailto\:security@justco.build) if you believe the Services or your account integrations have been compromised.
#### 7.2 Prohibited activities
You agree **not** to:
1. **Break the law.** Use the Services in violation of any applicable law, regulation, sanctions regime, court order, or other legal requirement.
2. **Exploit or attack systems.** Introduce malware; attempt to hack, DDoS, or otherwise interfere with the security or operation of the Services, Smart Contracts, or any infrastructure supporting them.
3. **Market manipulation & fraud.** Engage in rug pulls, wash‑trading, pump‑and‑dump schemes, front‑running using non‑public information, or other manipulative or deceptive practices; impersonate others; submit false or misleading information.
4. **Money laundering & illegal proceeds.** Use the Services to transfer, conceal, or obfuscate proceeds of crime, or to facilitate terrorist financing, sanctions evasion, or other unlawful activity.
5. **IP and content violations.** Upload or link to content that infringes or misappropriates any copyright, trademark, trade secret, privacy, publicity, or other proprietary right; or that is defamatory, obscene, hateful, or otherwise unlawful.
6. **Unwanted automation & scraping.** Use bots, scrapers, crawlers, or similar tools to access the Services, except as explicitly permitted (for example, documented APIs) or under an applicable open‑source license.
7. **Gaming allocation systems.** Attempt to manipulate Flows, Rounds, Reaction Markets, or other allocation mechanisms, including by:
* Creating or coordinating fake or duplicate identities (Sybil attacks);
* Generating artificial or fraudulent engagement (for example, bots, engagement farms) to capture Reaction Market budgets; or
* Colluding to mislead AI Allocation Systems.
8. **Interference with AI systems.** Deliberately provide adversarial inputs to Cobuild’s AI Allocation Systems with the primary intent of degrading their performance, misallocating funds, exfiltrating other users’ data, or probing for confidential model details.
9. **Unsolicited spam & scams.** Use the Services to distribute spam, phishing messages, pyramid schemes, or other deceptive communications.
10. **Other unlawful conduct.** Engage in any conduct that violates applicable law or the rights of others.
Cobuild may restrict or terminate your access to the Services for any behaviour we reasonably believe violates these Terms or creates legal, security, or reputational risk.
***
### 8. Intellectual Property
#### 8.1 Cobuild IP; license to you
Except for open‑source components and third‑party content:
* Cobuild and its licensors own all rights, title, and interest in and to the Services, including software, text, graphics, logos, designs, and other content (collectively, **“Cobuild IP”**).
Subject to these Terms, Cobuild grants you a limited, revocable, non‑exclusive, non‑transferable, non‑sublicensable license to access and use the Services solely for lawful purposes in accordance with this Agreement.
You may not copy, modify, distribute, reverse engineer, or create derivative works from the Services except as allowed by applicable law or by an applicable open‑source license.
#### 8.2 Open‑source components
Where code is released under open‑source licenses, your rights and obligations with respect to that code are governed by the applicable license (for example, MIT, GPL). Such licenses may allow broader use than this Agreement; nothing here restricts your rights under those licenses.
#### 8.3 Trademarks
“Cobuild,” “Just Cobuild, Co.,” associated logos, and other marks are trademarks or service marks of Cobuild. You may not use Cobuild’s marks without our prior written permission, except for nominative fair use.
#### 8.4 User‑generated content & feedback
If you submit content (for example, proposals, posts, text, images, or links) through the Services, then:
* You retain ownership of your content; and
* You grant Cobuild a worldwide, non‑exclusive, sublicensable, royalty‑free license to use, reproduce, display, adapt, distribute, and otherwise exploit that content as reasonably necessary to operate, promote, and improve the Services.
If you submit feedback, ideas, or suggestions, you grant Cobuild a perpetual, irrevocable, worldwide, royalty‑free license to use them for any purpose without compensation to you.
You represent and warrant that you have all rights necessary to grant these licenses and that your content does not infringe any third‑party rights or violate any law.
#### 8.5 DMCA / takedowns
If you believe content accessible via Cobuild‑hosted Services infringes your copyright or trademark, you may send a notice to:
> DMCA Agent\
> Just Cobuild, Co.\
> 131 Continental Dr, Suite 305\
> Newark, DE 19713, USA\
> Email: [legal@justco.build](mailto\:legal@justco.build)
Your notice must include all information required by applicable law (for example, the DMCA). Cobuild may remove or disable access to allegedly infringing material and, where appropriate, terminate repeat infringers.
***
### 9. Privacy & Data
Cobuild’s collection, use, and sharing of personal data is described in the **Just Cobuild, Co. Privacy Policy** below (or at `/legal/privacy` if hosted separately). By using the Services, you acknowledge that your information will be processed as described in that policy.
If these Terms conflict with the Privacy Policy on matters of data processing, the Privacy Policy controls.
***
### 10. AI & Automated Decision‑Making
#### 10.1 Use of AI Allocation Systems
Cobuild uses AI Allocation Systems (including large language models and other algorithms) to help:
* Filter, rank, and score proposals, builders, and content;
* Allocate Bonus Pools or other program funds; and
* Flag potential abuse or sybil patterns.
In some programs, AI Allocation Systems may contribute to decisions about whether and how much funding you receive.
#### 10.2 No guarantees; AI can be wrong or biased
AI outputs can be wrong, biased, incomplete, or inconsistent. Different models or prompts may yield different results. You understand that:
* Participation in any Flow, Round, Reaction Market, or other program does **not** entitle you to funding;
* Cobuild does not guarantee that AI‑driven allocation will be fair, accurate, or aligned with your expectations; and
* Cobuild may override, adjust, or ignore AI outputs in its discretion.
#### 10.3 Rights relating to automated decisions
If you are in a jurisdiction that grants rights in relation to automated decision‑making (for example, GDPR Article 22 in the EU), you may contact us at [legal@justco.build](mailto\:legal@justco.build) to:
* Request more information about how AI is used in a specific program affecting you; and
* Where required by law, request human review of a funding decision.
Cobuild will comply with such requests where legally required and technically feasible.
***
### 11. Security & Vulnerability Reporting
#### 11.1 Security expectations
You are responsible for the security of:
* Your devices and operating systems;
* Your wallets, private keys, and seed phrases; and
* Any credentials or tokens used to access the Services or integrated platforms.
Cobuild cannot recover lost private keys, reverse transactions, or undo interactions with Smart Contracts.
#### 11.2 Reporting vulnerabilities
If you discover a security vulnerability or other serious issue affecting the Services or related Smart Contracts, please report it promptly and privately to:
* **[security@justco.build](mailto\:security@justco.build)**
Cobuild does not currently operate a formal bug bounty program but may, at its sole discretion, recognize or reward good‑faith reports.
Cobuild will not pursue civil action or refer for criminal prosecution researchers who:
* Act in good faith;
* Share vulnerabilities privately with Cobuild;
* Do not exploit them for gain or cause undue harm; and
* Allow a reasonable time for remediation before any public disclosure.
This does not authorize you to access or modify data you are not entitled to or to disrupt the Services.
***
### 12. Assumption of Risk; No Advice; Regulatory Matters
#### 12.1 Blockchain and smart‑contract risks
By using the Services, you acknowledge and accept the inherent risks of cryptographic and blockchain‑based systems, including that:
* Digital assets and Tokens are **highly volatile** and may lose all value;
* Smart Contracts may contain bugs, economic flaws, or vulnerabilities that can be exploited;
* Blockchain transactions are generally **irreversible** once confirmed;
* Networks may experience congestion, forks, reorganizations, or governance changes that affect contract behaviour;
* Bridges, L2s, wrapped assets, and stablecoins introduce additional risk (for example, de‑pegs, bridge exploits); and
* MEV, frontrunning, and transaction ordering by validators or builders may adversely affect your transactions.
You **assume all such risks** when interacting with Smart Contracts or Tokens via the Services or otherwise.
#### 12.2 Revenue‑network & floor risks
Cobuild Tokens and other Tokens accessible through the Services may implement:
* Revenue Networks and treasuries;
* Onchain “floors” and redemption mechanics; and
* Cash‑out taxes or fees.
You understand that:
* Treasury assets may be hacked, drained, misconfigured, or de‑pegged;
* Floors and redemption values may be mis‑calculated, temporarily unavailable, or permanently disabled;
* Secondary‑market prices may be below any theoretical floor or redemption value or may go to zero; and
* You may be unable to redeem or cash out Tokens at the value you expect, or at all.
Any language in the Services or docs about “floors,” “cash‑out value,” “partial downside protection,” or similar effects describes design intent, **not a guarantee**.
#### 12.3 Loan and leverage risks
Loans implemented by Smart Contracts are over‑collateralized and may **not** include margin calls or active risk management. If you take a Loan:
* You may pay substantial fixed fees (which can be significant on an annualized basis); and
* If you fail to repay on time, you may permanently lose your collateral and any associated upside.
Loans may be economically inferior to simply selling or redeeming Tokens and may be treated differently under the laws of your jurisdiction (for example, as credit or securities). You should only take Loans if you fully understand the mechanics and risks.
#### 12.4 AI and allocation risks
You understand that AI Allocation Systems and algorithmic allocation:
* May misinterpret content, miss important context, or exhibit bias;
* May allocate less funding to you than you believe you deserve, or none at all; and
* Are experimental and may be subject to evolving regulation (for example, the EU AI Act).
Participation in any Cobuild‑related allocation system does not create a right to funding or a guarantee of any particular outcome.
#### 12.5 Social‑signal and sybil risks
Allocation mechanisms that rely on social or engagement signals (for example, likes, comments, follows) are subject to:
* Noise and manipulation (for example, bots, sybil attacks, engagement farming); and
* Changing rules and incentives over time.
You may lose funds or miss out on rewards due to other users’ behaviour, market dynamics, or flaws in the mechanism design. Cobuild does not guarantee the integrity of any identity, social signal, or engagement metric.
#### 12.6 No investment, legal, or tax advice
All content provided through the Services (including docs, examples, charts, simulations, and AI outputs) is for **general informational purposes only** and:
* Does **not** constitute investment, legal, tax, or other professional advice;
* Does not consider your personal objectives, financial situation, or risk tolerance; and
* Should not be relied upon to make decisions.
You should consult your own legal, tax, and financial advisors before engaging in any transaction or strategy.
#### 12.7 Unsolicited transactions; no suitability review
Any transaction you initiate using the Services is **unsolicited**:
* Cobuild does not recommend or solicit any transaction;
* Cobuild does not perform suitability or appropriateness assessments; and
* You alone decide whether, when, and how to interact with any Token, Loan, or Smart Contract.
#### 12.8 Regulatory status; no regulated services
Cobuild is **not** intended to operate as:
* A bank, money transmitter, payment institution, or custodian;
* A registered national securities exchange, securities broker, dealer, alternative trading system, or investment adviser; or
* A commodities or derivatives exchange or intermediary.
The Services are designed as **non‑custodial tooling** for interacting with Smart Contracts you choose to use. Trades, Loans, and other transactions occur directly between you and Smart Contracts or other users; Cobuild does not execute, clear, or settle them on your behalf.
Nothing in the Services is intended to constitute or be construed as the provision of regulated “crypto‑asset services” (for example, under the EU MiCA Regulation) or equivalent regimes. You are solely responsible for determining whether and how your use of the Services is permitted in your jurisdiction and for complying with any registration, licensing, or other requirements that apply to you.
***
### 13. Disclaimers of Warranties
To the fullest extent permitted by law:
* The Services (and any content, AI systems, or third‑party integrations) are provided on an **“AS IS” and “AS AVAILABLE”** basis;
* Cobuild and its affiliates, officers, directors, employees, contractors, agents, and licensors (the **“Cobuild Parties”**) make **no warranties of any kind**, whether express, implied, or statutory, including any warranties of merchantability, fitness for a particular purpose, non‑infringement, title, quiet enjoyment, or that the Services will be accurate, reliable, error‑free, secure, or uninterrupted; and
* No advice, information, or statement obtained from the Services (including AI outputs) creates any warranty not expressly stated in these Terms.
You use the Services at **your own risk**.
***
### 14. Limitation of Liability
To the maximum extent permitted by law:
1. **Excluded damages.**\
None of the Cobuild Parties will be liable to you for any:
* Indirect, incidental, special, exemplary, punitive, or consequential damages; or
* Loss of profits, revenue, goodwill, data, or opportunity,
arising out of or in connection with your use (or inability to use) the Services, Smart Contracts, or any third‑party services, even if advised of the possibility of such damages.
2. **Cap on aggregate liability.**\
If, notwithstanding these Terms, a Cobuild Party is held liable to you, the **aggregate** liability of all Cobuild Parties for all claims arising out of or related to the Services or these Terms will not exceed the greater of:
* **USD 100**, or
* The total amount of Cobuild‑specific fees (excluding gas, protocol‑level fees, and amounts paid to third‑party protocols) that you paid directly to Cobuild during the **12 months** preceding the event giving rise to the claim.
3. **Non‑waivable exclusions.**\
These limitations do not limit liability for fraud, intentional misconduct, or any other liability that cannot be limited under applicable law.
#### 14.1 No fiduciary duties
These Terms and your use of the Services do not create any fiduciary duties on the part of Cobuild or any Cobuild Party. To the fullest extent permitted by law, you waive and discla im any such duties that might otherwise exist in law or equity.
***
### 15. Indemnification
You agree to **indemnify, defend, and hold harmless** the Cobuild Parties from and against any and all claims, demands, actions, damages, losses, liabilities, costs, and expenses (including reasonable attorneys’ fees) arising out of or related to:
* Your access to or use of the Services or any Smart Contract;
* Your violation of these Terms or any applicable law or regulation;
* Your infringement or misappropriation of any third‑party right; or
* Any dispute between you and another user or third party.
Cobuild may assume exclusive control of any matter subject to indemnification. You may not settle any claim involving a Cobuild Party without Cobuild’s prior written consent.
***
### 16. Term, Suspension & Termination
These Terms are effective when you first access the Services and continue until terminated as described here.
Cobuild may, at its sole discretion and without liability to you, with or without notice:
* Suspend, restrict, or terminate your access to all or part of the Services; or
* Block transactions originating from or directed to certain addresses, IPs, or jurisdictions,
if we reasonably believe:
* You have violated these Terms or applicable law;
* Your use of the Services creates risk for other users, Cobuild, or any third party; or
* We are required to do so by law, court order, or a regulator.
Upon termination:
* Your license to use Cobuild‑hosted Interfaces ends;
* Onchain Smart Contracts may remain available and continue operating independently; and
* Sections **8–19** survive.
***
### 17. Governing Law & Dispute Resolution
#### 17.1 Governing law
These Terms and any Dispute between you and Cobuild arising out of or relating to the Services will be governed by the laws of the **State of Delaware**, USA, without regard to its conflict‑of‑law rules, and by applicable U.S. federal law.
#### 17.2 Informal resolution
Before starting arbitration or other formal proceedings, you agree to attempt to resolve any Dispute informally by emailing **[legal@justco.build](mailto\:legal@justco.build)** and describing the basis of the Dispute. If the parties cannot resolve the Dispute within **60 days**, either party may commence arbitration as described below.
#### 17.3 Binding arbitration
Except as provided in Sections 17.5 and 17.6, any **Dispute** (any claim or controversy arising out of or relating to the Services, these Terms, or any other acts or omissions for which you may contend Cobuild is liable) will be resolved by **binding arbitration** administered by **JAMS** under its applicable rules (including, where applicable, JAMS’ expedited or mass‑arbitration procedures).
* The arbitration will be conducted by a single neutral arbitrator;
* The seat and venue of arbitration will be **Wilmington, Delaware, USA**, unless the parties agree otherwise; and
* The arbitration will be confidential.
Judgment on the award may be entered in any court of competent jurisdiction.
#### 17.4 Class‑action and jury‑trial waiver
To the fullest extent permitted by law:
* All Disputes must be brought in your **individual capacity**, not as a plaintiff or class member in any purported class, collective, or representative proceeding; and
* You and Cobuild **waive any right to a jury trial**.
Class arbitrations, class actions, private attorney‑general actions, and consolidation of proceedings are **not allowed**.
#### 17.5 Arbitration opt‑out
You may opt out of the arbitration requirement (but **not** the class‑action waiver) by sending an email to **[legal@justco.build](mailto\:legal@justco.build)** with subject line **“Arbitration Opt‑Out”** within **30 days** after you first accept these Terms. Your email must include:
* Your full name;
* A contact email; and
* A clear statement that you wish to opt out of arbitration.
You may also send a written opt‑out notice to:
> Just Cobuild, Co. – Legal\
> 131 Continental Dr, Suite 305\
> Newark, DE 19713, USA
#### 17.6 Small‑claims and injunctive relief
Nothing in this Section prevents either party from:
* Bringing an individual action in small‑claims court if within that court’s jurisdiction; or
* Seeking provisional or injunctive relief in a court of competent jurisdiction to protect its rights (for example, intellectual‑property rights or misuse of the Services) pending final resolution.
***
### 18. Changes to the Services
Cobuild reserves the right, without liability to you, to:
* Add, modify, or discontinue any part of the Services;
* Impose or change eligibility criteria; or
* Impose limits on certain features or restrict access to parts or all of the Services,
where reasonably necessary for technical, legal, regulatory, security, or business reasons.
Cobuild will use reasonable efforts to give notice of changes that materially impact your use where legally required.
***
### 19. Miscellaneous
* **Entire agreement.** These Terms constitute the entire agreement between you and Cobuild regarding the Services and supersede all prior or contemporaneous communications about the same subject matter.
* **Assignment.** You may not assign or transfer these Terms without Cobuild’s prior written consent. Cobuild may freely assign these Terms in connection with a merger, acquisition, reorganization, or sale of assets.
* **Severability.** If any provision of these Terms is held invalid or unenforceable, the remaining provisions remain in full force and effect.
* **No waiver.** Cobuild’s failure to enforce any provision is not a waiver of its right to do so later.
* **Force majeure.** Cobuild is not liable for delays or failures caused by events beyond its reasonable control, including natural disasters, war, labour disputes, government action, internet or blockchain failures, major protocol bugs, or chain re‑orgs.
* **Relationship.** Nothing in these Terms creates a partnership, joint venture, agency, or fiduciary relationship between you and Cobuild.
***
### 20. Plain‑Language Summary (Non‑Binding)
This section is just a human‑readable recap and does **not** change the Terms:
* Cobuild runs non‑custodial Interfaces and tooling; you always control your wallet and interact with Smart Contracts at your own risk.
* Cobuild tokens, floors, revenue networks, loans, and social‑driven allocation are all **experimental** and can fail in many ways. There is no guaranteed downside protection.
* AI helps allocate capital but can be wrong or biased; you are never guaranteed funding.
* Cobuild is not your broker, bank, or investment adviser and is not promising to comply with or satisfy any particular regulatory framework for you.
* Our liability is very limited and disputes are mostly resolved in individual arbitration with no class actions.
***
## Just Cobuild, Co. Privacy Policy
**Effective Date:** December 6, 2025\
**Snapshot:** “Privacy‑first approach for non‑custodial coordination and streaming funding.”\
**Commit Hash:** REPLACE\_WITH\_REPO\_COMMIT
This Privacy Policy (the **“Policy”**) explains how **Just Cobuild, Co.** (**“Cobuild,” “we,” “us,” or “our”**) collects, uses, and shares information in connection with the Cobuild platform, including our Sites, Interfaces, and related Services.
Your use of the Services is also governed by our [Terms of Service](/legal/terms) (or the Terms above, if combined).
***
### 1. High‑Level Summary
* Cobuild is a U.S.‑based company operating non‑custodial tools for onchain coordination and continuous funding.
* The underlying protocols (for example, revnets, Juicebox, Flows contracts) are permissionless and generally not governed by Cobuild.
* We do **not** require user accounts to use core onchain features and aim to collect **minimal personal data**.
* We primarily process:
* **Public blockchain data** (for example, wallet addresses, transactions); and
* Limited technical telemetry (for example, device and browser info) to operate and improve the Services.
* If you choose to give us contact details (for example, email for updates), we use them only for the stated purpose and you can unsubscribe at any time.
* We do **not** sell your personal data or share it for cross‑context behavioural advertising.
* You have privacy rights under GDPR, CCPA/CPRA, and similar laws, which we respect as described below.
* We cannot edit or delete information that is stored on public blockchains.
If this Policy conflicts with the Terms on privacy/data matters, this Policy controls.
***
### 2. Information We Collect
#### 2.1 Public blockchain data
When you connect a wallet or interact with Smart Contracts through the Services, we may process:
* Your public wallet address(es);
* Transaction metadata (for example, function calls, logs, token transfers);
* Program participation data (for example, participation in Flows, Rounds, Reaction Markets); and
* Other onchain information necessary to display balances, activity, and state.
This information is **public by design** and generally visible to anyone who reads the relevant blockchains.
#### 2.2 Technical and usage data
To operate and improve the Services, we may collect limited technical information such as:
* Browser type and version, operating system, language settings;
* Referrer URLs, pages viewed, approximate time spent;
* Aggregated usage patterns (for example, which features are used most); and
* Error logs and basic diagnostics.
We aim to use privacy‑respecting analytics where possible (for example, avoiding third‑party tracking cookies and storing IP or similar identifiers only in a limited, security‑focused way if at all). Where feasible, we honour browser “Do Not Track” (DNT) signals.
#### 2.3 Information you provide directly
You may choose to provide us with:
* **Contact information** – such as email address or social handles, for newsletters, updates, or support.
* **Program information** – such as application forms, grant proposals, or progress updates submitted through Cobuild‑hosted flows.
* **Survey & research data** – if you participate in studies, we collect your responses and any optional biographical information you provide.
* **Support communications** – contents of messages and metadata when you contact us via email, forms, or community channels.
* **Job‑application data** – such as your name, email, resume/CV, and other information you submit when applying for a role.
You are not required to provide this information to use the core non‑custodial features, but certain features (like email updates) will not work without it.
#### 2.4 Compliance & grant‑program data
For certain programs (for example, larger grants, fiat payouts, or where required by law), we may collect additional information such as:
* Full name, country of residence, and contact details;
* Government‑issued identifiers and documents (via third‑party KYC providers);
* Sanctions‑screening or risk‑score results; and
* Tax or payment details required to process certain payouts.
We collect and process such data **only where necessary** to:
* Comply with legal or regulatory obligations (for example, AML/CTF, sanctions); or
* Administer specific funding programs that require identity verification or eligibility checks.
#### 2.5 Social and AI‑related data
If you connect social accounts (for example, Farcaster or X/Twitter) or enable Reaction Markets:
* We may receive identifiers, profile information, public posts, and engagement metadata (for example, likes, replies, reposts) necessary to operate those features and route budgets.
For AI Allocation Systems:
* We may process content you post or link to (for example, updates, proposals, and public onchain data) as input to AI models to help rank, score, or group proposals and builders.
We use such data only to operate allocation features and improve model performance, not to build behavioural advertising profiles.
***
### 3. How We Use Information
We use the information described above to:
1. **Provide and operate the Services**
* Display onchain data (for example, balances, Flows, Rounds, Reaction Markets);
* Facilitate program participation and allocation;
* Run Reaction Markets and social‑driven micro‑buys; and
* Operate Smart‑Contract tooling and interfaces.
2. **Maintain security & integrity**
* Detect, prevent, and respond to fraud, abuse, and security incidents;
* Screen wallet addresses or transactions for known illicit activity using analytics providers;
* Enforce our Terms, including prohibitions on abuse and gaming.
3. **Improve and develop the Services**
* Analyse aggregated usage patterns and UX flows;
* Debug issues and improve reliability and performance;
* Train or tune AI Allocation Systems for better ranking and filtering, using appropriate safeguards.
4. **Communicate with you**
* Respond to support requests or inquiries;
* Send service announcements, security notices, and program‑related messages;
* Send marketing or product updates if you have opted in (you may unsubscribe at any time).
5. **Comply with legal obligations**
* Meet KYC/AML/sanctions and other compliance requirements where applicable;
* Respond to lawful requests from regulators, law enforcement, and courts; and
* Maintain appropriate records.
6. **Research & aggregated insights**
* Produce aggregated or de‑identified statistics about how users interact with the Services, which we may use internally or share publicly (for example, in blog posts or docs).
Where required by law (for example, under GDPR), our legal bases for processing may include:
* Performance of a contract (for example, providing the Services you use);
* Our legitimate interests (for example, improving and securing the Services);
* Compliance with legal obligations; and
* Your consent, where we rely on it (for example, certain marketing communications).
***
### 4. How We Share Information
We do **not** sell your personal information and do not share it for cross‑context behavioural advertising. We may share information as follows:
1. **Service providers**
With third‑party vendors under appropriate contracts who provide services such as:
* Hosting and infrastructure;
* Analytics and telemetry;
* Email and communication tooling;
* Blockchain analytics, KYC/AML, and sanctions screening; and
* Payment or payout processors for certain programs.
2. **Affiliates**
With entities under common control with Cobuild, only where consistent with this Policy.
3. **Program sponsors & partners**
In specific programs, with sponsors or partners to the extent reasonably necessary to:
* Verify eligibility;
* Administer grant or loan programs; or
* Coordinate publicity or reporting.
4. **Legal and compliance**
With government authorities, regulators, or other parties when we believe disclosure is reasonably necessary to:
* Comply with a law, regulation, subpoena, or court order;
* Protect the rights, property, or safety of Cobuild, users, or the public; or
* Detect, prevent, or address fraud, security, or technical issues.
5. **Business transfers**
In connection with a merger, acquisition, financing, reorganization, bankruptcy, or sale of assets, your information may be transferred as part of the transaction, subject to similar protections.
6. **With your consent**
Any other time you expressly consent to a specific disclosure.
We may also share **aggregated or de‑identified data** that cannot reasonably be used to identify you.
***
### 5. Cookies, Local Storage & Similar Technologies
We and our service providers may use:
* Local storage, cookies, or similar technologies to:
* Remember your preferences (for example, imported tokens);
* Maintain session state; and
* Support core functionality.
Where we use analytics or monitoring tools, we aim to:
* Minimise data collection;
* Avoid cross‑site tracking cookies where feasible; and
* Provide controls (for example, browser settings) to limit tracking.
You can usually control cookies and similar technologies through your browser or device settings, which may affect how the Services function.
***
### 6. Data Security
We use commercially reasonable administrative, technical, and physical safeguards to protect information within our control, such as:
* Encrypted communications (for example, HTTPS);
* Access controls and permissioning;
* Secure development and deployment practices.
However:
* No system can be 100% secure; and
* We cannot control the security of public blockchains, third‑party protocols, or your own devices and wallets.
If you believe your interaction with us is no longer secure, contact us at **[security@justco.build](mailto\:security@justco.build)**.
***
### 7. Data Retention
We retain information for as long as reasonably necessary to:
* Provide the Services and support ongoing use;
* Comply with legal, tax, accounting, and reporting obligations;
* Resolve disputes and enforce our agreements; and
* Maintain business records consistent with our legitimate interests.
Retention periods vary by data type and context. When we no longer need information for the purposes described in this Policy, we will delete or de‑identify it, unless we are required by law to retain it longer.
Onchain data (for example, transactions, onchain programme state) is not controlled by Cobuild and generally **cannot be altered or deleted**.
***
### 8. Your Rights & Choices
Depending on your jurisdiction, you may have rights including to:
* **Access** the personal data we hold about you;
* **Rectify** inaccurate or incomplete data;
* **Delete** certain data, subject to legal exceptions;
* **Object to** or **restrict** certain processing;
* **Withdraw consent** where we rely on consent; and
* **Data portability** – receive a copy of certain data in a portable format.
To exercise these rights, contact **[legal@justco.build](mailto\:legal@justco.build)**. We may need to verify your identity before responding. Some rights may be limited by applicable law.
We cannot edit or delete data stored on public blockchains.
#### 8.1 GDPR (EEA, U.K., and similar jurisdictions)
If you are in the EEA, U.K., or a jurisdiction with similar laws, you also have the right to lodge a complaint with your local data‑protection authority if you believe our processing violates applicable law. We encourage you to contact us first so we can try to address your concerns.
#### 8.2 CCPA / CPRA (California residents)
If you are a California resident, you may have rights under the CCPA/CPRA, including:
* The right to know what categories of personal information we collect and how we use them;
* The right to request access to and deletion of certain information;
* The right to correct inaccurate information; and
* The right to non‑discrimination for exercising your rights.
Cobuild does **not** sell personal information as defined under the CCPA/CPRA and does not share personal information for cross‑context behavioural advertising.
You or your authorised agent may submit a request by emailing **[legal@justco.build](mailto\:legal@justco.build)**. We will respond consistent with applicable law and may require additional information to verify your identity.
***
### 9. International Transfers
Cobuild is based in the United States and may process information in the U.S. and other countries that may have different data‑protection laws than your jurisdiction.
Where required (for example, under GDPR), we implement appropriate safeguards for cross‑border transfers, such as:
* Standard contractual clauses; or
* Other mechanisms permitted under applicable law.
By using the Services, you acknowledge that your information may be transferred to and processed in the United States and other jurisdictions as described in this Policy.
***
### 10. Children’s Privacy
The Services are intended for adults and are not directed to children under 13 (or older where local law requires a higher age, such as 16 under GDPR).
We do not knowingly collect personal data from children under such ages. If you believe we have collected personal data from a child in violation of this Policy, please contact us at **[legal@justco.build](mailto\:legal@justco.build)** and we will take appropriate steps to delete it where required.
***
### 11. Changes to This Policy
We may update this Policy from time to time. When we do:
* We will update the “Effective Date” at the top; and
* For material changes, we will provide additional notice via the Services and, where required, seek your consent.
Your continued use of the Services after an updated Policy becomes effective constitutes your acceptance of the updated Policy.
***
### 12. Contact Us
If you have questions about this Policy or wish to exercise your privacy rights, contact us at:
* **Email:** [legal@justco.build](mailto\:legal@justco.build)
* **Mail:**\
Just Cobuild, Co.\
131 Continental Dr, Suite 305\
Newark, DE 19713, USA
import { CashOutFloorChart } from "../../components/CashOutFloorChart";
import { AMMBandChart } from "../../components/AMMBandChart";
## Cash-out floor \[Onchain redemption mechanism]
### Unlimited downside
Traditional token launches also share a darker feature: there is no built‑in way to get your money back from the thing you funded.
Once you buy a token, your fate is in the hands of secondary markets and large holders; if they decide to leave, the price can blast to zero.
Cobuild takes a different approach.
### Cobuild token floor
Every token comes with a cash‑out floor: at any time you can return tokens and receive a slice of the assets sitting in the token's treasury.[^1]
When cashing out, you pay a small fee that stays in the treasury.
You get slightly less than the pro‑rata share and the remainder is left behind. Under normal operation, redemptions are structured so that, when the contract works as intended, they can increase the redemption value for remaining holders.
The design aims to provide a mechanism for partial downside protection by tying redemption value to treasury assets. However, token prices can still fall significantly, and there is no guarantee you will be able to redeem at any specific price or time beyond the cash-out floor.
### AMMs
AMMs trade freely between the mint price and the floor. The core mechanics are designed to work as follows:
The issuance schedule prices earlier mints lower than later mints.
Every token has a built‑in mechanism to redeem against treasury assets.
And as real revenues accrue, the redemption value is designed to increase.
Cobuild tokens wrap these mechanics so communities can focus on building culture and products while the underlying system aims to keep the funding game fair.
[^1]: Cobuild tokens are designed with an onchain redemption mechanism that lets holders redeem tokens for a share of treasury assets, subject to contract terms, available liquidity, and protocol risk.
import { PumpDumpChart } from "../../components/PumpDumpChart";
import { FounderDumpChart } from "../../components/FounderDumpChart";
## Issues Today \[Problems with token issuance]
Most token launchpads and ERC20 sales today are optimized for speculation, not coordination.
They compress the entire funding event into a few minutes, where "being early" means having the right bot and latency setup rather than actually understanding what's being built.
Bonding curves and pump.fun style launches structurally reward whoever's bots show up first, then shift the risk onto everyone who arrives seconds later.
There's no built‑in floor, no obligation from the treasury back to the people who funded it, and once the initial hype passes, late participants are often left holding assets that can drift toward zero with no recourse.
The mechanism treats attention and speed as the scarce resource, not long‑term conviction or contribution.
On top of that, these launches make it hard for founders to get fair, durable working capital.
Teams pre‑mint massive allocations to themselves and gradually dump into their own community's bids just to pay for actual work.
The cleanest way to stay solvent becomes selling into your earliest supporters.
Meanwhile, every project reinvents its own tokenomics: bespoke vesting, ad‑hoc discounts, governance wrappers, hidden admin keys.
Participants have to reason about opaque human promises layered on top of fragile liquidity games.
The result is a funding stack that's great at spinning up short‑lived casinos, but bad at aligning builders, participants, and users around something that can compound over years.
Cobuild is an attempt to solve these issues and more.
import { RevenueFloorChart } from "../../components/RevenueFloorChart";
import { NetworkRevenueChart } from "../../components/NetworkRevenueChart";
## Revenue network \[Real activity, real value]
### Beyond speculation
On a typical bonding curve, the only thing propping up the price is the willingness of later buyers to subsidize earlier ones.
Hype is the main input.
With Cobuild, the input that matters most is real economic activity.
Whenever someone routes revenue or raises money, the treasury grows, and with it the cash-out floor for every holder.
The "worst case" for holders improves as the project actually does business, sells products, runs campaigns, charges fees.
Those flows are captured onchain, and **everyone has an incentive to share revenue.**
The incentive flips from pure greater-fool speculation to something with real skin in the game: help the network earn and propagate, and the minimum you can walk away with increases as long as money keeps flowing through the rails.
### Supercharged buybacks
Anyone in the community can build products and services that feed the treasury.
The mechanism is simple: when you sell something, route a portion of revenue to mint the network's token.
This creates a direct link between your commercial success and the network's growth.
You're not asking for permission or applying for a grant. You're building a business that automatically compounds value back to the community.
#### Why would you do this?
**Build equity as you sell.** Every sale builds your stake in the network you're helping grow.
**Supercharged customer rewards.** You can split the minted tokens between yourself and your customers. A customer who buys your product doesn't just get the product, they get tokens backed by real treasury value.
**No gatekeepers.** You don't need approval to start. The protocol is permissionless. Build what you want, price it how you want, set your revenue split how you want.
#### How it works
1. **Sell your product or service.** Use the network's brand, tooling, and community.
2. **Decide your percentage.** Maybe 10% of each sale goes back to the network.
3. **Buy back the token.** Route that percentage to mint or buy tokens from the network. Split them between yourself and your customer.
4. **Everyone wins.** You get tokens. Your customers get tokens. The treasury grows. The floor rises for everyone.
Unlike traditional stock buybacks, revenue routed to the treasury is designed to back the redemption value. Under normal operation, redemptions are structured to increase the per-token floor for remaining holders.
#### Example
You sell a product for $100. You've configured a 10% revenue split to the treasury.
* $10 routes to mint network tokens
* You receive 70% of those tokens (\~$7 worth at floor)
* Your customer receives 30% (\~$3 worth at floor)
* The customer got the product plus a stake in the network
* You built equity while running your business
* The treasury grew by $10, lifting the floor for all holders
The customer's "rewards" aren't inflated loyalty points. They're tokens backed by the very revenue their purchase contributed.
Now multiply this across dozens or hundreds of builders. Each one selling their own products, routing their own revenue. Your customer's tokens don't just benefit from your sales. They benefit from every sale across the entire network.
This is why customers are more likely to buy: they're not just getting your product, they're holding the same token that ties into activity across the entire network—not just your sales.
### A different kind of network
This model inverts the typical platform relationship.
On traditional platforms, you build on someone else's rails and they extract value from your work.
Here, you build on shared rails and the value you create flows back to you, your customers, and **everyone else building on the network.**
The brand is in the public domain. The treasury is transparent. The rules are encoded, not negotiated.
You're not a tenant. You're a participant building stake alongside a team of thousands with every transaction.
**This is the positive-sum future Cobuild enables.**
import { StagedIssuanceChart } from "../../components/StagedIssuanceChart";
## Staged issuance \[Long term alignment]
### The problem with bonding curves
Most token launches today are slot machines wrapped in code.
If you're early you print, if you're late you're exit liquidity.
The mechanism structurally rewards latency and bot infrastructure rather than real conviction.
"Early" means fast, not thoughtful.
That's backwards: you want to reward people who took real information risk over weeks and months, not whoever sat closest to the mempool.
Cobuild tokens fix this.
### Staged issuance
Cobuild tokens are issued in stages with a pre‑declared price schedule, so early conviction is rewarded over long time windows while nanosecond sniping stops mattering.
Each stage sells tokens at a price that only steps upward over time.
Compared to a bonding curve, the price is linked to the amount of time that has passed, not how many tokens that've been sold.
This moment is always cheaper than the ones that come after, but that advantage accrues to everyone who shows up in the early era of the network, not just a handful of bots.
An example: launch a token, set a mint price of $1 for the first week, $10 for the following month, and stop minting after that.
Supply is uncapped: anyone can mint as many tokens as they want during a stage at the set price.
Founders can reserve a percentage of every mint to maintain ownership.
## Why Crypto \[Understanding onchain fundraising]
Crypto quietly smuggled a new institution onto the internet: anyone can spin up an asset for an idea, push it onto a global market, and have strangers fund it in seconds.
Networks can raise capital not by pitching incumbents, but by selling liquid slices of their story directly to the crowd.
A token becomes a tiny, tradable claim on "this should exist," and 24/7 global markets decide in real time how much that belief is worth.
Seen this way, blockchains aren't just shared computers; they're capital formation machines.
They collapse the distance between "we want to do this" and "we have the funds to make it happen," turning culture and conviction into balance sheet on demand.
Modern coordination, at its core, is two loops: pull capital in (and keep it flowing), then route it toward the work that matters.
Crypto has made the first loop radically easier, but mostly in crude, speculative ways.
Our bet with Cobuild is to close that loop properly: new primitives for allocating capital with high signal, and a new primitive for raising it: revenue networks that let communities plug their real economic activity into onchain rails and turn it into long-term value.
import { FounderDumpChart } from "../../components/FounderDumpChart";
import { SplitAllocationChart } from "../../components/SplitAllocationChart";
import { CashOutComparisonChart } from "../../components/CashOutComparisonChart";
import { LoanCycleChart } from "../../components/LoanCycleChart";
## Working Capital \[Pay the bills without selling]
A major failure mode of existing token launches is how founders get working capital.
To pay for work, teams pre‑mint huge allocations to themselves and periodically dump into their own community's bids.
The **cleanest way for a founder to pay rent is to sell out the people who believed earliest.**
### Splits
Cobuild solves this dynamic.
Each Cobuild token can specify how newly minted tokens are split: a fixed share of every new issuance is earmarked to fund builders, and that rule is locked in at deploy time.
For example, with a 20% split rate, when someone buys 100 tokens, 20 tokens automatically route to builders.
### Cashing out
When you need working capital, you can cash out against the treasury instead of dumping on the market.
You pay a small exit tax that stays in the treasury, raising the floor for all remaining holders.
Instead of selling out early believers, you get capital and everyone else's position improves.
### Loans
More powerfully, anyone can use their tokens as collateral for loans instead of market‑selling.
Cobuild natively enables loans backed by each token's treasury.
Lock your tokens, take cash from the treasury, use it for a year or two to fund operations, pay back the loan, and your original tokens return to your wallet. You never lost your position. You never sold anything.
As a builder, you mortgage your future contribution to the network, not your community's trust. The interest paid on those loans feeds back into the treasury, nudging the floor higher for all holders.
For a deeper dive into builder economics—how splits compound, when to cash out vs borrow, and optimal strategies—see [Builders](/economics/builders).
## Zero Governance \[Incentive alignment without governance]
Most tokenized networks entangle participants in bespoke governance and liquidity games.
Someone can change parameters mid‑flight, pull liquidity, or rewrite the rules once enough value is in the system.
Staking rewards and buybacks are subject to the same risks.
That uncertainty is another hidden tax on coordinators: you spend attention modeling the humans behind the contract instead of the contract itself.
Cobuild strips the problem down to a small, inspectable machine: a schedule for how expensive new tokens are, a rule for how cash‑outs work, and an optional split that decides who shares in new issuance.
Once deployed, no one can arbitrarily move the goalposts.
Cobuild aligns long-term participants, builders, and users with hard-coded incentives.
import { BuilderFloorEffect } from "../../components/BuilderFloorEffect";
## Builders Payouts \[Ways to get working capital]
*Hold vs Sell vs Cash-out vs Loan - for long-term contributors*
This page covers **what's rational for builders** to do with their split share once the cobuild is live, assuming:
* High conviction over a 5-10 year horizon
* A meaningful split (often 10-40% of supply early on)
**TL;DR**
* If you believe the cobuild will grow over years, your default is:\
**hold most of your split, use loans for working capital, and sell only when you consciously want to reduce exposure.**
* Cash-outs are a clean way to exit but remove treasury; loans give you liquidity *and* support the floor.
* Occasional AMM sells are fine for liquidity needs; just don't turn your founder stack into a constant sell wall.
### Your Split
Your split is not "free tokens." Each token is:
* **Tied to treasury assets** via a redemption mechanism\[4]
* A **source of borrowing power**, because loans are priced off that same curve and are designed to be over-collateralized
What you do with those tokens feeds back into everyone else's position:
* **Cash-outs (redemptions)**
* Burn your tokens
* Pay you from the treasury
* Designed to *increase* the floor price for remaining holders, because supply falls faster than the treasury
* **Loans**
* Burn your collateral at origination
* Lend you *less* than you'd get from redeeming
* Also *increase* the floor at origination (same mechanics as a discounted cash-out, plus loan fees)
* **AMM sells**
* Do **not** touch the treasury at all
* Just move tokens from you to someone else inside the corridor between floor and ceiling
* Floor and treasury stay unchanged
So you're always trading off:
> **Personal liquidity now** vs **future upside + network health**.
### Basic Moves
With split tokens you can:
#### Hold
Do nothing. You stay fully exposed to:
* Rising issuance price (ceiling)
* Activity-driven floor growth from other people's issuances, cash-outs, and loans
Good if:
* You don't need cash right now
* You're maximally bullish and happy being "all-in" on upside
#### Cash-out
Burn tokens and withdraw base asset at the bonding-curve price minus cash-out tax and protocol fees.
* You receive slightly *less* than the backing value per token
* The tax stays in the treasury → designed to increase the floor for those who stay
* When the tax is > 0, the mechanics are structured so that each cash-out can raise the per-token redemption value for remaining holders
Use this when:
* You **intentionally want to reduce exposure** (e.g. stepping back or leaving the project)
* You're okay with "selling" some upside to reward remaining holders
#### AMM Sell
Swap tokens at the current market price (between floor and ceiling).
* No cash-out tax
* Treasury & floor don't change
* You just move tokens from "you" to "someone else"
Best for:
* **Small, periodic liquidity needs** (taxes, personal runway)
* Situations where there's good AMM liquidity and you don't want to touch the treasury
#### Loan
Use tokens as collateral to borrow from the treasury instead of exiting. See [Loans](/economics/loans) for full details on fee structure and costs.
* Collateral is **burned** at origination
* You can borrow up to \~63-95% of your cash-out value (depending on loan duration)
* When you repay, collateral is **reminted** to you
Intuition:
> A loan is like selling your tokens at a discount now **with the option** to buy them back later at today's floor price, plus a fixed fee.
### Default Strategy
If you have 5-10 year conviction, the baseline play is:
> **Hold most of your split; use loans to fund work and salary; sell rarely and deliberately.**
From the math, a loan beats holding when you can deploy borrowed capital at a return that exceeds the loan fees — roughly **5-6%/yr** for long-term loans, **11-13%/yr** for short-term. See [Loans](/economics/loans) for the exact thresholds.
### Founder Salary
Suppose you're a founder with a big split and you just want to pay yourself a normal salary.
#### Option 1: Sell
Pros:
* You get full AMM/floor value today
* No future obligation
* Simple to reason about
Cons:
* You permanently reduce your future upside
* If you sell heavily, you become your own sell pressure
This is "classic equity sell-down": safe but de-levered.
#### Option 2: Loan
Here you:
* Borrow against a portion of your stack (say 10-30% of your split)
* Use that to pay yourself over some years
* Plan to repay from future revenue or occasional, smaller token sales
Mentally, you're doing:
> "I'm selling a chunk of my tokens at a discount **to my future self**, not to the market."
Rational when:
1. You expect the floor to grow steadily (a few % per year or more), and
2. You're confident your future income (from the project or otherwise) can handle eventual repayment.
If things go well:
* Floor grows, your salary was funded, and you still own most of your original position at a much higher value.
* The \~37-40% fee on a 10-year loan looks cheap in hindsight.
If things go poorly:
* Floor stagnates or falls
* Repaying hurts, and defaulting effectively means "I sold those tokens years ago at \~60-65% of what I could have redeemed then"
* System stays solvent; you just own less of it
That's the real trade:
> **Debt + more upside** vs **no debt + less upside**.
#### Option 3: Hybrid
A very sane founder pattern:
* Use **small, rolling loans** on a minority of your stack (10-30%)
* Keep the rest unlevered
* Re-assess annually: only roll or increase if floor growth and cashflow actually support it
This keeps you:
* Aligned for the long term
* Liquid enough to live
* Away from "all-in leveraged founder" risk
### System Effects
From the formal analysis, different actions affect the floor and treasury in predictable ways:
* **Issuance (users buying from the cobuild)**
* Increases treasury and supply
* Increases the floor whenever issuance price > current backing per token
* **Cash-outs (including yours)**
* Reduce both treasury and supply
* Designed to *increase* the floor when there's a cash-out tax
* **Loan originations**
* Reduce treasury and supply (collateral burned, funds lent out)
* Designed to *increase* the floor due to over-collateralization and fees
* **Loan repayments**
* Increase treasury and supply (collateral reminted)
* Slightly *reduce* the floor vs the origination point, though the prepaid/time fees keep the full loan cycle net-positive for the system
* **Auto-issuances**
* Increase supply with no treasury inflow
* Mechanically *decrease* the floor and should be used sparingly
Implication for builders:
* **Best for network & you**: use loans for working capital, repay when the project is healthy.
* **Neutral**: occasional AMM sells.
* **Heavy early redemptions and big auto-issuances**: mechanically drag on the system and should be reserved for exceptional cases.
### References
\[1] Cryptoeconomics of Revnets - formal analysis of issuance, redemption, loans, and rational holder behavior.
\[2] Revnet Value Flows as a Continuous-Time Dynamical System - derivation of the floor dynamics and neutral line in terms of issuance/redemption rates.
\[3] Revnet Analysis - simulation results and archetype guidance (Launchpad, Stable-Commerce, Periodic Fundraising), including tax-regime and auto-issuance effects.
\[4]: The redemption mechanism allows holders to redeem tokens for a share of treasury assets, subject to contract terms, available liquidity, and protocol risk. Redemption is not guaranteed.
import { PriceCorridorChart } from "../../components/PriceCorridorChart";
## Designing a Cobuild
When you launch a cobuild, you lock in a small set of rules that define how money and tokens move forever. Those rules live in *stages*-time windows with fixed settings. Within each stage, you choose five main levers:
1. **Stage cadence** - How often the rules change (length and number of stages).
2. **Issuance curve** - How the token's issuance price rises over time.
3. **Split %** - What share of newly minted tokens goes to preset recipients (team, partners, other contracts) vs the buyer.
4. **Auto-issuance** - One-time token mints that happen automatically at stage start.
5. **Cash-out tax** - The % fee paid when someone redeems tokens for treasury assets.
### The price corridor
Under the hood, these parameters interact with two mechanical facts:
* **Ceiling**: the current issuance price (plus splits). Nobody pays more than they can mint for.
* **Floor**: the redemption value, roughly `treasury ÷ supply`, adjusted by protocol fees and the cash-out tax.
Every issuance, redemption, loan, or auto-issuance moves either the treasury or the supply, which nudges that floor up or down.
Think of this as "write once, run forever." There's no governance switch to fix a misconfigured curve later. Picking parameters is about picking **incentives**:
* **Urgency vs accessibility** - Is this a rush-to-get-in launch, or an open, calm system?
* **Builder funding vs community allocation** - How much supply funnels to the team vs buyers?
* **Liquidity vs loyalty** - Do you make it cheap to exit, or reward people who stick around?
import { RunawayChart } from "../../components/RunawayChart";
import {
TaxComparisonChart,
FlatIssuanceChart,
AutoIssuanceChart,
LiquiditySpiralChart,
} from "../../components/FailureModeDiagrams";
## Failure Modes
This page covers the main ways a cobuild can "go wrong" from an economic/holder perspective, and how to design around those risks.
### Ceiling Runaway
#### What It Is
The issuance price (ceiling) keeps stepping up, but **market price can't keep up**. Eventually `P_AMM` sits near the floor while `P_ceil` rockets away. Rational users stop minting from the contract (why buy at the ceiling if AMM is cheaper?), so **issuance halts** and new inflows go only to the AMM.
#### Why It's Bad
* Treasury `B` stops growing from new sales.
* Floor `P_floor ∝ B/S` only grows via redemptions and loan fees, not new primary inflows.
* In a speculative-only system, a confidence shock can trigger exits → redemptions drain AMM liquidity → price gets more volatile → more exits (a liquidity spiral).
#### Guardrails
* **Match ceiling growth to real demand.** For service-coupled systems, target ceiling growth loosely in line with expected revenue growth instead of "number go up" curves.
* **Stage AMM depth.** Don't deploy huge AMM liquidity before you have recurring real activity. Shallow but healthy initial liquidity + steady service inflows can naturally pull `P_AMM` back toward `P_ceil`.
* **Monitor the gap.** Track `P_ceil / P_AMM`. If the ratio stays very high for long periods, you're likely in runaway; future stages should be flatter.
### Tax Too Low
#### Symptoms
* Holders treat the token as fully liquid money.
* During stress, everyone **redeems** instead of borrowing.
* Floor growth relies mainly on *volume* rather than per-exit gains.
#### Design Facts
For `rₖ` well below \~19%, models show the system is **exit-dominant** in stress: rational actors pick redemption, not loans.
#### Guardrails
If you want **sticky capital** and loan usage, avoid very low taxes (e.g. \<2-3%) unless it's a deliberate "currency" design.
### Tax Too High
#### Symptoms
Rational myopic users avoid cashing out; large holders may borrow as much as possible, then **default** if long-term growth doesn't materialize (system is still solvent, but effective exits route through loans).
#### Design Facts
* Around **39%**, loans can give more immediate liquidity than cash-outs for big holders.
* Higher `rₖ` raises the **growth required** to make borrowing worth it vs exiting.
### Flat Issuance
In a "loyalty token" / business currency setup:
* If **issuance price stays flat forever**, the floor converges to a fixed % of that price and then **stops growing**. At that point rational users have no reason to hold; they'll gradually exit.
### Aggressive Auto-Issuance
Auto-issuance (pre-scheduled mints to team) **always lowers the floor**, because supply jumps but treasury doesn't.
#### Symptoms
* Sudden drop in floor value at stage transitions.
* Community perception of "stealth dilution".
#### Guardrails
* Keep auto-issuance **small and infrequent**.
* Schedule it **after periods of strong organic growth** so the floor hit is absorbed.
* Prefer **ongoing splits** for builder funding instead of large one-time auto-mints.
### Speculative Demand
If your cobuild has no real product or revenue and relies entirely on traders:
* During good times, everything looks fine.
* During bad times: Redemptions raise the floor but **drain AMM liquidity**, increasing volatility and discouraging new buyers.
#### Guardrails
* Anchor the cobuild to **real activity** (fees, sales, usage).
* Avoid over-sizing the AMM relative to real inflows.
* Use **periodic fundraising** archetype (timed rounds, moderate tax) instead of an always-on, high-slope speculative curve.
## Holder Behavior Modeling
import { StrategyHeatmap } from "../../components/StrategyHeatmap";
This page models how economically rational participants might behave given a cobuild's mechanism design—choosing between **redeeming**, **holding**, or **borrowing** based on network outcomes.
### Three Available Actions
At any time, a holder with `q` tokens has three options:
**1. Redeem**
Burn tokens for a share of the treasury (paying the cash-out tax) or sell on an AMM at market price (which arbitrage keeps between floor and ceiling).
**2. Hold**
Take no action and remain exposed to future changes in floor / AMM price.
**3. Borrow**
Burn tokens as collateral, borrow less than their cash-out value, and optionally repay later to remint. Because loans are priced off the same convex redemption curve, they are always over-collateralized; the system remains solvent even if all loans default.
The stage parameters determine which action is individually rational under different scenarios.
### Immediate Liquidity Needs
First, consider a purely **myopic** scenario where future expectations are ignored. A participant simply asks:
> "I need liquidity now. Should I redeem or borrow?"
The relevant variables are:
* **Cash-out tax** `rₖ`
* **Net loan proceeds factor** `a` (what % of collateral's cash-out value is received after fees)
* **Position size as fraction of supply** `x = q / S`
#### Redemption vs Borrowing
When cash-out tax is below \~39%, redeeming yields more immediate liquidity than borrowing. Most cobuilds use 10–20% tax, so in practice: **for immediate liquidity needs, redemption dominates.**
Only at very high taxes (40%+) does borrowing begin to compete for large holders seeking immediate liquidity.
### Forward-Looking Scenarios
Now consider participants who account for expected outcomes between **time `t₀`** and **future time `t₁`**.
Three variables matter:
* **External opportunity cost `R`** — alternative yield available elsewhere (DeFi, treasuries, etc.)
* **Expected token appreciation** — floor / AMM price growth between `t₀` and `t₁`
* **Loan fee level `a`** — net proceeds as fraction of collateral value
We model three outcome scenarios:
1. **Unsuccessful network** — token underperforms alternatives
2. **Moderate success** — steady but modest appreciation
3. **Strong success** — sustained compounding over years
### Unsuccessful Network Scenario
In this model, participants believe:
* "Alternative opportunities outperform this token."
Formally, redemption beats holding when:
```text
(1 + R) > P_sell(t₁, q) / P_sell(t₀, q)
```
In this scenario:
* **Redemption dominates holding** — If expected token appreciation is worse than external yield, rational behavior is to redeem and reallocate.
* **Borrowing vs holding** — For participants who want to maintain some exposure while reallocating capital, borrowing only beats holding if external return `R` clears the fee threshold:
```text
R > (1 − a) / a
```
With default loan parameters:
* **6-month loan (`a ≈ 0.94`)** — Requires \~6% return over 6 months (\~12% annualized)
* **10-year loan (`a ≈ 0.63`)** — Requires \~60% total return over 10 years (\~5–6% annualized)
In an unsuccessful network model:
> **Most rational participants redeem.**
> Borrowing only makes sense if external yield is genuinely attractive *and* the participant wants to maintain some token exposure.
### Moderate Success Scenario
Assume the network performs adequately:
* Floor / AMM price drifts up over time
* But not by large multiples
With **minimal external yield** (`R ≈ 0`), the key comparison is **borrowing vs redemption**.
With no external yield, borrowing only makes sense if expected token appreciation beats the loan fee.
For typical parameters:
* **6-month loan (`a ≈ 0.94`)** — Requires \~6% floor / price growth in 6 months (\~11–12% annualized)
* **10-year loan (`a ≈ 0.63`)** — Requires \~37% total floor growth over 10 years (\~3–4% annualized)
In a moderate success model where floor growth of \~4–5% annually seems plausible:
* **Holding** is rational over redeeming
* **10-year loans** become viable: slow but steady growth covers the loan fee, and borrowed capital can be deployed elsewhere
If expected growth is below \~3% annually:
* **Holding** may still be rational for those who value the exposure
* **Loans add little value** unless external yield `R` is non-trivial
### Strong Success Scenario
This models a network that achieves product-market fit: real revenue and a floor that compounds over years.
#### Redemption vs Holding
Holding beats redemption when expected appreciation exceeds external opportunity cost:
```text
Hold beats Redeem when:
P_sell(t₁, q) / P_sell(t₀, q) > (1 + R)
```
In this regime, optimistic participants hold or acquire more. Redemption is for those who believe they can do better elsewhere.
#### Loan Thresholds
Two thresholds emerge:
* **Borrowing vs Holding**
For participants maintaining exposure either way, borrowing beats simply holding when external return on borrowed capital clears:
```text
R > (1 − a) / a
```
For a 10-year window (`a ≈ 0.63`), that's the **\~60% total over 10 years (\~5–6%/yr)** threshold. Once external yield beats that, **"hold + borrow"** strictly dominates **"just hold"**.
* **Borrowing vs Redemption (with `R ≈ 0`)**
If external opportunities are limited and loans are mainly used to access liquidity sooner, the relevant condition is that token appreciation beats the fee: roughly **\~37% total over 10 years (\~3–4%/yr)** for long-dated loans.
In other words:
* If token growth of **\~1.4× over 10 years** (\~3–4% annualized) seems plausible, long-dated loans are individually rational vs immediate redemption.
* If external yield of **\~5–6% annually** is achievable, loans become compelling vs just holding—participants keep exposure *and* earn yield on borrowed capital.
Both conditions can easily hold in a successful network, so rational behavior in this scenario is:
* **Don't redeem**
* **Do hold**
* **Use loans opportunistically** when good external opportunities or liquidity needs arise
### Parameter Effects
Stage parameters don't just change the math—they also signal what *kind* of behavior the network is designed for.
#### Cash-out Tax
| Tax Range | Behavioral Signal |
| --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
| **Low (\~0–10%)** | "If you're bearish or need liquidity, you can leave cheaply." Expect more **redemptions**, less loan usage, more trading & churn. |
| **Medium (\~10–20%)** | Balanced regime: redemption is still viable, loans are usable, and each redemption pushes the floor up meaningfully. |
| **High (≳20–40%+)** | You're heavily penalizing redemption. Large rational holders are nudged toward **loans** over redemptions for liquidity, especially short-term. |
Higher cash-out taxes discourage immediate redemption, but also require stronger long-term growth to make loans worthwhile versus just leaving.
#### Issuance Growth
* Faster issuance cuts (steeper ceiling) create more growth potential and make **holding + borrowing** more attractive if the network succeeds.
* But if the ceiling outruns reality for too long, you enter the **"runaway" regime**:
* new issuance effectively stops
* inbound flows mostly route through the AMM
* AMM liquidity can thin out if demand is mostly speculative
Calibrating the ceiling so it roughly tracks plausible long-term demand is key to avoiding multi-year runaway.
### Summary
Parameter choices implicitly select for certain behavioral patterns:
* **High uncertainty and churn expected** → tilt toward **lower cash-out tax**, accept more redemptions, and lean on floor mechanics to reward those who stay.
* **Strong long-term growth expected** → design for:
* a **modest-high cash-out tax** (to reward stayers and enable loans)
* an issuance schedule that doesn't outpace realistic demand (to avoid runaway)
* clear UX around loans as the primary liquidity mechanism that preserves exposure
import { IssuanceCurvesChart } from "../../components/IssuanceCurvesChart";
import { ClosingIssuanceChart } from "../../components/ClosingIssuanceChart";
import { CurveTypeChart } from "../../components/CurveTypeChart";
## Stage Cadence & Issuance Curve
This page is about shaping the **ceiling**: the price users pay to mint new tokens over time.
Inside each stage you configure:
1. **Stage duration** - how long this stage's rules last.
2. **Initial issuance price** - starting price at the beginning of the stage.
3. **Issuance cut %** - how much issuance per dollar falls each step (equivalently, how much price rises).
4. **Issuance cut frequency** - how often you apply that cut (daily, weekly, monthly…).
The contract treats the issuance price as a step function: it stays flat within each interval and jumps up by a fixed factor on a fixed schedule. The result is a time-rising ceiling that doesn't care what the market does.
### What the curve controls
Your issuance curve sets:
1. **Urgency** - how much it feels like "get in now or pay way more later."
2. **Accessibility** - how expensive it will be for people who discover you late.
3. **Treasury growth pattern** - front-loaded in a sharp curve vs spread out in a gentle one.
4. **Runaway risk** - whether the ceiling can outrun the market price so much that primary issuance basically shuts off.
### Steep curve (high cut%, short interval)
**Why you'd choose it:**
* You want a high-energy token launch with strong FOMO.
* You expect most of the capital to arrive in a short window.
**What it does:**
* Weekly or daily jumps (+20-30%/week) mean early buyers pay dramatically less than late ones.
* Treasury grows extremely fast while issuance is active.
**Tradeoffs:**
* Latecomers can feel "too late" after just a few jumps.
* If the secondary market price can't keep up with your ceiling, you hit a **runaway** regime: buyers stop minting from the contract and just trade on the AMM instead, so treasury growth stalls.
### Gentle curve (low cut%, longer interval)
**Why you'd choose it:**
* You want calm, recurring participation (subscriptions, SaaS, commerce).
* You want late users to still feel early-ish.
**What it does:**
* Small, infrequent jumps (≈3% per quarter) keep ceiling and floor very close together.
* The token behaves more like a revenue-backed currency than a speculative asset.
**Tradeoffs:**
* Less event-driven hype.
* If growth is too flat, rational users will just cash out instead of borrowing against tokens, because there's no expected appreciation to justify loans. Commerce-style cobuilds need roughly **≥3% per quarter** issuance growth to keep loans attractive.
### Stepwise curve (big jumps between stages)
**Why you'd choose it:**
* You want regular fundraising "rounds", seasons, or milestones.
* You want marketing windows where people know "next month the price jumps 50%".
**What it does:**
* Within a stage, price is flat; at the boundary, it jumps +40-50%.
* Each stage becomes a mini-launch with its own story and metrics.
**Tradeoffs:**
* Floor tends to follow a "sawtooth": each new round pushes the ceiling up, and activity in the round pulls the floor up toward it.
* Requires you to actually deliver something each round to justify the step.
Use this for **Periodic Fundraising** cobuilds.
### Closing issuance
You can configure a cobuild to **fully stop minting new tokens** after a certain date by adding a final stage with issuance disabled. Once this stage begins, no new tokens can be minted from the contract-ever.
**Why you'd do it:**
* Create a fixed supply cap after an initial distribution period.
* Signal commitment: "this is all there will ever be."
* Shift focus from primary issuance to secondary trading and cash-outs.
**How it works:**
Set up your active issuance stage(s), then add a final stage with duration set to "forever" and issuance set to 0. When that stage activates, the ceiling effectively disappears-there's no price at which new tokens can be minted.
**Common pattern:** Many launchpad-style cobuilds use a short issuance window (30-90 days) followed by a closed stage. This creates urgency during the launch, then locks in the supply permanently.
### How to pick your curve
Ask yourself:
1. **Revenue shape** - Are your inflows spiky (drops/campaigns) or smooth (subscriptions, fees)?
2. **Onboarding horizon** - Do you care more about the next month, or about steady onboarding over years?
3. **Hype vs trust** - Is your audience excited by sharp events, or comforted by stability?
Then:
* If you want **hype, fast treasury bootstrapping, and secondary trading** → short stage, steep curve.
* If you want **loyalty and stable pricing** → long stage, gentle curve.
* If you want **recurring narrative beats and staged capital** → multiple stages with big step increases.
## Loans
Cobuild loans don't have a floating APR. They're **fixed-fee loans with a tunable fee-free window and a hard 10-year limit**.
The upfront payment (the **source fee**) is configurable. It determines the **interest-free period**. After that period, an additional time-based source fee ramps up until a cap, and after 10 years the loan can no longer be repaid (it's administratively liquidated).
### How It Works
High-level:
* Tokens are used as collateral to borrow the base asset from the treasury **instead of** cashing out.
* The collateral is **burned at origination**.
* The **maximum borrowable amount before fees** is the **cash-out value** of that collateral on the bonding curve.
* After protocol / REV / source fees, the participant receives a percentage of the cash-out value:
* **Short window (\~6 months)** → \~94%
* **Max window (10 years)** → \~63%
So the participant is effectively accessing liquidity at a **discount to the cash-out value**, with the option to restore their position later by repaying the loan.
On repayment:
* The participant chooses how much collateral to restore.
* That fraction of the original collateral is **reminted**, and the loan obligation shrinks accordingly.
* Full repayment before the 10-year deadline restores all collateral.
* After 10 years, the loan can be liquidated: accounting is updated, collateral remains burned, and the treasury stays solvent.
**Intuition:**
A loan ≈ *"access liquidity at a discount today, while preserving the option to restore the original token balance later at (roughly) today's floor price, plus a fixed fee."*
### Fee Layers
When a loan is originated, three fees are deducted from the loan amount immediately:
| Fee type | Approx % | Paid to |
| ---------------- | --------------------------------- | ---------------- |
| **Protocol fee** | ≈ **2.4%** | $NANA / Juicebox |
| **REV fee** | ≈ **1.0%** | $REV revnet |
| **Source fee** | ≈ **2.4% – 33.3%** (configurable) | The cobuild |
After fees, the participant receives:
* **Short window (\~6 months)** → \~94% of the cash-out value
* **Max window (10 years)** → \~63% of the cash-out value
**Minimum upfront cost (6-month config):**
* Protocol + REV + smallest source fee
* ≈ 2.4% + 1.0% + 2.4% ≈ **5.9% of the amount borrowed**
### Prepaid Duration
The chosen **source fee** determines the **fee-free repayment window**:
| Source fee | Fee-free window |
| ---------- | --------------- |
| \~2.4% | \~6 months |
| \~5% | \~1 year |
| \~9% | \~2 years |
| \~20% | \~5 years |
| \~33% | \~10 years |
**After the prepaid window ends:**
* A **time-based source fee** starts accruing.
* It ramps up smoothly from 0 and, at the 10-year limit, can add **up to \~50% of the *un-prepaid* portion** of the loan as extra source fee.
* For typical configurations, **total source fees over 10 years fall in the 50–65% of principal range**, depending on the initial prepayment amount.
There is **no compounding APR**. The structure is:
> upfront % → X years of "no additional interest" → after that a growing late fee accrues, capped by the 10-year limit.
### Cost by Horizon
A property of the fee formulas:
**For a given repayment horizon T, the minimum-cost configuration is always "prepay exactly T years".** Under-prepaying and repaying late is strictly more expensive.
Key horizons, assuming repayment by the end of the prepaid window:
#### 5-Year Loan
* \~**20% source fee** → **5-year** fee-free window.
* Total one-time cost (protocol + REV + source):
≈ 2.4% + 1.0% + 20% ≈ **23–24% of the amount borrowed**.
* Simple average over 5 years: **\~4.7%/yr** (non-compounding).
#### 10-Year Loan
* \~**33% source fee** → **10-year** fee-free window.
* Total one-time cost (protocol + REV + source):
≈ 2.4% + 1.0% + 33.3% ≈ **\~36–37% of the amount borrowed**.
* Simple average over 10 years: **\~3.7%/yr**.
#### Under-Prepaying
Example: a **6-month** prepay (\~2.4% source fee) with actual repayment **5 years** later:
* Total cost on that 5-year horizon ≈ **37% of principal**
(vs \~23–24% with a 5-year prepay).
* Simple average: **\~7.4%/yr**.
A 6-month prepay extended to the **10-year limit** results in ≈ **55% total cost** of principal.
The mechanism is designed such that:
> Matching the prepaid window to the actual repayment horizon minimizes total fees. Under-prepaying and repaying late always costs more in total percentage terms.
### Loan Use Cases
The loan mechanism serves several practical purposes:
* **Working capital**: Builders who need liquidity for operations without permanently reducing their position.
* **Bridging timing gaps**: When a participant expects future income but needs funds now.
* **Maintaining alignment**: Accessing liquidity while preserving the option to restore one's original token balance later.
The fixed-fee structure makes costs predictable—participants know the total cost at origination rather than facing variable rate uncertainty.
### 10-Year Mechanism Properties
With the max-prepay 10-year configuration:
* The participant pays **\~36–37% of the cash-out value** of their collateral as a one-time fee, in exchange for **10 years of liquidity**.
* The mechanism preserves:
* The option to restore the original token balance at any point before the deadline.
* The repayment amount is fixed at origination—it does not change if the floor moves.
This design allows long-duration liquidity access while keeping costs bounded and predictable.
### Rolling Loans
Participants **can refinance**, but **cannot reuse the same collateral twice**:
* Collateral is burned and tied to a specific loan until repayment or default.
* To open a new loan:
* Repay the existing loan,
* Collateral is reminted,
* A new loan can then be opened at the current floor.
Each cycle:
* Incurs a fresh set of fees.
* Reduces the participant's net token position over time.
The **loan → repay → loan** pattern allows participants to access liquidity across multiple periods while maintaining their token balance.
### TL;DR
* No floating APR; a **front-loaded fee** determines the **fee-free repayment window (up to 10 years)**.
* Protocol + REV fees total **\~3.4%** on top of the chosen source fee.
* When **prepay matches horizon and repayment is on time**:
* \~6-month: **\~6%** total cost.
* **5-year**: **\~23–24%** total (\~4.7%/yr simple).
* **10-year**: **\~36–37%** total (\~3.7%/yr simple).
* **Under-prepaying with late repayment** increases total cost (e.g. 6-month prepay with 5-year repay → \~37% total; 6-month prepay extended to 10 years → \~55% total).
* **No compounding interest** and no unbounded debt growth; everything is bounded by the 10-year design.
All percentages are of the **amount borrowed** and exclude gas and token price volatility; rounded for clarity, but the structure matches the cobuild math.
## Cobuild Token Economics
Cobuild tokens are built on top of [Revnets](https://revnet.app/) - autonomous revenue networks that tokenize payments with locked issuance and cash-out terms across stages.
Revnets are built on [Juicebox](https://juicebox.money/), the programmable treasury protocol behind [ConstitutionDAO](https://en.wikipedia.org/wiki/ConstitutionDAO) - the historic crowdfund that raised $47M in under a week to bid on a copy of the U.S. Constitution.
This stack gives Cobuild tokens battle-tested, audited smart contracts that have processed hundreds of millions in onchain payments.
### The Original Memo
* [Revnet Memo](https://rev.eth.sucks/memo/) - The original revnet specification
* [Revnet Blog](https://blog.revnet.app/blog/) - A blog with some older writings on revnets
### Further Analysis
* [Cryptoeconomics of Revnets](https://docs.co.build/revnet/Revnet-Whitepaper.pdf) - Mathematical analysis of holder behavior, loan thresholds, and floor dynamics
* [Revnet Parameter Analysis](https://docs.co.build/revnet/Revnet-Analysis.pdf)
* [Revnet Value Flows as a Dynamical System](https://docs.co.build/revnet/Revnet-Dynamical-System.pdf)
import { MintFlowDiagram } from "../../components/MintFlowDiagram";
import { CashOutTaxCurve } from "../../components/CashOutTaxCurve";
import { AutoIssuanceDiagram } from "../../components/AutoIssuanceDiagram";
## Issuance & Redemption Mechanics
This page documents the protocol mechanics for token distribution and redemption parameters.
### Split %
Each time someone pays into the curve, the protocol mints new tokens and splits them:
* A fraction routes to a predefined list of recipients (team, partners, other contracts).
* The remainder routes to the payer.
Properties:
* Splits **do not change the treasury**—they only affect *who* receives the new tokens.
* From the payer's perspective, a higher split is equivalent to a higher effective price.
* Splits do **not** affect whether the price floor rises from an issuance—that depends on whether the issuance price exceeds the current backing ratio.
#### Split Ranges
**Low split (5–20%)**
* Most new tokens route to payers → broad distribution.
* Common in Launchpad-style or community-first configurations.
**Moderate split (40–50%)**
* Payers and existing stakeholders both receive significant shares on each payment.
* Typical for periodic funding configurations where each round both funds the treasury and allocates to incumbents.
**High split (95–98%)**
* Nearly all new tokens route to the operator.
* Payers receive small cashback-style amounts; suitable for loyalty programs and commerce.
Design considerations:
* Splits fund **ongoing work** (salaries, development, operations).
* Predictable splits ("team receives 30% of all new tokens, forever") are easier to model.
### Auto-issuance
Auto-issuance (automint) schedules one-off token mints at stage start. These mints:
* Increase **supply** without adding to the **treasury**.
* Therefore **always reduce the price floor**, because `floor ≈ treasury ÷ supply` and only the denominator changes.
#### Use Cases
**Common reasons:**
* Compensate pre-launch contributors who took early risk.
* Allocate to strategic partners or infrastructure providers.
**Design considerations:**
* Keep auto-issuance **minimal** relative to expected future supply.
* Earlier issuance (before significant participation) reduces floor impact on existing holders.
* In multi-stage configurations, scheduling auto-issuance **after** periods of activity gives the floor headroom to absorb dilution.
Framing: **splits for ongoing work; auto-issuance for prior contributions**.
### Cash-out Tax
When someone redeems tokens, the curve calculates a payout based on `treasury ÷ supply`, then applies a **cash-out tax**. A fraction stays in the treasury; the rest goes to the redeemer.
Key property: **Every redemption raises the price floor** as long as the tax is > 0. Treasury decreases, but supply decreases *faster*, because some of the payout remains inside.
Higher tax = stronger floor lift per redemption, but higher cost to redeem.
#### Low (0–8%)
* Redemptions are inexpensive; tokens function more like a currency.
* Suitable for **Stable Commerce** configurations where participants need to move in and out freely.
* The floor still increases over time through activity, but more gradually.
#### Medium (8–20%)
* Each redemption meaningfully benefits remaining holders.
* Loans remain viable for many configurations.
* Suitable for **Periodic Fundraising** systems—participants can remain between rounds but retain the ability to leave.
#### High (20–40%+)
* Redemptions become costly; the mechanism favors longer-term holding.
* In Launchpad simulations, tax ≥20% improved capital preservation and floor growth.
* Above \~40%, an interesting property emerges: for large holders, **loans can provide more immediate liquidity than redemption**. The system remains solvent (defaults actually strengthen the floor), but loans become an alternative liquidity path.
### Tax and Loan Interactions
Loans are not configured directly, but their properties depend on tax and ceiling parameters:
* **Higher tax** accelerates floor growth for remaining holders, but raises the appreciation threshold needed for loans to be preferable over redemption.
* **Growing ceiling** gives holders reason to borrow instead of redeem, as future price increases may outpace the loan's cost.
## Flows \[Recursive streaming grants]
import { TCRDemo } from "../../components/TCRDemo";
import { FlowsDemo } from "../../components/FlowsDemo";
Flows is our "always‑on" grants system: instead of one‑off payouts, it turns a budget into a stream of money for people doing continuous grassroots work.
### How it works
Each flow is a curated list of builders plus a monthly budget.
Tokens stream out every second to builders on the list—no waiting for milestone reviews or batch payouts.
### Eligibility
Builders apply with a short pitch and a small application fee.
Once accepted, they start receiving a continuous stipend and are expected to post clear, public progress updates (usually on Farcaster) instead of filling out heavy grant reports.
We use a **Token Curated Registry (TCR)** to maintain who's in each flow.
Anyone can challenge a builder's eligibility by staking tokens; if the challenge succeeds (decided by token-holder vote), the builder is removed and the challenger earns a portion of the builder's stake.
If it fails, the challenger loses their stake to the builder.
Applying or challenging requires buying the community's token.
When the flow funds impactful work, the token attracts more buyers and holders earn more, so everyone has skin in the game to curate well.
Bad actors get slashed out quickly, legitimate builders are protected by the cost of frivolous challenges, and the registry self-corrects without needing a central gatekeeper.
### Baseline vs Bonus
Sponsors put capital into a flow; that capital is split into two parts: a **baseline** pool that gives every accepted builder an equal share, and a **bonus** pool tilted toward builders that are having outsized impact.
The baseline keeps things fair and predictable; the bonus lets the crowd express strong preferences without a central committee.
Over time, good work gets more stream, stalled work loses it, and the money keeps moving toward people actually shipping.
### Deciding Bonus Allocations
Instead of token voting deciding the bonus pool allocation, we use LLM-driven pairwise duels to weight grants against each other.
In addition, anyone that likes or comments on a builder's update micro-buys the community's token and sends it to the builder. This creates a direct link between visible contribution and compensation.
These micro-transactions are quadratically weighted when calculating bonus allocations—many small endorsements from different people count more than a few large ones. This rewards builders who earn broad community recognition over those who simply have a few wealthy supporters.
Bonus allocations update weekly based on these two signals.
### Prior Success
We ran Flows [already](https://www.nouns.camp/proposals/697) with Nouns DAO, paying over 250 builders from a $200k pot across 6 months.
94% made real impact; only 6% rugged, and because funds streamed rather than paid in lump sums, losses stayed minimal.
Builders also loved getting a small stipend up front they could immediately put to work: booking a venue, buying supplies, or kicking off production.
## Capital Allocation \[Scaling global coordination]
Until very recently, humanity was limited in the size and scope of the organizations we could build.
With new coordination technology (the internet, AI, and programmable money) we believe it's now possible to accurately fund hundreds of thousands of people working toward a common goal, all with no slow-moving hierarchy.
Our core bet: if we build a capital allocation machine for grassroots work that functions as well as markets do for private goods, fundraising becomes relatively easy. The real gap isn't funding, it's the feedback loops that markets provide for things you buy, but almost never exist for things we share.
### Markets as compression
Markets turn millions of tiny, local judgments into a single global signal: price. No central planner needed. The loop of "produce → spend → consume" continuously pushes capital toward what actually works.
Markets work because they combine skin in the game with rich, bottom-up signaling. We're importing that same feedback (real money, real preferences, real downside for being wrong) into domains without a clean buyer-seller relationship.
### The funding desert
Most people doing interesting work outside clearly profitable enterprises (open‑source devs, movement builders, indie researchers, local organizers, artists) have no "customer pays X for Y" moment that tells the world what their work is worth. Instead: likes and retweets, opaque grant committees, one‑off donors chasing narratives. None with tight feedback loops.
> The underlying goal is to create a societal gadget that can fund public goods with a level of accuracy, fairness and open entry that at least approximates the way that markets fund private goods.
> [Vitalik Buterin](https://vitalik.eth.limo/general/2025/01/05/dacc2.html)
We're building market-like structures so that funding public, cultural, collective things can feel as sharp, honest, and efficient as capital allocation in the best private markets.
## Reaction Markets \[Engagement as allocation]
import { ReactionMarketDemo } from "../../components/ReactionMarketDemo";
Reaction markets on Cobuild turn every like, comment, and follow into a micro-purchase.
You configure a budget, set amounts per reaction type, and from then on your normal social behavior automatically allocates capital to the creators you engage with.
### How it works
You set rules for each reaction type: maybe $0.10 per like, $0.20 per comment, $0.40 per follow.
When you engage with a creator, we batch those micro-buys and swap your money for their token.
The creator gets direct financial signal that their work is valued; you get a portfolio that perfectly reflects your genuine interests.
### Why it matters
Traditional capital allocation suffers from a fundamental disconnect: the people deciding where money goes are rarely the same people consuming and valuing the work.
Grant committees, VCs, and institutional investors are one or two steps removed from the grassroots signal of what's actually resonating.
Social engagement is the purest form of bottom-up signal we have.
When you like something, you're expressing genuine attention and approval: a micro-judgment that this creator is producing value worth your time.
But historically, that signal has been worthless for capital allocation.
It gets aggregated into vanity metrics that mean nothing to the creator's bank account.
Reaction markets close the loop.
Your attention becomes capital.
Instead of likes being empty gestures and investments being detached decisions, they merge into a single action.
The result is a capital allocation system that routes money exactly where organic human interest already flows.
No committees, no applications, no gatekeepers.
This is what market-like allocation looks like for social goods: millions of tiny, honest judgments aggregating into real capital flows.
**No central allocator could ever match the information density of organic engagement at scale.**
import { RoundsDemo } from "../../components/RoundsDemo";
## Rounds \[In-feed quadratic funding]
Rounds are open-competitions for small scale work that anyone on the internet can participate in by making a post on social media.
### How it works
Come up with an idea for what you want to fund, people post proof of work on social media, Cobuild automatically decides the best work weighted by market signals and LLM judged qualitative rankings.
1. Write requirements and set a budget, eg: post an idea for how to improve @Cobuild
2. Incoming posts + authors are filtered against requirements \[1]
3. An LLM compares pairs of posts, and builds an ELO like ranking
4. Anyone that likes or comments on the post micro-buys the communities coin and sends to the builder
5. The budget is allocated based on quadratically weighted micro-buys and the AI-driven qualitative duels
Likes and retweets are no longer a fuzzy approximation for value.
With Cobuild, your social media engagement is the fuel that funds these new-era organizations and helps them allocate capital intelligently.
#### Notes
\[1] We have some solid anti-sybil protections in place. At scale - we acknowledge the need for more robust systems where
builders will have to put money on the line to assert they are legitimate.
## Cobuild Capital Allocation \[Our stack for effective grants]
Since 2021, we've been building systems to help communities fund what matters to them.
Our two flagship systems, [Flows](/allocation/flows) and [Rounds](/allocation/rounds), were engineered to provide accurate, efficient, and fair grants to people making grassroots impact for their communities.
### Diverse strategies
There's no one-size-fits-all solution for funding impactful work.
Different allocation strategies are necessary to fund the wide range of efforts that help these organizations scale and sustain.
Rounds funds micro-bounties for one-off tasks.
Flows funds longer term small stipends for continuous work.
We've designed these systems to enable supporters to fund work directly, so builders on the ground can raise funds for themselves and their communities effortlessly while integrating valuable market signals into our allocation systems.
[Reaction markets](/allocation/reaction-markets) are our first primitive.
They turn social engagement into micro-purchases that generate the bottom-up signal Flows and Rounds need to allocate accurately.