> For the complete documentation index, see [llms.txt](https://doc.cryptostone.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://doc.cryptostone.org/gem-attributes/30_attribute_generation_and_randomness_verification.md).

# 30 Attribute Generation and Randomness

Gemstone attributes are not manually entered by the operator. At the time of mining, the mining contract determines Weight, Color, Clarity, and Cut based on a random value.

The important point is that the randomness generation method must be verifiable. If an operator could arbitrarily generate high-grade NFTs, the decentralization and scarcity of CryptoStone would be damaged.

CryptoStone reduces dependence on any single randomness element by combining user-provided entropy, recent multi-block entropy, Ethereum `prevrandao`, claim state, and contract-specific values.

The structure can be expressed as follows.

$$
S = H(userEntropy, user, positionId, claimNonce, prevrandao, chainId, contract)
$$

$$
B\_i = blockhash(blockNumber - 1 - (H(S,i) \bmod 30)) \quad \text{for } i \in {0..4}
$$

$$
R = H(userEntropy, B\_0, B\_1, B\_2, B\_3, B\_4, prevrandao, claimState, contractState)
$$

This model does not depend on a single block value or a single user value. It mixes user entropy, multiple recent block references, Ethereum consensus entropy, and claim-specific state to reduce predictable or operator-dependent outcomes.

CryptoStone's randomness generation method follows these principles.

| Principle                   | Description                                                                                               |
| --------------------------- | --------------------------------------------------------------------------------------------------------- |
| Unpredictability            | Neither operator nor user should know the result in advance                                               |
| No result selection         | The operator must not be able to select favorable results or reject unfavorable results                   |
| Prevention of retry         | After a randomness request, users must not be able to cancel or retry before the result is finalized      |
| No Admin Reroll             | The operator must not be able to reroll or replace a specific result                                      |
| Public verification         | The result generation process must be on-chain or publicly verifiable                                     |
| Fixed probability table     | Attribute probability tables must be disclosed before deployment and cannot be changed after finalization |
| Immutability after issuance | Attributes must not be changeable after issuance                                                          |

After a random result is requested, the user must not be able to cancel or retry the claim because the result is unfavorable. The operator must also not be able to allocate favorable results to specific users or choose a seed that produces specific attribute combinations. This is a core condition to ensure that rare gemstones are generated by a verifiable randomness structure rather than operator discretion.

After issuance, the core attributes of a Gem NFT must be frozen. Core metadata such as Weight, Color, Clarity, Cut, stoneType, minedAt, and minedFromPool must not be changeable by the operator.


---

# 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://doc.cryptostone.org/gem-attributes/30_attribute_generation_and_randomness_verification.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.