> For the complete documentation index, see [llms.txt](https://raretyperesearch.gitbook.io/stockmon/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://raretyperesearch.gitbook.io/stockmon/mon/vault-and-feed.md).

# The Vault and 48-hour Feed

The Stockmon Vault is the accounting and custody boundary that turns authenticated WETH revenue into sealed, token-ID-level allocations.

![An engineered glass vessel dividing authenticated value into three sealed mineral allocations](https://164480815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0r3IgolbVPO14VcUCkOG%2Fuploads%2FwKQlwxGvdzG2DjvJhp7e%2Fstockmon-vault-editorial-v1.webp?alt=media)

## One launch-anchored clock

Feed rounds are anchored to the `$MON` launch time and occur every 48 hours:

```
round opens → revenue arrives → cutoff → living snapshot → DNA allocation → settlement
```

A delayed settlement does not move later cutoffs. Due rounds remain ordered and can catch up deterministically.

![The launch-anchored Feed clock and allocation ledger from received WETH through verified token-level settlement or preserved pending amounts](https://164480815-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F0r3IgolbVPO14VcUCkOG%2Fuploads%2Fpz71GykpH9BpOGiFvmJS%2Fvault-feed-v2.svg?alt=media)

## The allocation order

For each completed round:

1. The Vault identifies distributable WETH revenue received for that round.
2. Exactly 50% is assigned to the stock-purchase budget, with base-unit carry conserved.
3. The other 50% is tracked separately as the project-treasury share.
4. The stock-purchase budget is divided equally across every living Genesis ID.
5. Each ID’s permanent DNA divides its equal share among its lineages.
6. Purchases are aggregated by ticker for execution efficiency.
7. Only verified output balance changes become settled token-ID entitlement.

## Why available Stockmons count

Both available-unminted and owned-non-burned IDs are living. This keeps mint timing from changing the equal value assigned to a Genesis ID.

Minting changes ownership status; it does not create or erase that ID’s prior sealed accounting.

## Pending is not lost

If a ticker route is unavailable, unsafe, paused, or fails its bound, assigned WETH remains pending for the same IDs and ticker. Dust and carry cannot be redirected to the project treasury.

## What stays sealed

While a Genesis NFT is living:

* settled Stock Tokens remain in pooled contract custody;
* liabilities remain recorded by token ID;
* the owner cannot withdraw individual stock positions; and
* an NFT transfer carries the entire living basket with the token.

This prevents a seller from stripping displayed entitlement immediately before a marketplace transfer.

## What the Vault does not promise

Vault accounting does not remove:

* Stock Token price movement;
* route or liquidity unavailability;
* smart-contract defects;
* issuer freezes or transfer restrictions;
* network congestion or gas costs; or
* delayed settlement.

{% hint style="warning" %}
Displayed USD values are estimates unless the interface identifies a verified price source and observation time. Contract atoms and confirmed ownership remain the authoritative accounting inputs.
{% endhint %}

Next: follow [one complete Feed example](/stockmon/mon/vault-and-feed/a-complete-feed-example.md), then read [The NFT lifecycle](/stockmon/nft-lifecycle.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 dynamically by asking a question.

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

```
GET https://raretyperesearch.gitbook.io/stockmon/mon/vault-and-feed.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 `build a script that syncs our docs to a CMS` 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.