Skip to main content
As a metaprotocol, Kontor inherits Bitcoin’s constraints: 4,000,000 weight units per block and a ten-minute block time. A naive implementation would be limited to roughly the same throughput as Bitcoin itself—about 10 transactions per second. Kontor reaches 1,000+ operations per second by bundling many operations into single Bitcoin transactions and minimizing per-operation payload overhead. Depending on batch size, this reduces weight per operation by 35–120×.

​
Transaction Bundling

The most significant optimization is trustless BLS signature aggregation. Vanilla Bitcoin signatures require one 64-byte Schnorr signature per input, and these cannot be aggregated across different keys. BLS signatures can be aggregated: N signatures from N different signers compress into a single 48-byte aggregate signature. Bundling packs multiple signed operations into a single Bitcoin transaction, amortizing the fixed transaction overhead (inputs, outputs, witness structure) across the batch. Kontor users can choose to use their regular Bitcoin addresses, or they can use Kontor BLS addresses for lower fees and greater scalability.
  1. Users sign operations. Each user signs their Kontor operation using a BLS key derived from their seed phrase. The signature commits to the operation details: target contract, function, arguments.
  2. Bundlers collect operations. Bundlers are infrastructure providers who collect signed operations from users. Any party can run a bundler—there is no permissioning or staking requirement.
  3. Bundlers aggregate and publish. The bundler combines all signatures into a single BLS aggregate signature, constructs a Bitcoin transaction containing all operations, and broadcasts it to the Bitcoin network.
  4. Indexers verify and execute. When the transaction confirms, indexers verify the aggregate signature against all (public key, message) pairs and execute each operation with its designated signer as caller.
Users do not need to trust bundlers. The BLS signature scheme has a key property: given signed operations, anyone can produce a valid aggregate.

​
Payload-size optimizations

Kontor reduces per-operation payload size via:

​
Compact Registry IDs

Kontor maintains a deterministic registry that maps long identifiers (public keys, contract addresses, etc.) to compact 4-byte numeric IDs. When a new identifier first appears (a new public key signs an operation, or a new contract is deployed), the indexer assigns it the next sequential ID. This is deterministic—all indexers processing the same blocks assign the same IDs. Space savings: 4 bytes instead of 32+ bytes per identifier—an 8–16× reduction in identifier overhead.

​
Binary Encoding

Operations are encoded in a compact binary format to remove syntactic overhead and improve compressibility: 
BinaryCall:
  signer_id:      4 bytes (registry ID)
  contract_id:    4 bytes (registry ID)
  function_index: 2 bytes (index into contract exports)
  args:           variable (compact serialization)
Combined with registry IDs, this produces compact payloads that compress well.

​
Zstd Compression

The final layer is Zstd compression. After operations are serialized in binary format with registry IDs, compression exploits redundancy across the batch: repeated contract IDs, common function indices, and similar argument patterns.

​
Benchmarks

The following table shows how each optimization contributes to throughput at batch size N=100:
ConfigurationWU/opTPSImprovement
Vanilla Bitcoin P2TR61511baseline
Naive Kontor (N=1)770–82480.7×
+ BLS batching (N=100)33–38172–19916–19×
+ Registry IDs21–25264–30525–29×
+ Binary + Zstd15–18366–44335–42×
Throughput scales with batch size:
Batch SizeWU/opTPSImprovement
1696–69891×
1080–8279–818×
10015–18366–44335–42×
1,0007–10683–98665–93×
10,0005–8771–1,29573–123×

​
Fee model

​
Fee components

Users pay two types of fees: Bundling fee. Compensates the bundler for Bitcoin block space. This is the user’s share of the total Bitcoin transaction fee, amortized across all operations in the bundle. Ordering fee (optional). Paid to consensus stakers for optimistic ordering. This is independent of bundling.

​
Cost model

The bundler’s cost per operation is: 
cost = (BTC_fee / N) + operational_overhead
Where:
  • BTC_fee is the total Bitcoin transaction fee for the bundle
  • N is the number of operations in the bundle
  • operational_overhead covers bandwidth, computation, and infrastructure
As N increases, the per-operation share of the Bitcoin transaction fee decreases proportionally to (1/N). For example, a bundler processing 1,000 operations pays roughly the same total Bitcoin fee as a bundler processing 10 operations, but spreads it across 100× more users.

​
Fee Burn

A fraction of bundling fees can be burned. The remainder goes to the bundler: 
bundler_revenue = (1 - burn_rate) × bundling_fee
The burn creates deflationary pressure on KOR while ensuring bundlers remain profitable.

​
Market Structure

The bundling market is designed to be competitive: Permissionless entry. Anyone can run a bundler. There is no staking requirement, no approval process, no geographic restriction. User choice. Users can submit to any bundler, self-bundle, or submit to multiple bundlers simultaneously. There is no lock-in. Price transparency. Bundling fees are visible on-chain. Users can compare bundler prices and switch freely. These dynamics drive fees toward marginal cost. Bundlers compete on price, latency, and reliability. Over time, the market tends toward efficient pricing where bundlers earn normal returns on capital.
For the complete specification and detailed benchmark results, see Scalability Specification.