Sentry Nodes

This is a high level overview of Sentry Nodes, the roles they fulfill in our ecosystem, and their unique incentives.

note

Due to the sheer variety of specialized node-types in the world of blockchain technology (e.g. validators, various masternode types such as "guardians", etc.), it is important to explicitly state a few things that Sentry Nodes are not.

What Sentry Nodes Are Not#

A authoritative subset of nodes that other nodes or clients are forced to trust
A solution that resolves the tech stack down to Proof-of-Stake
Privacy providers
Block producers

The Roles of Sentry Nodes#

Beyond simply serving as incentivized full nodes, Sentry Nodes do fulfill a few roles unique to themselves.

Security Enhancement#

Sentry Nodes are Syscoin's solution to the challenge of providing a decentralized means of finality for Proof-of-Work (PoW) without resolving the entire stack down to sheer Proof-of-Stake (PoS). Sentry Nodes provide additive finality through multi-quorum chainlocks that resist 51% attacks and selfish mining. This turns merge-mining into a secure source of hashpower, and makes it possible for Syscoin to provide safe modular data availability while sticking to the Nakamoto ideal of every full node independently validating before trusting.

Finality is particularly important for securing modular ecosystems such as those supporting rollups, especially because proper data availability (DA) requires pruning, and pruning requires certain guarantees afforded only by finality. Lack of finality is the reason the Bitcoin chain itself cannot provide DA, and one of several reasons Syscoin's merge-mined chain is important for scaling and expanding Bitcoin in the most ideal way.

It is true that finality can be achieved relatively easily within the PoS model compared to PoW. However, Syscoin maintains that PoW (specifically Bitcoin's through merged mining) is most desireable for a settlement base-layer due to the hardness of PoW's real-world inputs, and its resilience against black swans such as wars and fiat hyper-inflationary events.

Ultimately we found the best finality would come in the form of an additive layer on top of standard Nakamoto-style consensus. In line with comments by Andreas Antonopoulos, we found that the quorums and chainlocks introduced by Dash in their evolution masternodes model would be useful to this end. However, some important changes and enhancements would be in order. Instead of Dash's single quorum, Syscoin implemented a more robust multi-quorum scheme, involved a greater portion of the network, and used a higher block time. Furthermore, the finality was made explicitly additive. In other words, in the rare event finality is not achieved, the chain continues unabated rather than having a breaking event.

Network Stability#

The great stability of Syscoin's network is due in large part to Sentry Nodes being incentivized with block rewards and seniority bonuses. At time of writing the vast majority of Sentry Nodes have been running for over 2.5 years, having reached maximum seniority. Our seniority model, which is unique, is a proven success in this regard.

Governance#

Syscoin's network of Sentry Node owners can participate in Syscoin's decentralized governance which takes place on a ~monthly basis. As a Sentry Node owner, you determine whether or not proposals get approved for superblock funding. Find out more and see how to participate in Syscoin's decentralized governance.

Incentives and Requirements#

Owning a Syscoin Sentry Node and providing this service to earn income requires you to hold 100,000 SYS as collateral. While the Sentry Node is active it will be paid regularly for its service. The beginning of payments is determined by when the Sentry Node goes online. The (deterministic) qualification period following a Sentry Node activation typically lasts around a week depending on how many Sentry Nodes are currently on the network. A newly activated Sentry Node is added to queue of those waiting to be paid each block and this position will be kept as long as it is live. Fewer Sentry Nodes on the network translates to more frequent payments. With ~2500 online, a Sentry Node receives income roughly once every three days.

The base income payment to a Sentry Node is a 52.91 SYS block reward as of January 2024. There are two further seniority levels based on when the 100,000 SYS collateral transaction was settled, as can be seen below.

Payouts as of January 2024

Seniority Level	Block Payout
Basic	52.91 sys
1 year	71.43 sys
2.5 years	105.83 sys

There is a 5% reduction in these payouts each year. This reduction will cease in the distant future at a minimum of 5.275 sys per payout for basic-seniority level nodes, and 10.55 sys for full-seniority nodes. This floor, combined with SYS EIP-1559 coinomics, serves to keep Sentry Nodes incentivized indefinitely into the future.

If you have 100,000 SYS and are interested in setting up a new Sentry Node, use this setup guide.

Sentry Node Registry#

The Sentry Node Registry is the umbrella mechanism that tracks Sentry Node ownership and seniority on Syscoin Core (UTXO) and makes a read-only projection of that information available inside NEVM (EVM) for smart contracts and rollups. This section documents both sides and how they connect, so dapps can rely on the NEVM view while operators manage the ground truth on UTXO.

Registry model at a glance#

UTXO Registry (authoritative, in Core): The deterministic list of valid Sentry Nodes anchored by 100,000 SYS collateral, ProTx lifecycle, and BLS operator keys. Seniority is derived from the collateral block height. This is the canonical source of truth. See the Sentry Node Setup Guide.
NEVM Registry (projection, in sysgeth): A read-only mapping that associates an EVM address to UTXO-side Sentry metadata (notably the collateral height). Exposed to contracts via a precompile so dapps and rollups can gate features without bespoke indexers. See Syscoin Geth (sysgeth) and Prepare Your Syscoin Wallet.

tip

Think of the UTXO Registry as the source of truth and the NEVM Registry as a contract-friendly window into that truth.

Data flow (end-to-end)#

Operator stakes 100k SYS and registers a Sentry Node on UTXO via ProTx commands.
Ownership and seniority live in the deterministic UTXO list (derived from collateral height).
Operator associates an EVM address with their Sentry Node (so dapps can recognize them on NEVM).
sysgeth exposes a precompile that returns the collateral height for a given EVM address for contract consumption.

Associating your NEVM address#

To link your Sentry Node to an EVM address, follow the official support guide: NEVM SentryNode Registry tutorial

Important points from the guide:

A NEVM address can only be linked to one SentryNode at a time.
To reuse an address, you must first unlink it.
Your SentryNode must have already received three payout rounds before you can register a NEVM address; otherwise, you’ll see an error.
Use protx_update_service to register, update, or unlink ("" for empty address) the NEVM address.

UTXO Registry (Core) — operations and references#

Key data tracked

Collateral outpoint (collateralHash/collateralIndex)
Owner / voting addresses
Operator BLS public key
Seniority (from collateral confirmation height)

Common commands (via syscoin-cli / Qt console)

# Generate BLS keypair (store securely)
bls_generate

# Identify your 100k SYS collateral outpoint
masternode_outputs

# ProRegTx flow (prepare → sign → submit)
protx_register_prepare <collateralHash> <collateralIndex> <ip:port> <ownerAddr> <operatorBLSPubKey> <votingAddr> <operatorReward> <payoutAddr> [feeSourceAddr]
protx_register_submit <tx> <sig>

# Update service details (e.g., IP, operator payout, NEVM address)
protx_update_service <proTxHash> <ip:port> <operatorKey> <nevmAddress> [operatorPayoutAddr [feeSourceAddr]]

# Show valid entries in the deterministic list
protx_list valid

# Sync status
mnsync status

See the Sentry Node Setup Guide and the NEVM SentryNode Registry tutorial for step-by-step instructions and examples.

NEVM Registry (sysgeth) — precompile and usage#

What it exposes to contracts

Collateral height for an associated EVM address.
0 indicates “not associated / not found.”
Exposed via a precompile at 0x62 on NEVM.

Solidity wrapper (recommended)

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @title NEVM view of the Sentry Node Registry
/// @notice Returns UTXO-side collateral height for an associated EVM address.
contract NEVMRegistry {
    address constant PRECOMPILE = address(0x62);

    function getCollateralHeight(address who) external view returns (uint256 h) {
        (bool ok, bytes memory out) =
            PRECOMPILE.staticcall{gas: 200}(abi.encodePacked(who));
        require(ok && out.length == 32, "precompile call failed");
        h = abi.decode(out, (uint256));
        require(h > 0, "address not found");
    }
}

Try a live wrapper Deployed on NEVM mainnet: 0xbBAaa17aDde3D921c383029043E6C4E4De002CD7 Use the ABI above to call getCollateralHeight(address).

Off-chain (ethers.js)

import { ethers } from "ethers";
const provider = new ethers.JsonRpcProvider("https://rpc.syscoin.org"); // NEVM mainnet
const abi = ["function getCollateralHeight(address) view returns (uint256)"];

const registry = new ethers.Contract(
  "0xbBAaa17aDde3D921c383029043E6C4E4De002CD7",
  abi,
  provider
);

const height = await registry.getCollateralHeight("0xEvmAddressYouAssociated");
console.log("Collateral height:", height.toString());

Network reference

NEVM mainnet chainId 57; testnet 5700.
See Syscoin Geth (sysgeth) and Prepare Your Syscoin Wallet.

Governance (grounded in the UTXO Registry)#

Sentry Node owners vote on proposals for monthly superblock funding. Only valid Sentry owners (as per the UTXO registry) are eligible. Typical RPCs include:

gobject_prepare
gobject_submit
gobject_vote-*

See Decentralized Governance for the full lifecycle.

Example #1: airdrop gated by seniority#

interface ISNRegistry {
    function getCollateralHeight(address who) external view returns (uint256);
}

contract SentryAirdrop {
    ISNRegistry constant REG = ISNRegistry(0xbBAaa17aDde3D921c383029043E6C4E4De002CD7);
    mapping(address => bool) public claimed;
    uint256 public minSeniorityHeight; // set to a block height threshold

    function claim() external {
        require(!claimed[msg.sender], "already claimed");
        uint256 h = REG.getCollateralHeight(msg.sender);
        require(h > 0, "not a registered owner");
        require(h <= minSeniorityHeight, "not senior enough");
        claimed[msg.sender] = true;
        // mint/transfer payout...
    }
}

Example #2: weighted voting power (DAO influence)#

interface ISNRegistry {
    function getCollateralHeight(address who) external view returns (uint256);
}

contract WeightedVoting {
    ISNRegistry constant REG = ISNRegistry(0xbBAaa17aDde3D921c383029043E6C4E4De002CD7);
    uint256 public baseHeight; // governance sets this (e.g., deployment block)

    constructor(uint256 _baseHeight) {
        baseHeight = _baseHeight;
    }

    function voteWeight(address voter) public view returns (uint256) {
        uint256 h = REG.getCollateralHeight(voter);
        if (h == 0) return 0;
        uint256 age = baseHeight > h ? (baseHeight - h) : 0;
        uint256 K = 200_000; // scaling factor
        uint256 w = 1 + (age / K);
        if (w > 10) w = 10; // cap
        return w;
    }
}

Example #3: operator-only perks (tiered discounts)#

interface ISNRegistry {
    function getCollateralHeight(address who) external view returns (uint256);
}

contract OperatorPerks {
    ISNRegistry constant REG = ISNRegistry(0xbBAaa17aDde3D921c383029043E6C4E4De002CD7);

    struct Tier {
        uint256 maxHeight;
        uint16  bpsDiscount;
    }

    Tier[] public tiers;

    constructor(Tier[] memory _tiers) {
        for (uint i = 0; i < _tiers.length; i++) tiers.push(_tiers[i]);
    }

    function priceFor(address user, uint256 basePrice) external view returns (uint256) {
        uint256 h = REG.getCollateralHeight(user);
        if (h == 0) return basePrice;

        uint16 discountBps = 0;
        for (uint i = 0; i < tiers.length; i++) {
            if (h <= tiers[i].maxHeight) {
                discountBps = tiers[i].bpsDiscount;
                break;
            }
        }
        return basePrice - ((basePrice * discountBps) / 10_000);
    }
}

Troubleshooting#

Precompile returns zero / wrapper reverts Ensure your Sentry is valid on UTXO (protx_list valid), the EVM association was completed, and you’re querying the correct network (mainnet chainId 57).
Updating service, payout, or NEVM address Use protx_update_service with the current operator key (and "" to unlink a NEVM address).
Governance commands not found Upgrade to the latest Syscoin Core; governance RPCs are maintained and documented in releases.

Quick reference#

UTXO Registry (Core)

Keys & Collateral
- bls_generate → create operator BLS keypair.
- masternode_outputs → list wallet outputs eligible as collateral.
Registration & Lifecycle
- protx_register_prepare → build the ProRegTx payload.
- protx_register_submit → submit signed ProRegTx.
- protx_update_service → update IP, NEVM address, operator payout.
- protx_update_registrar → update owner, voting, or payout addresses.
- protx_revoke → revoke a Sentry Node (invalidates entry).
- protx_list → list ProTx entries (valid, registered, etc.).
Masternode / Sentry Info
- masternode_list → show status/details of masternodes (mode arguments like status, full).
- masternode_status → show the status of the local masternode.
Sync & Debug
- mnsync status → show deterministic masternode list sync state.
- getblockchaininfo / getnetworkinfo → confirm chain state and peer status.
Governance
- gobject_prepare → create a governance object (e.g. proposal).
- gobject_submit → submit governance object.
- gobject_vote-alias / gobject_vote-conf / gobject_vote → vote using a node or voting key.
- gobject_list → list governance objects.

NOTE: Commands above can be run either via syscoin-cli or in the Debug Console of Syscoin-Qt (Window → Console).

NEVM Registry (sysgeth / contracts)

Chain IDs: 57 (mainnet), 5700 (testnet)
Precompile: 0x62
View wrapper: getCollateralHeight(address) → uint256