# 3.4. Multi-protocol commitments

There could be two different protocols willing to put different commitments into a single transaction output; and only one of the protocols may succeed since a transaction can contain only a single commitment. It is also possible that some protocol may require committing to a number of messages within a single transaction and public key with the requirement that some dedicated information from these messages (like the message type) should be unique across the whole message set. For instance, this is required for the state updates, where such updates separated into different blocks (messages) and should be kept private, such that a single party will know the information about a single update and should not see any information about the rest. However, in this case, there should be a proof that the other state updates do not affect the state of the analyzed one, thus excluding state collisions. In such a setup, each state may be assigned with a unique integer identifier (like cryptographic digest), and a special form of zero-knowledge proof should be utilized to prove the fact that all the states are different without exposing the actual state ids.

While both cases are impossible at the level of deterministic bitcoin commitment standards, a dedicated procedure for structuring multiple independent messages was proposed, named “**multi-protocol commitments**”. With it, some properties of the committed messages may be proven in a zero-knowledge way, i.e. without revealing any information about the source messages or the properties themselves.

Multiple commitments under different protocols are identified with a unique per-protocol 256-bit identifiers (like tagged hashes of a protocol name and/or characteristic parameters) and serialized into 256-bit slots within `N * 32` byte buffer such as `N >> M`, where `M` is the number of the individual commitments. The rest of the slots is filled with random data deterministically generated from a single entropy source. The position `n` for a commitment with the identifier `id`  is computed as `n = id mod N`, guaranteeing that no two commitments under the same protocol with a given `id` may be simultaneously present.

<figure><img src="/files/pjzNpLvmnc6QXQSjgB5L" alt=""><figcaption></figcaption></figure>


---

# Agent Instructions: 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:

```
GET https://black-paper.rgb.tech/consensus-layer/3.-client-side-validation/3.4.-multi-protocol-commitments.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
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.