Security Model
Relix is designed with the assumption that something will eventually go wrong hardware fails, keys are lost, software has bugs, and attackers are patient. The security model is built around limiting the damage when that happens, rather than pretending it never will.
At a high level, security on Relix comes from three layers working together:
Consensus and economic security – how the chain resists attacks at the protocol level
Network and infrastructure security – how nodes are run, monitored, and protected
Application and user-level security – how contracts, dApps, and wallets behave on top of the base layer
Each layer assumes the others can fail in bounded ways and is designed to contain that failure.
1. Threat model and assumptions
Relix does not assume a perfectly honest world. Instead, the design assumes:
Some validators may be offline or misconfigured at any given time.
A minority of participants may act maliciously or try to cheat if they believe it is profitable.
Network connections can be unreliable, congested, or partially partitioned.
Software may contain unknown bugs that only appear under specific conditions.
Against that backdrop, the security goals are to:
Keep the chain live – honest users can continue to transact and include their transactions in blocks.
Keep the chain consistent – honest nodes agree on a single canonical history.
Make attacks expensive – breaking safety or liveness for any meaningful duration requires putting a significant amount of RLX at risk.
Relix is a Proof of Stake chain, so economic security (how much stake is required to cause damage, and what happens to that stake) is as important as cryptographic primitives.
2. Consensus and economic security
Relix uses a PoS-based consensus engine where RLX is the asset staked by validators. The core ideas are simple:
Validators lock RLX as stake to participate in block production.
The protocol selects validators to propose and attest to blocks based on their stake and other parameters.
Honest behavior is rewarded; provable misbehavior can be penalized.
Key aspects of the consensus security model:
Stake as collateral Attackers must control a significant portion of the staked RLX to meaningfully disrupt the chain. Acquiring and risking that stake is intended to be more expensive than any realistic benefit from attacking.
Punishment for provable faults Double-signing, equivocation, and other serious consensus violations can lead to slashing once the final rules are in place. This turns certain classes of attacks into guaranteed financial losses for the attacker.
Liveness under partial failure The protocol is designed to continue producing blocks as long as a sufficiently large subset of validators remains online and honest. Individual node failures should not halt the network.
The exact parameters minimum stake, slashing amounts, reward curves are defined in the staking and consensus specifications, but the principle is constant: the cheapest strategy for a validator should be to follow the protocol honestly over time.
3. Network and node security
Even with strong consensus rules, the chain only works if nodes can talk to each other and process blocks. The network layer assumes:
Some peers may behave maliciously (spam, malformed messages, selective relaying).
Operators may misconfigure nodes, expose services accidentally, or run outdated software.
To mitigate this, the model emphasizes:
Peer diversity Nodes connect to multiple peers and are not dependent on any single counterparty. Misbehaving peers can be dropped without affecting overall liveness.
Topology options for operators Validators are encouraged to use sentry node setups public-facing full nodes that shield the validator node from direct internet exposure. This reduces the risk of targeted attacks on the signing infrastructure.
Resource-aware behavior Node implementations are built to reject obviously malicious traffic, set sensible defaults for peer counts, and protect against simple denial-of-service vectors.
From an operator’s point of view, node security is a shared responsibility: the protocol defines safe behaviors, but firewall rules, OS hardening, monitoring, and patching practices are just as important in practice.
4. Smart contract and application layer
Relix is fully EVM-compatible. That means contracts deployed on Relix inherit both:
The strengths of EVM tooling and well-known patterns, and
The risks of typical Solidity and EVM mistakes.
The base chain does not protect users from:
Logic bugs in dApps or protocols
Poor access control in contracts
Economic exploits in DeFi systems built on top of Relix
Instead, the security model at this layer rests on:
Clear separation of responsibilities
Relix provides execution, ordering, and finality.
dApps are responsible for their own logic, invariants, and upgrade paths.
Guidelines and best practices
The “Smart Contract Guidelines” section lays out expectations around access control, testing, pausing, and dependency management.
Teams are encouraged to use audits, formal analysis, and Relix Testnet as part of their release pipeline.
Transparency through the explorer
Users and integrators can inspect contracts, transactions, and events via
https://testnet.relixchain.com.Verified source and published ABIs help reduce the risk of interacting with unknown or malicious code.
In short: Relix guarantees that the chain executes what contracts say, but it cannot decide whether what they say is safe.
5. Key management and trust boundaries
Almost every security issue eventually comes back to key management:
Validator signing keys
Operator keys for staking and governance
Multisig keys for protocol-owned treasuries
User wallet keys
The model assumes:
Keys used to sign blocks or move high-value assets are stored and used in restricted environments (servers with hardened access, HSMs, or well-secured multisigs).
Operational access to validator and treasury infrastructure is limited to a small set of trusted operators with clear procedures.
Best-practice expectations include:
Separating everyday user wallets from high-privilege keys.
Using multisig or other shared-control mechanisms for protocol governance and large treasuries.
Applying defense-in-depth: SSH hardening, firewalls, VPNs, role separation, and audited processes for key rotation and incident response.
Relix as a protocol cannot enforce these practices, but the long-term stability of the ecosystem depends on teams adopting them.
6. Defense in depth
The security model is built on the idea that no single control is perfect. Instead, multiple layers should catch or limit problems:
At the protocol level Slashing and staking rules make large-scale consensus attacks expensive and visible.
At the node level Good monitoring, alerting, and upgrade practices reduce the window where bugs or misconfigurations can cause issues.
At the contract level Audits, rigorous testing, pausable mechanisms, and clear governance reduce the blast radius if something goes wrong.
At the user level Verified contract code, explorer transparency, and cautious wallet usage reduce the impact of phishing or malicious contracts.
If one layer fails a vulnerable contract, an outdated node, a compromised key the goal is that:
The damage is limited in scope and time.
The problem is observable via logs, metrics, and on-chain data.
There is a clear path to remediation: pausing a protocol, rotating keys, upgrading nodes, or slashing bad actors.
7. Testnet vs mainnet realities
On Relix Testnet (chain ID 4127):
Security assumptions are intentionally more flexible.
Testnet RLX has no monetary value, and the network may be restarted or upgraded more aggressively.
The primary purpose is to discover issues early in consensus, node implementations, contracts, and tooling without putting real capital at risk.
On mainnet, the bar is higher:
Protocol changes are rare and carefully coordinated.
Validator and infrastructure operators are expected to treat their environments as production systems.
Contracts that handle RLX or major ecosystem assets should go through proper review and staged deployment.
The security model is designed so that lessons from testnet directly inform mainnet operations: the same architecture, but with stricter operational discipline and higher stakes.
8. Shared responsibility
Finally, Relix’s security model is explicitly shared:
Core protocol and node developers are responsible for the correctness and robustness of the base software and its upgrades.
Validators and node operators are responsible for running that software safely, monitoring it, and reacting to issues.
dApp teams and protocol builders are responsible for the safety of their contracts and economic designs.
Users and integrators are responsible for key hygiene, understanding the risks of the products they use, and verifying on-chain activity.
Relix provides the foundation: consensus, execution, and transparent data. The strength of the overall system comes from how seriously each participant takes their piece of that security story.
Last updated