# Amadeus Protocol Parameters: Complete Configuration Guide for Node Operators

> Master Amadeus Protocol parameters for node operators. Learn to configure static limits runtime settings and decompression guards in this comprehensive guide. Optimize your node setup today.

- Repository: [Amadeus Protocol/node](https://github.com/amadeusprotocol/node)
- Tags: complete-guide
- Published: 2026-08-20

---

**The key protocol parameters for Amadeus Protocol are controlled through three core configuration layers: static limits in [`config.exs`](https://github.com/amadeusprotocol/node/blob/main/config.exs), environment-driven settings in [`runtime.exs`](https://github.com/amadeusprotocol/node/blob/main/runtime.exs), and hardcoded decompression guards in the protocol module itself.**

The Amadeus Protocol defines its operational boundaries through a set of carefully tuned constants and configurable limits. Understanding these parameters is essential for node operators who need to optimize performance, adjust security postures, or deploy custom network configurations. This guide examines each parameter, its default value, and where it resides in the [`amadeusprotocol/node`](https://github.com/amadeusprotocol/node) codebase.

## Core Static Parameters

The foundation of Amadeus Protocol parameters lives in [`ex/config/config.exs`](https://github.com/amadeusprotocol/node/blob/main/ex/config/config.exs). These values establish hard limits for data storage and consensus requirements.

### Entry and Transaction Size Limits

Two size constraints govern what the node will accept:

- **`:entry_size`** — Maximum payload entry size, set to **1,048,576 bytes (1 MiB)**
- **`:tx_size`** — Maximum individual transaction size, set to **786,432 bytes (~768 KiB)**

These limits prevent resource exhaustion from oversized data submissions. Both are defined at lines 14–15 of [`ex/config/config.exs`](https://github.com/amadeusprotocol/node/blob/main/ex/config/config.exs).

### Quorum Configuration

The **`:quorum`** parameter specifies how many signatures finalize a transaction. The default is **3**, with a testnet override available at lines 16–18 of [`ex/config/config.exs`](https://github.com/amadeusprotocol/node/blob/main/ex/config/config.exs). This directly impacts the protocol's Byzantine fault tolerance characteristics.

### Protocol Version

The **`:version`** parameter propagates from the Mix project definition in [`ex/mix.exs`](https://github.com/amadeusprotocol/node/blob/main/ex/mix.exs) (line 4). At runtime, this becomes a 3-byte binary encoding used in message headers.

```elixir

# Retrieving core protocol limits at runtime

entry_limit = Application.fetch_env!(:ama, :entry_size)
tx_limit    = Application.fetch_env!(:ama, :tx_size)
quorum      = Application.fetch_env!(:ama, :quorum)

# Protocol version as 3-byte binary for message headers

{v1, v2, v3} = Application.fetch_env!(:ama, :version_3b)

```

## Runtime-Configurable Parameters

The [`ex/config/runtime.exs`](https://github.com/amadeusprotocol/node/blob/main/ex/config/runtime.exs) file handles environment-driven configuration, allowing operators to override defaults without recompiling.

| Parameter | Default Value | Environment Variable | Purpose |
|-----------|---------------|----------------------|---------|
| `:snapshot_height` | `77736265` | `SNAPSHOT_HEIGHT` | Block height to start from snapshot vs. genesis |
| `:rpc_url` | `"https://mainnet-rpc.ama.one"` | `RPC_URL` | Chain data endpoint |
| `:max_peers` | `300` | `MAX_PEERS` | Connection pool limit |
| `:localnet_tx_delay_ms` | `0` | — | Artificial latency for testing |

These parameters are read at lines 18, 20, 42, and 56 of [`ex/config/runtime.exs`](https://github.com/amadeusprotocol/node/blob/main/ex/config/runtime.exs) respectively.

```bash

# Example: Override peer limit and RPC endpoint for custom deployment

export MAX_PEERS=500
export RPC_URL="https://custom-rpc.ama.one"
mix run --no-halt

```

## Network Security Parameters

The [`ex/lib/node/node_proto.ex`](https://github.com/amadeusprotocol/node/blob/main/ex/lib/node/node_proto.ex) module enforces strict decompression limits to prevent denial-of-service attacks through malicious compressed payloads.

- **`:max_decompressed_size`** — **64 MiB** hard ceiling for any decompressed message (line 63)
- **`:max_window_log`** — **26** (≈67 MiB ZSTD window) (line 64)
- **`:decompress_chunk_size`** — **64 KiB** streaming chunk size (line 65)

These three parameters work together in the `NodeProto.decompress_and_unpack/1` function to safely handle incoming compressed messages:

```elixir
def handle_message(compressed) do
  # Raises if declared size exceeds :max_decompressed_size

  case NodeProto.decompress_and_unpack(compressed) do
    %{op: op, payload: payload} -> process(op, payload)
    %{error: err} -> IO.puts("Message rejected: #{inspect(err)}")
  end
end

```

## Parameter Hierarchy and Precedence

Understanding how Amadeus Protocol parameters resolve is critical for debugging configuration issues:

1. **Hardcoded defaults** in [`node_proto.ex`](https://github.com/amadeusprotocol/node/blob/main/node_proto.ex) — These protect against resource attacks and cannot be overridden
2. **Static configuration** in [`config.exs`](https://github.com/amadeusprotocol/node/blob/main/config.exs) — Compiled into the release, requires recompilation to change
3. **Runtime configuration** in [`runtime.exs`](https://github.com/amadeusprotocol/node/blob/main/runtime.exs) — Environment-driven, evaluated on every startup

Operators should treat size limits (`entry_size`, `tx_size`, `max_decompressed_size`) as security boundaries rather than performance tuning knobs. The quorum parameter affects consensus safety and should only be modified with thorough network analysis.

## Summary

- **Amadeus Protocol parameters** are organized across three layers: [`ex/config/config.exs`](https://github.com/amadeusprotocol/node/blob/main/ex/config/config.exs) for static limits, [`ex/config/runtime.exs`](https://github.com/amadeusprotocol/node/blob/main/ex/config/runtime.exs) for environment overrides, and [`ex/lib/node/node_proto.ex`](https://github.com/amadeusprotocol/node/blob/main/ex/lib/node/node_proto.ex) for security hardening
- **Size constraints** (`entry_size`, `tx_size`, `max_decompressed_size`) prevent resource exhaustion attacks with defaults of 1 MiB, ~768 KiB, and 64 MiB respectively
- **Consensus quorum** defaults to 3 signatures and directly impacts Byzantine fault tolerance
- **Network parameters** (`max_peers`, `rpc_url`, `snapshot_height`) adapt to deployment environments via environment variables

## Frequently Asked Questions

### What is the maximum transaction size in Amadeus Protocol?

The **`:tx_size`** parameter limits individual transactions to **786,432 bytes** (~768 KiB) as defined in [`ex/config/config.exs`](https://github.com/amadeusprotocol/node/blob/main/ex/config/config.exs) at line 15. This cap prevents network spam from oversized transactions while accommodating typical payload requirements.

### How do I change the number of signatures required for transaction finality?

Modify the **`:quorum`** parameter, defaulting to **3** in [`ex/config/config.exs`](https://github.com/amadeusprotocol/node/blob/main/ex/config/config.exs) (lines 16–18). Note that this value must remain consistent across all participating nodes in a network; mixed quorum settings cause consensus failures.

### Where does Amadeus Protocol define its decompression security limits?

Hard ceilings for message decompression reside in [`ex/lib/node/node_proto.ex`](https://github.com/amadeusprotocol/node/blob/main/ex/lib/node/node_proto.ex) at lines 63–65. The **`:max_decompressed_size`** of 64 MiB provides the primary defense against ZIP bomb-style attacks, supplemented by ZSTD window and chunk size controls.

### Can I run a node without syncing from genesis?

Yes. Set the **`:snapshot_height`** parameter via the `SNAPSHOT_HEIGHT` environment variable or modify line 18 of [`ex/config/runtime.exs`](https://github.com/amadeusprotocol/node/blob/main/ex/config/runtime.exs). The default snapshot height of `77736265` instructs the node to bootstrap from a recent checkpoint rather than executing all historical blocks.