> For the complete documentation index, see [llms.txt](https://docs.canhav.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.canhav.com/token-launch/journey-and-credibility.md).

# Journey and credibility

**Available now.**

A **journey** is the off-chain plan for a token: why it exists, the supply rationale, and dated milestones. It is the **commitment** a launcher can choose to make. At launch, CanHav records hashes on-chain so anyone can verify that a published document matches what was launched.

The description hash is always recorded. The commitment is optional: on the launch form it is the **Add a commitment** toggle, and a launch from a published token design commits that design instead. Without either, `journeyHash` is zero and the token page says "Launched without a commitment".

## Two commitments

| Hash              | Commits to                                                                                                                                                    |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `descriptionHash` | Short description from the launch form. The text is stored off-chain and shown only when it re-hashes to this value                                           |
| `journeyHash`     | The journey document stored off-chain, or a published token design's snapshot when the launch was made from a design. Zero when the launch made no commitment |

They are independent. Changing one document does not rewrite the other hash. Verification is: hash the published bytes and compare to the event.

## Why it matters

Launch pages often make claims that never appear on-chain. Binding a journey hash in the launch transaction means:

* The launch event is the source of truth for “what was promised at t0”
* Later [journey updates](/token-launch/journey-updates.md) can add content-addressed progress without rewriting the original commitment
* Explorers and indexers can surface the hashes even if hosting moves
* The milestones in the document are what [escrow](/token-launch/milestone-escrow.md), [allocation sales](/token-launch/allocation-sales.md) and progress updates are scheduled against. A token with no commitment cannot use them

## Format notes

Journey document format may evolve. Smoke-test launches have used placeholders. Treat the **hash in the event** as the contract with the chain; treat the hosted file as the human-readable payload that must match.

## Related

* [The launch form](/token-launch/launch-form.md)
* [Deploy paths](/token-launch/deploy-paths.md)
* [Journey updates](/token-launch/journey-updates.md)
* [Milestone escrow](/token-launch/milestone-escrow.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.canhav.com/token-launch/journey-and-credibility.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.