> ## Documentation Index
> Fetch the complete documentation index at: https://docs.opengdp.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Adaptive Multi-Proposers

Adaptive Multiple Concurrent Proposers (AMCP) allow multiple validators to contribute transactions to a single block, enabling sub-second inclusion latency and higher aggregate throughput.

## Identification

Adaptive Multiple Concurrent Proposers (AMCP) transactions are identified through a nonce-key prefix system:

* The most-significant byte of the 2D nonce key is set to `0x5b`.
* The next 15 bytes encode a partial validator public key that binds the transaction to a specific proposer.

This allows the protocol to verify which validator proposed each transaction without additional metadata.

## Validation Rules

| Rule              | Description                                                                                                                           |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| One per validator | Each validator may contribute at most one sub-block per block.                                                                        |
| Signature check   | The sub-block hash (with `0x78` magic-byte domain separator) must be validly signed by a member of the current epoch participant set. |
| Gas bound         | Each sub-block is limited to a pro-rata share of the shared lane gas.                                                                 |
| Size bound        | Total serialized transaction size is bounded relative to the block size cap.                                                          |
| Parent anchoring  | The `parent_hash` must match the current chain tip.                                                                                   |

## Use Case: Low-Latency Point of Sale

A point-of-sale terminal submits a payment transaction. Instead of waiting for the next full block, a validator includes it in its sub-block and signs it. The merchant receives a cryptographic proof of inclusion within milliseconds, backed by the validator's stake.