OctopusbridgeOctopusbridge relayers: event validation in Octus Bridge V2
The historical Octus Bridge V2 design used relayers to confirm configured cross-chain events. EVM deposits required votes on Everscale event contracts, while Everscale-to-EVM withdrawals used signed payloads that destination contracts could verify. Operating a relayer involved BRIDGE staking, node operation, and election participation, with exposure to DAO slashing.
Find a section
Broxus’s September 23, 2026 infrastructure notice scheduled the end of its Everscale-related Octus Bridge infrastructure for September 29, 2026. Availability of the affected relay infrastructure and transfer routes after that date is unconfirmed.
EVM deposits and event-contract votes
The V2 Litepaper placed the list of monitored events on Everscale and gave the DAO authority to add or remove entries. Relayer nodes watched the configured events on Everscale and connected EVM networks, providing confirmations that the bridge contracts could use for cross-chain actions.
In the integration guide’s MultiVault flow, an EVM deposit emitted a
Deposit
event and either an
AlienTransfer
or
NativeTransfer
event, according to the token classification. An event contract on Everscale represented that deposit for relayer voting. The relevant event configuration supplied
blocksToConfirm
, so the block requirement depended on that configuration. Release or minting on Everscale also depended on satisfying the required relayer confirmation quorum.
Deploying the event contract was a separate task from voting on it. When EVM gas tokens funded the Everscale operations, Credit Modules handled deployment, provided that sufficient gas tokens were attached and
expected_Evers
matched the event contract’s initial balance. A lower value or insufficient attached EVM gas tokens meant that deployment had to be manual. When those operations were funded with EVER,
expected_Evers
was zero and deployment required a manual
deployEvent
call on
EthereumEverscaleEventConfiguration
. Both paths still needed relayer confirmations.
After the required confirmations, this EVM-to-Everscale flow released Native tokens or minted Alien tokens, using the integration guide’s classifications. A recorded EVM deposit therefore established an earlier stage than delivery on Everscale; event deployment and validation remained material dependencies.
Everscale withdrawals and signature submission
For Everscale-to-EVM withdrawals, the V2 Litepaper described signed payloads in place of direct relayer transactions on the EVM network, citing potentially high network fees. Relayers signed an EVM-compatible payload and stored their signatures in an Everscale contract. A bridge contract on each connected EVM network held the relayers’ public keys so that signatures could be verified.
In the Litepaper’s vault model, anyone could submit the payload and signature list to the vault. Valid signatures allowed the vault to release tokens. Collecting signatures and submitting the destination transaction were separate stages, so a stored relayer signature alone did not establish that the destination submission had occurred.
The integration guide described a MultiVault flow in which Credit Modules, a set of backend scripts, called
saveWithdraw
to initiate release or minting on the EVM side. That submission responsibility was distinct from the relayers’ validation work.
Stake thresholds and relay rounds
The V2 Litepaper described a relayer candidate as a stakeholder with more than 100,000 BRIDGE staked who also started a relayer node and applied for the next election. A qualifying stake was one entry requirement; selection still depended on the election.
Elections occurred each round, with rounds described as one week long. The DAO could change both the minimum stake and the round duration. These were configurable parameters of the documented design, so its quoted stake threshold and weekly schedule should not be treated as permanent operating rules. Historical relayer guidance also specified that each participation in voting automatically extended the stake lock-up for two months.
Reward funding and slashing
The V2 reward model drew on earnings from managing vault liquidity on the EVM side. Those earnings were to be transferred to Everscale, converted into BRIDGE, and distributed between staking participants and relayers. The Litepaper’s initial allocation gave each group 50% of that distribution, with the DAO able to change the ratio. This was a division of gains allocated for distribution, not a stated return on an operator’s staked BRIDGE.
The DAO could slash a relayer for confirming an incorrect event or failing to participate in event confirmations. Under the Litepaper’s model, slashing redistributed the affected relayer’s stake and reward to the current stakeholders.
Checks for interpreting confirmation or assessing participation
- For an EVM deposit, check event-contract deployment and the required confirmation quorum separately from the source-chain deposit record.
- For an Everscale-to-EVM withdrawal, distinguish stored signatures from submission of the payload to the destination vault.
- For a prospective relayer, establish the applicable round’s stake threshold and duration, and account for the stake lock-up after voting and the documented slashing conditions.
- For live use, establish that the required relay infrastructure and route are operating after Broxus’s scheduled September 29, 2026 infrastructure withdrawal.