Adoption and identity

A launch is not an endorsement

Anyone may propose a coin around a public idea or another person’s work, subject to launch review. Until the intended creator verifies and accepts it, the project remains unadopted and unendorsed. A source URL or matching display name does not establish control.

The adoption sequence

• The candidate wallet requests adoption and submits the exact proposed charter or terms.
• The verifier checks evidence for the candidate, project, current adoption nonce, and hash of those terms.
• The governor approves that same candidate and terms.
• A two-day notice period allows a public challenge.
• Once the period has elapsed and the adoption is not challenged, finalization records the developer.

Why identity proofs are specific

Identity evidence must bind the wallet to the exact project and terms. A prior proof for another project, a stale nonce, or an altered charter cannot be reused as approval. Repository ownership and social identity verification depend on the actual provider configuration and evidence.

The first EVANGEL project reserves adoption for its configured founding developer. Other projects follow their candidate-verification flow. Adoption does not itself release tokens.

Write a useful charter

Describe what the project is for, what the creator intends to deliver, how fees support it, how contributors can participate, and how progress will be demonstrated. Keep roadmap claims specific enough for a reviewer to assess.

For example: “Publish an indexed API reference and reproducible examples for the current release; acceptance requires a merged documentation change and working example commands.” This is more reviewable than “grow the ecosystem.”

Changing plans

Roadmap and fee changes go through proposals. A new plan does not remove supply limits, the developer ceiling, protected bounty allocation, or rolling release restrictions. Public terms help participants understand a proposal; they are not a guarantee of delivery.