The repository index
345 researched crypto repositories, source-specific fork proposals and community priorities.
What was researched
The launch catalogue contains 345 canonical GitHub repositories across 28 crypto categories. All entries have observed repository metadata; 100 include README inspections and all 345 have recorded commit revisions in the initial research snapshot. The entry shows its actual review depth. This is a broad discovery index, not a line-by-line audit of hundreds of codebases.
Each candidate has an independent working name and ticker, a unique concept favicon, a scoped fork brief, a port strategy, acceptance criteria and blockers. EVM contracts, non-EVM ports and off-chain adapters are distinguished. Research evidence links back to GitHub.
Vote for a source
When account services and persistent storage are connected, each catalogue repository can receive one saved vote per signed-in account. You can remove your vote. Repeated requests to save the same choice do not add votes. Account identity is not displayed. Account voting does not prove unique humans and is not Sybil-resistant governance.
Votes prioritize proposals. They do not spend a wallet balance, launch a token, guarantee implementation or authorize release. A separate request records the agreed scope and reserves settled build credit.
A catalogue entry is not permission to build
Archived, unresolved-license and restricted sources remain clearly marked for research. Public visibility does not establish reuse rights. The permissive filter selects non-archived entries with a detected permissive license; dependency, asset and security review is still required.
Copyleft, change-date and custom license cases require exact-revision review. Working names and symbols are independent proposals. Source logos identify the original project; they do not establish endorsement, a cleared launch identity or an affiliation with Robinhood.
Prepared briefs
Open any repository card to inspect its migration scope and acceptance criteria. Download the brief as Markdown, then use Request build to prefill the source and specification. Intake performs a fresh source and revision check before a saved request can progress.