Skip to content
Published Case Study

Temtum Protocol Security Assurance

A real-world Layer-1 security assessment of the Temtum Temporal Blockchain. We tested the three claims that matter most: speed, security, and cryptography. The work combined code review, digital-twin simulation, and adversarial testnet experiments.

Engagement Summary

PUBLICLY_REPORTED
ProtocolTemtum Temporal Blockchain
FocusSpeed, security, and cryptography
StatusCompleted assurance engagement
Claimed peak TPS
120,000+
Sustained under adversarial load
8,000–14,000
Validator set tested
64–128
Latency (ideal)
< 1 s
Latency (cross-continent, 2% loss)
4–8 s
Attack scenarios modelled
14

Speed

Temtum's architecture is built around a block-lattice combined with a single leader per round. The leader can produce a block immediately after being elected, which removes the need for multi-round consensus under normal operation. In theory, this allows very high throughput when the network is well-connected and the leader is honest.

We reproduced the claimed peak throughput in a controlled data-centre environment with 64 validators, sub-millisecond links, and no adversarial nodes. The headline number is real under those conditions. The problem is that those conditions are not the public internet.

When we introduced cross-continent latency, 2% packet loss, and a modest number of slow or Byzantine validators, sustained throughput dropped by an order of magnitude. The bottleneck moved from consensus to state re-propagation: the block-lattice structure requires each validator to track and validate many account chains, and the leader's block becomes a large serialisation point. The protocol is fast, but the throughput claim needs to be qualified by network assumptions.

Security

The security model rests on the NIST public randomness beacon, honest-majority of validators, and the assumption that the elected leader cannot be eclipsed before it proposes. We focused on the second and third assumptions because they are the most actionable.

In our digital twin, we showed that an adversary who knows the upcoming leader can flood the leader's peer slots with attacker-controlled nodes. Once the leader is eclipsed, it proposes a block that never reaches the honest network. The protocol recovers through timeout and re-election, but the recovery window is measurable and exploitable for censorship or short forks.

We also tested partition tolerance. Because the protocol depends on a single leader per round, any network partition that isolates the leader from a quorum creates a visible liveness stall. The recovery mechanism works, but it does not provide the same graceful degradation as a BFT protocol with multiple concurrent proposers.

Cryptography

Temtum's cryptography is ambitious. It uses a post-quantum signature scheme for long-term security, and it anchors leader election to the NIST randomness beacon. The temporal proof mechanism binds transactions to a time window, which gives the protocol a natural ordering primitive.

The quantum-resistant signatures are correctly implemented at the primitive level, but they carry a real cost: signatures and public keys are an order of magnitude larger than ECDSA. This inflates block size, transaction propagation time, and the storage requirements for full nodes. The throughput benchmarks we reviewed used smaller legacy signatures in some configurations, which under-reports the real-world cost.

The temporal proof is a valuable idea, but its security depends on clock synchrony. We demonstrated that validators with only modest clock skew can disagree on whether a temporal proof is valid, creating small forks that are eventually resolved by leader election. This is not a fatal flaw, but it is a hidden assumption that must be documented and enforced.

Findings

F-01HIGHCryptography

NIST beacon dependency creates liveness risk

Leader selection relies on the NIST public randomness beacon. If the beacon is unavailable, delayed, or its output is censored, the network cannot elect a leader and block production stalls. This is a single external point of failure for liveness, not for safety, but it contradicts the protocol's claim of high availability.

Recommendation: Add a fallback randomness source with a documented failover policy, and measure recovery time under beacon outage.
F-02MEDIUMSecurity

Leader predictability window enables eclipse planning

Because the leader for a given round is computable once the beacon output is known, an adversary has a short but non-zero window to mount an eclipse attack against the next leader. We demonstrated in the digital twin that isolating the leader before it proposes can partition the network.

Recommendation: Increase outbound diversity requirements for validators and add feeler connections to detect eclipse attempts before the leader round begins.
F-03MEDIUMSpeed

Peak TPS is achievable only under idealized conditions

The reported throughput assumes a small validator set, low-latency links, no Byzantine faults, and abundant bandwidth. Under more realistic geographic distribution and packet loss, throughput drops by an order of magnitude. The bottleneck is not consensus logic but serialization and re-propagation of the block-lattice state.

Recommendation: Publish benchmark methodology and run adversarial load tests with simulated latency, packet loss, and malicious nodes.
F-04LOWCryptography

Quantum-resistant signature scheme increases payload size

The chosen post-quantum signature scheme adds significant size to every transaction and block. This is a correct trade-off for long-term security, but it was not fully reflected in the stated throughput numbers, which used smaller legacy signatures in some benchmark configurations.

Recommendation: Re-baseline all throughput claims using the actual quantum-resistant signature payload sizes.
F-05MEDIUMSecurity

Temporal proof ordering is sensitive to clock skew

Temporal ordering depends on a network of clocks. We showed that validators with modest clock skew could accept or reject different temporal proofs, leading to short forks that must be resolved by leader election. This is manageable but requires explicit clock synchrony assumptions.

Recommendation: Document clock-synchrony requirements and add stricter validation windows for temporal proofs.

Recommendations

  • Replace the single NIST beacon dependency with a hybrid randomness source that can survive a beacon outage.
  • Harden validator peer selection against eclipse attacks, especially in the round window before a leader is known.
  • Re-baseline all throughput and latency marketing with adversarial network conditions and real signature payloads.
  • Document clock-synchrony assumptions and tighten temporal-proof validation windows.
  • Add continuous adversarial testnet runs that exercise leader eclipse, partition, and Sybil scenarios before every release.