You can originate useful work without waiting for a bounty. A contribution concept is a short explanation of the problem, why it matters, and the first result worth testing.
Copy the concept template · Read a worked example · Use the agent skill
This is a preparation workflow, not a new approval body, submission service, or funding program.
Find a need worth solving
Choose a beneficiary and one difficulty or unanswered question. Begin with experience, an existing issue, a documented limitation, or a decision that needs evidence. Separate an observed problem from a hypothesis about demand.
Check the relevant repositories, proposals, public discussions, and field-specific work. Extending or reviewing an existing effort may be more useful than competing with it. Record source links, dates, relevant versions, and access gaps. Do not invent interviews, task availability, or agreed owners.
Explain why it belongs in 1Hive
Connect the work to one of the three lanes:
- Core infrastructure: what becomes easier to understand, use, contribute to, or govern?
- Communications and narrative: who can better understand the mission or act on real evidence?
- Tangible public goods: what knowledge or open resource can people beyond the project reuse?
Describe the relationship to Honey, contributor capacity, or the broader commons. One strong connection is enough. Do not force a token mechanism into a useful tool or substitute token demand for public benefit.
Define a first experiment
Name an inspectable output, a baseline or current alternative, a resource limit, and evidence that would justify continuing, revising, or stopping. A prototype, sourced note, test fixture, dataset, draft, or focused patch can be enough.
Start with resources you are willing and authorized to offer. If funding could help later, explain what it would buy beyond this baseline. Record costs and maintenance needs without implying a budget, reviewer, or owner has been approved.
Choose the next step
- Uncertain problem or design: research it or run a bounded local experiment.
- Clear, small, reversible improvement: prepare a patch through the normal contribution workflow. No separate proposal is required.
- Work spanning several contributions or a durable decision: use the working-draft improvement process.
- On-chain governance, covenant, or shared-asset changes: research deployed dependencies, authority, existing obligations, failure modes, and alternatives before formal protocol proposals. Local experiments do not authorize execution.
Ask for specific review
When an agent prepares the concept, return it privately first. When you choose to share, use the 1Hive website repository for contribution concepts and public reasoning, or the relevant project repository for technical work. Check existing issues and pull requests first, and follow the repository’s conventions. There is no automatic concept inbox or guaranteed review service here.
Ask an answerable question: does this capture the problem, is there existing work to extend, or would the experiment distinguish the approaches? Agents can help critique and reproduce work; unresolved or consequential questions need human judgment and relevant expertise.
Leave the next contributor something useful
Record the artifact, sources, checks, limitations, and what you learned. Include observed use or feedback only when it actually happened. A negative result is valuable when it rules out an approach and can be reproduced.
The knowledge-commons direction explores how those records could become shared, retrievable context. Until then, a well-maintained artifact in the right repository is already useful.