Consensus

MigoChain is an EVM-compatible Layer-1 protocol that runs on Proof of Staked Authority (PoSA). The active validator set produces blocks in a fixed order determined at the start of each epoch: at every height, the validator whose turn it is (“in-turn”) is known in advance, and everyone on the network knows ahead of time who the next block is expected from. Out-of-turn production is possible — if the in-turn validator misses its block, the next validator steps in — but this stays visible on the network and is recorded against that validator’s performance history.

Downtime is measured over a separate, sliding window, not the epoch itself. The epoch is the cadence at which the validator set is updated; it is far too short a unit for measuring downtime, because as the validator count grows, the number of in-turn slots available to each validator within a fixed-length window shrinks, and honest validators would be penalized unfairly. Instead, the window length grows in proportion to the number of active validators, so that the expected number of slots per validator stays constant regardless of how many validators are on the network. If a validator’s overall production rate within the window falls below the threshold, a downtime penalty applies.

Entry into the validator set follows FIFO order, but the queue is not a bare sequence: a diversity filter prevents validators from the same autonomous system number (ASN) or the same legal jurisdiction from exceeding a set share of the set. The goal is to prevent the validator set from concentrating in a single hosting provider or a single legal jurisdiction — and with it, to prevent a single outage or intervention from affecting the majority of the network at once.

InstantSend

To prevent double-spending without waiting for block confirmation, MigoChain uses a threshold signature scheme built on masternode quorums. When a transaction is broadcast, members of the masternode quorum produce partial signatures on the BLS12-381 curve; once enough partial signatures are collected, they combine into a single threshold signature and the transaction is “locked.” The threshold is stricter than the quorum majority (the block-liveness threshold) — see the comparison in the table below — because double-spend protection requires a higher assurance than accepting a single block does.

Any block that conflicts with a locked transaction is rejected at the consensus level: validators do not produce a block that would invalidate a locked transaction, and they do not accept one if it arrives. The lock is not a discretionary priority signal left to a miner or validator; it is a constraint enforced by the protocol itself.

Client architecture

The node software MigoChain runs is built on go-ethereum and carries a small, well-defined diff that replaces the consensus engine with PoSA. That diff leaves everything else in go-ethereum untouched — the EVM executor, the RPC layer, the state database, the network protocol. The result is a client that is directly compatible with the rest of the EVM ecosystem, including MetaMask, ethers.js, Foundry and standard block explorers: these tools need no special integration to connect to MigoChain, only the network’s chain ID and RPC endpoint.