> For the complete documentation index, see [llms.txt](https://lashae.gitbook.io/lashae-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://lashae.gitbook.io/lashae-docs/the-protocol/sealed-vows.md).

# sealed vows

A sealed vow is a promise made **before** the outcome is known — hashed, anchored, and hidden until the walker chooses to reveal it.

It is the field's answer to the question:

> *how do you prove you meant it, and not merely rewrote your intentions afterward?*

## the shape of a vow

| field                        | meaning                                                                |
| ---------------------------- | ---------------------------------------------------------------------- |
| **plaintext**                | what the walker swore. hidden from the public until reveal.            |
| **salt**                     | 128 bits of local randomness mixed into the commitment.                |
| **deadline**                 | when the walker intends to have kept the vow.                          |
| **commitment hash**          | \`SHA-256(LASHAE\_VOW                                                  |
| **anchor signature**         | optional. proof the commitment existed on Solana at a specific moment. |
| **status**                   | `sealed`, `revealed_kept`, `revealed_broken`, or `expired`.            |
| **fulfilled\_footprint\_id** | optional. the footprint that discharged the vow.                       |

## the two acts

### 1. seal

The walker writes the promise privately, chooses a deadline, and lets the browser compute the commitment hash. Nothing on the chain yet says what the promise is — only that a commitment of exactly this shape existed at this exact second.

### 2. reveal

Any time after the sealing, the walker chooses to open the box. The server re-hashes the plaintext + salt + deadline and confirms the commitment matches. The status is written: **kept**, or **broken**. Both are honest.

## why a commitment, not a public post

Because posting an intention publicly rewards the posting, not the walking. Every productivity feed becomes a graveyard of aspirational tweets. A sealed vow removes the applause phase. The only witnesses are you, the field, and the chain — and only the chain remembers *before* you knew whether you would keep it.

## what verification proves

* the promise existed at time T₀ (the anchor timestamp).
* the plaintext revealed later hashes to the same commitment.
* the walker had no way to invent a more convenient promise after the deadline.

What verification does not prove: that the walker *kept the spirit* of the promise. That is between the walker and the field.

## verifying without LASHAE

```bash
# fetch the memo from the transaction signature
solana confirm -v <SIGNATURE> --url devnet

# recompute the commitment locally
printf 'LASHAE_VOW\x1f%s\x1f%s\x1f%s' "$SALT" "$PLAINTEXT" "$DEADLINE_ISO" | shasum -a 256
```

If they match, the vow was real. That is all a vow ever needed to be.

## the poetics

The field prefers vows that are small enough to keep and quiet enough to not perform. **the smallest vow honestly kept is louder than the largest vow loudly announced.**


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://lashae.gitbook.io/lashae-docs/the-protocol/sealed-vows.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.