Rotko/Sceptre Operating Multiple Infrastructure Identities

ftso group test
,
1

Proposed defendants (registered Flare C-chain infrastructure-provider identity addresses)

  1. 0x7e74D30eF4dd811830118645633a9471f6cc63D3 (self-identified in a pending Bifrost listing application as Rotko Networks)
  2. 0xb70c6987626A96df66C9068bd10b84Ecb8e949df (currently unnamed in the public dashboards reviewed)

Snapshot date: 30 August 2026 (UTC)

Requested action: A first chill of both provider identities under FIP.02, with each address submitted as a separate PollingFtso proposal if the contract requires one defendant per proposal, followed by mandatory consolidation to one registered on-chain infrastructure-provider identity. Failure to remediate by the end of the first chill will trigger immediate second-strike proposals seeking permanent removal.

September 8 addendum

After feedback from a foundation employee the correct remediation procedure would be to unregister the nodes from participation while leaving them running to prevent block gaps, chilling is not exclusive from full validator shut down.
Remediation process should read that if the nodes are not unregistered from the network by the end of the chill period then the second proposal moves forward.

This proposal does not allege copied prices, duplicated FTSO submissions, or poor price accuracy. The alleged infraction is that one entity—Sceptre—owns the validator self-bonds and validator reward rights used across two separately registered on-chain infrastructure-provider identities. No person or entity may operate more than one registered on-chain infrastructure-provider identity.

Executive assessment

The central evidence is the validators’ self-bond and reward-owner accounts, considered together with the host attribution and Sceptre’s first-party admission:

  • Every one of the seven individual Catenalytica Validator Details pages identifies the node’s host as Rotko Networks. This is node-level host discovery, not an inference from either provider’s name. Flare Builders corroborates the four nodes under the first identity, while the second identity’s page shows its three active nodes as Rotko Networks.
  • Rotko’s pending TowoLabs pull request #459 self-identifies the first address as Rotko Networks and says Rotko operates its own bare-metal Flare infrastructure, including four validator nodes.
  • FIP.05 defines self-bond as the stake an entity must provide to become a validator. In every decoded P-chain validator-registration transaction, the 20M-FLR stake output, validationRewardsOwner, and delegationRewardsOwner all point to the same one of four P-chain accounts. Posting those self-bonds is a direct on-chain claim of validator ownership: the four accounts own the returned principal and both validator reward streams. Every registration TxID is linked in section 1.3’s first transaction table.
  • The corresponding C-chain accounts were all granted privileged DEPOSIT, WITHDRAW, and instant-redemption-buffer roles on the Sceptre sFLR contract by the same sFLR administrator on 15 July 2026. The deposit/withdraw grants formed one two-minute batch; the four buffer grants formed a later 43-second batch. Every grant is linked in section 1.3’s role-grant table.
  • The four accounts then used those privileged Sceptre roles to withdraw approximately 20M FLR from the sFLR pool immediately before each corresponding 20M-FLR P-chain self-bond. Six validator registrations followed 24–26 seconds after the privileged withdrawal; the seventh followed within ten minutes. The exact C-chain calls, P-chain imports, and validator-registration TxIDs are linked row by row in section 1.3’s direct-funding timeline.
  • This repeated funding sequence demonstrably identifies the C-chain accounts as Sceptre-owned/controlled operational accounts in the on-chain sense defined in section 1.3. The linked transaction record connects each privileged pool withdrawal to the same owner’s P-chain import and self-bond transaction. The two Provider A owner accounts also have exact linked validator-reward claim transactions; the newer Provider B accounts own the reward rights in their exact linked registration transactions. These are not merely outside wallets delegating liquid-staking funds to unrelated validators.
  • Sceptre publicly stated in its May 2026 recap that it was testing one validator and considering operating its own validator to avoid entity fees and gain more control over rewards.
  • In a 10 August 2026 X reply, @SceptreLS went further: in response to a question about anonymous new providers receiving exceptionally large Sceptre delegations, it expressly said the referenced node was run by Sceptre and linked the May recap. That admitting reply has since been deleted from X, but its original JSON remains recoverable through the Internet Archive’s raw Wayback capture.
  • Five additional P-chain wallets that supply the external delegated stake map to C-chain accounts funded and role-authorized by the same sFLR administrator. Every cited delegation, initial funding transfer, and role grant is linked to its exact transaction in section 1.5. This corroborates the Sceptre relationship but is not required for the central finding.

Taken together, the evidence establishes the relevant ownership and hosting facts: Sceptre-controlled accounts supplied and own every validator self-bond and both validator reward streams, making the seven validators Sceptre’s nodes; Catenalytica identifies Rotko Networks as the host of every node.

1. Observation

1.1 Two registered on-chain provider identities are running validator sets on the same Rotko infrastructure

The two provider identities are:

Provider A currently has four active validators. Provider B currently has three active validators and has also displayed a fourth, now-expired NodeID in Catenalytica. The seven active validators are:

Registered provider identity Validator Details page Catenalytica host discovery Self-bond
0x7e74…63D3 NodeID-436a…78NR Rotko Networks 20M FLR
0x7e74…63D3 NodeID-QK6w…kyBE Rotko Networks 20M FLR
0x7e74…63D3 NodeID-C3cw…h3a3 Rotko Networks 20M FLR
0x7e74…63D3 NodeID-LwpT…uExo Rotko Networks 20M FLR
0xb70c…49df NodeID-QcDi…bY8 Rotko Networks 20M FLR
0xb70c…49df NodeID-K8GP…XMq Rotko Networks 20M FLR
0xb70c…49df NodeID-Q3Mp…vJs Rotko Networks 20M FLR

Each NodeID in the table links directly to its own Catenalytica Validator Details page. Every page reports that validator as hosted by Rotko Networks. Catenalytica’s underlying node-level records encode the same result as location.isp: "Rotko Networks", with separate discovery records and check timestamps for the seven nodes. This is direct validator-by-validator host attribution, not an inference from the registered identity or provider name. Flare Builders also displays Rotko Networks beneath every node.

The host discovery establishes that all seven validators use Rotko infrastructure. The on-chain self-bond ownership evidence below establishes the separate ownership link to Sceptre-privileged accounts.

1.2 Rotko has self-attributed Provider A and its four validators

On 13 August 2026, GitHub user hitchho, whose profile identifies rotko.net, opened TowoLabs PR #459. The application identifies 0x7e74…63D3 as Rotko Networks and states that Rotko operates its own bare-metal Flare infrastructure, including FTSO, FDC, and four validator nodes. Its sole commit was authored and committed by Tommi Niemi using [email protected].

The proposed Bifrost entry also requests "listed": true. This is relevant because TowoLabs’ extended listing requirements say that a resilient team runs only one signal provider attracting vote power per network, and an independent team has no legal, development, or operational ties to another signal provider.

Evidence placement: To comply with the Discourse post limit, sections 1.3–1.5 and the complete transaction/reproducibility record are posted in the first reply directly below. That reply is an integral part of this proposal.

2. Analysis: Why this is a governance infraction

2.1 One Sceptre-owned validator cluster across two registered on-chain identities

The infraction examined here is operation by one entity through multiple registered on-chain infrastructure-provider identities. It does not depend on which individual protocol function an identity performs or on the number of validators assigned to it.

Here, the evidence connects both registered on-chain identities at multiple independent layers:

  1. Host/operator layer: every active node is identified as Rotko Networks.
  2. Public attribution layer: Rotko claims Provider A and four validators.
  3. Validator-ownership layer: the exact registration and role-grant transactions linked in section 1.3 show that the accounts owning the self-bond outputs and validator rewards for both providers were batch-authorized as privileged Sceptre pool operators by the same Sceptre role administrator.
  4. Direct-funding layer: the exact C-chain and P-chain transactions linked in section 1.3 show those accounts exercising Sceptre-only roles to withdraw approximately 20M FLR from the sFLR pool immediately before posting each 20M-FLR self-bond—six within 24–26 seconds and all seven within ten minutes.
  5. Reward-flow layer: the exact registration transactions linked in section 1.3 assign both validator reward streams to the same Sceptre-controlled owners; that section also links the two Provider A owners’ ValidatorRewardManager.claim transactions.
  6. Delegated-stake layer: the exact delegation transactions linked in section 1.5 show Sceptre’s operating wallets supplying outside stake across both identities, including one reward owner that crosses from a Provider A validator to a Provider B validator.
  7. Admission layer: Sceptre first acknowledged an active validator test and later expressly said that the node referenced in a large-delegation inquiry was run by Sceptre.

The self-bond and reward-owner transactions establish ownership: these are Sceptre’s validators. The validator-detail records separately establish that Rotko Networks hosts all seven. Rotko hosting does not change Sceptre’s ownership of the nodes used across both registered on-chain identities.

2.2 Prohibited operation of more than one registered on-chain infrastructure-provider identity

No person or entity may operate more than one registered on-chain infrastructure-provider identity. This is a binary identity rule: an operator is either operating an identity or it is not. The seven exact self-bond registrations identify a single owner—Sceptre—operating validator infrastructure across the two registered identities. Rotko hosting does not convert Sceptre’s separately presented nodes into independent providers.

The P-chain records ownership through the self-bond and reward-owner fields but cannot itself prevent the owner from presenting different C-chain FTSO addresses as separate infrastructure providers. That is precisely why Management Group enforcement is required here.

2.3 Listing representations and ecosystem transparency

Rotko’s pending Bifrost application asks to be treated as a listed provider while representing four validators under Provider A. It does not disclose the second Rotko-hosted identity or the Sceptre operational linkage.

That omission is material under TowoLabs’ published extended requirements, which require a listed provider to run only one signal provider attracting vote power per network and to have no operational ties to another signal provider. This proposal does not ask the Management Group to administer Bifrost’s private list, but the listing application is relevant evidence of how the operation is represented to users.

2.4 FIP.02 permits case-by-case infractions

FIP.02 deliberately leaves “infractions” open-ended and gives non-exhaustive examples. It requires a public discussion, reasons, provider address, and evidence. Therefore, the Management Group can evaluate undisclosed common operation and conduct affecting an adopted entity-level safeguard without turning this matter into an allegation about price submissions.

2.5 Network harm

Allowing one undisclosed operating cluster to present itself as two independent infrastructure entities can:

  • undermine adopted entity-level validator safeguards;
  • concentrate validation, FTSO/FSP weight, fees, and rewards;
  • mislead delegators and stakers who believe they are diversifying across independent providers;
  • create common-mode operational risk across apparently separate providers; and
  • weaken the credibility of provider directories and the Management Group’s entity-based controls.

3. Summary of charges

Charge 1 — Sceptre ownership and control of the validator accounts

The exact transactions in section 1.3 show Sceptre-privileged accounts directly sourcing the validator principal from the Sceptre sFLR pool, then posting and owning the self-bonds and validator rewards for the Rotko-hosted validator sets attached to both 0x7e74…63D3 and 0xb70c…49df. The repeated privileged-withdrawal-to-self-bond sequence is direct on-chain evidence of Sceptre ownership and control, inconsistent with presenting the providers as independent without disclosure.

Charge 2 — Operation by one entity through multiple infrastructure-provider identities

The exact role-provisioning and funding transactions in section 1.3 show the July batches and seven repeated self-bond funding sequences spanning both registered on-chain identities. They establish deliberate operation by Sceptre through multiple separately registered infrastructure-provider identities rather than incidental delegation or hosting. The infraction is complete once the same entity operates more than one registered identity; protocol role, activity mix, validator count, and stake expiry do not alter that test.

Charge 3 — Material omission in a public provider-listing application

The Rotko application identifies only Provider A and its four validators while requesting listed status under requirements that prohibit multiple signal providers and operational ties to another provider. The second Rotko/Sceptre-linked identity is not disclosed.

4. Proposed action

I propose that the Infrastructure Provider/FTSO Management Group:

  1. Open public discussion against both provider identity addresses.
  2. Invite Rotko Networks, Sceptre, and Rome Blockchain Labs to identify any specific transaction, decoded ownership field, or address mapping they contend is incorrect, and to disclose all current and historical NodeIDs attached to the two defendant identities.
  3. Submit separate formal chill proposals for:
    • 0x7e74D30eF4dd811830118645633a9471f6cc63D3; and
    • 0xb70c6987626A96df66C9068bd10b84Ecb8e949df.
  4. Apply the first-chill consequence specified by FIP.02: removal from participation and ineligibility to reapply for two FTSO reward epochs.
  5. Make reinstatement conditional on the remediation requirements below.
  6. Request that TowoLabs reject or pause PR #459 and any listed designation while more than one Sceptre-owned infrastructure identity exists.

Chilling only one address would leave the same entity operating through the other infrastructure-provider identity. The proposed action therefore covers both addresses. The required public discussion remains the proper venue for correcting a specific factual or transaction-decoding error.

Required remediation and second-strike escalation

The first chill must carry a clear, binary remediation requirement. By the end of the two-reward-epoch chill, Sceptre must:

  1. publicly designate one—and only one—surviving registered C-chain infrastructure-provider identity;
  2. cause every other Sceptre-owned or Sceptre-controlled provider identity—including whichever defendant address is not the survivor—to be removed from the on-chain provider registry and to cease operating;
  3. cease all operation of every identity other than the survivor, including protocol submissions, provider registration, whitelisting or listing activity, and use of that identity for any validator or infrastructure-provider function;
  4. publish the surviving identity and all NodeIDs that will remain associated with it; and
  5. refrain from replacing any removed identity with a new address, brand, nominee, self-bond account, NodeID set, or hosting arrangement.

Existing stake and self-bond expiry dates create no grace period and no excuse for continued operation of a separate provider identity. Sceptre chose the duration and expiry of each registration through its own staking transactions, as recorded in the exact validator-registration TxIDs linked in section 1.3; those self-imposed dates cannot postpone the remediation deadline. The stake remains locked until its recorded expiry, but that lock neither requires nor authorizes continued operation or registration of a separate on-chain identity. The remediation test is binary: after the deadline, exactly one Sceptre-owned or Sceptre-controlled infrastructure-provider identity may remain registered and operating. Every other identity must be removed from the provider registry and cease operating by the end of the first chill. Consolidation is not satisfied by rotating wallets, moving the same nodes, renaming an entity, or shifting the same Sceptre-owned self-bonds behind a new on-chain provider address.

If Sceptre has not completed this consolidation by the end of the first chill, the failure will trigger immediate second-chill proposals against both defendant identities and any successor identity used to continue the same operation. FIP.02 specifies that a second chilling permanently bans the provider. The second-strike proposals should therefore request:

  • permanent removal of both defendant identities;
  • lifetime disqualification of Sceptre and Rotko Networks from operating, controlling, or presenting an infrastructure provider on Flare, including through replacement addresses, nominees, brands, or successor entities; and
  • treatment of any attempted address or entity rotation as continuation of the permanently banned providers rather than a new application.

At the same time, the Management Group should open the floor for a separate discussion on whether the lifetime entity-level exclusion should extend to Rome Blockchain Labs, which Sceptre’s own Privacy Policy identifies as “the Company” providing the Sceptre services and whose public repository contains the Sceptre liquid-staking contracts. That extension should be decided openly because it concerns the company behind the Sceptre product, not merely the two presently identified provider addresses.

1 Like
2

Evidence reply 1 — Transaction record and reproducibility

This reply is an integral part of the proposal above and contains sections 1.3–1.5 plus the complete evidence notes.

1.3 The validators’ self-bond and reward-owner accounts are demonstrably Sceptre-owned/controlled operating accounts

Flare’s P-chain platform.getCurrentValidators response identifies each validator’s validationRewardOwner separately from each outside delegator’s rewardOwner. Decoding each underlying registration transaction with platform.getTx adds two important fields:

  • stake[].output.addresses: the owner address to which the 20M-FLR self-bond output belongs; and
  • validationRewardsOwner and delegationRewardsOwner: the destinations for rewards earned by the validator itself.

For every node below, all three fields contain the same P-chain address. FIP.05 defines the minimum self-bond as the minimum stake an entity must provide to become a validator, and Flare’s validator documentation describes it as the validator’s “own stake.” Posting these self-bonds is therefore a direct on-chain claim of ownership, not merely a nominated reward relationship. The separate question of who physically holds each NodeID/staking key concerns operational custody, not the ownership claim encoded by the self-bond.

Registered provider identity Nodes and registration transactions P-chain self-bond/reward owner Corresponding C-chain account
0x7e74…63D3 436a, LwpT P-flare1gwds…j3v0 0x9d2f…2481
0x7e74…63D3 QK6w, C3cw P-flare1hwyq…4mcf 0xDEBa…18dC
0xb70c…49df QcDi, K8GP P-flare13hg2…dm53 0x65b2…e843
0xb70c…49df Q3Mp P-flare10rcs…59hp 0xcE62…76b6

The official Flare stake tool explains that the P- and C-chain addresses are derived from the same public key. The mappings above are independently viewable on the linked flare.space P-chain pages.

On 15 July 2026, address 0xF76a…0Ef9 successfully called grantRole on 0x12e605…51c2BB, the Sceptre Staked FLR (sFLR) contract, for every one of the four C-chain accounts above.

The role-grant transactions are:

Self-bond C-chain account ROLE_DEPOSIT ROLE_WITHDRAW Instant-redeem-buffer role
0x9d2f…2481 tx tx tx
0xDEBa…18dC tx tx tx
0x65b2…e843 tx tx tx
0xcE62…76b6 tx tx tx

The first deposit/withdraw grant occurred at 10:50:32 UTC and the last at 10:52:31 UTC. The buffer-role grants followed at 14:23:59–14:24:42 UTC. Both batches span the reward-owner accounts of both registered provider identities.

The official Sceptre/Rome Blockchain Labs source defines ROLE_DEPOSIT and ROLE_WITHDRAW in StakedFlrStorage.sol. StakedFlr.sol requires those roles to withdraw FLR from and deposit FLR into the sFLR pool without minting sFLR. The live contract’s verified ABI and implementation source additionally define ROLE_MANAGE_INSTANT_REDEEM_BUFFER and decreaseInstantRedeemBuffer(uint256). These are privileged administrative/operational AccessControl roles; the report does not claim the grantees held the global DEFAULT_ADMIN_ROLE. Successful grantRole transactions establish that 0xF76a…0Ef9 held the required role-admin authority on the Sceptre contract at the time.

The privileged Sceptre accounts directly funded every validator self-bond

The role grants were exercised, not merely assigned. Each C-chain account used its privileged Sceptre WITHDRAW and instant-redeem-buffer permissions to release approximately 20M FLR from the sFLR pool immediately before the corresponding same-key P-chain account posted a 20M-FLR validator self-bond:

Registered provider identity / node registration Sceptre-controlled C-chain account Privileged sFLR operation(s) P-chain validator start Elapsed
A — QK6w: P import → self-bond 0xDEBa…18dC buffer decrease; ≈20M withdrawal at 16:26:21 2026-07-15 16:26:46 UTC 25 sec
A — C3cw: P imports 1, 2 → self-bond 0xDEBa…18dC ≈20M withdrawal at 19:21:51 2026-07-17 19:22:16 UTC 25 sec
A — LwpT: P import → self-bond 0x9d2f…2481 buffer decrease; ≈20M withdrawal at 07:50:49 2026-07-29 07:51:15 UTC 26 sec
A — 436a: P import → self-bond 0x9d2f…2481 buffer decrease; ≈20M withdrawal at 05:21:04 2026-08-14 05:21:28 UTC 24 sec
B — QcDi: P import → self-bond 0x65b2…e843 buffer decrease; ≈20M withdrawal at 11:01:55 2026-08-17 11:11:54 UTC 9 min 59 sec
B — K8GP: P imports 1, 2 → self-bond 0x65b2…e843 buffer decrease; ≈20M withdrawal at 12:20:54 2026-08-20 12:21:18 UTC 24 sec
B — Q3Mp: P import → self-bond 0xcE62…76b6 buffer decrease; ≈20M withdrawal at 10:45:40 2026-08-28 10:46:04 UTC 24 sec

The source contract permits these withdrawals only to an account holding Sceptre’s ROLE_WITHDRAW. The linked transactions show six of the seven funding sequences also reducing the instant-redemption buffer. The linked P-chain registration transactions assign the self-bond output and both validator reward streams to the corresponding same-key accounts. By the snapshot date, both Provider A owner accounts had also executed successful ValidatorRewardManager.claim calls: 0x9d2f…2481 claim and 0xDEBa…18dC claim. The newer Provider B owner accounts had no confirmed validator-reward claim in the public history reviewed at the snapshot.

For purposes of this proposal, “Sceptre-owned/controlled” means demonstrably controlled and used as Sceptre operational accounts on-chain: the exact linked transactions show Sceptre’s role administrator assigning privileged pool-management roles, the accounts exercising those roles to source the validator principal from Sceptre’s pool, P-chain imports under the corresponding owners, and those owners posting and owning the self-bonds and associated reward rights. This establishes Sceptre’s ownership and control of the accounts and validators.

The common provisioning date and the repeated withdraw-to-self-bond sequence across accounts assigned to both Provider A and Provider B demonstrate advance intent to run validator infrastructure through multiple separately registered on-chain provider identities. It is not consistent with accidental common hosting or passive Sceptre delegation to unrelated third-party validators.

1.4 Sceptre admitted running the referenced node, then the reply was deleted from X

In its 2 June 2026 monthly recap, Sceptre said it was considering running its own validator to save the entity fee and gain more control over rewards. It also said it was already testing one validator with a small amount of FLR.

On 10 August 2026, an X user asked @SceptreLS why anonymous new providers were receiving hundreds of millions of FLR in delegated stake, noting that one might be close to one billion, and asked whether those were Sceptre’s nodes. Sceptre replied: “Regarding that node you mentioned, yes, it’s run by us.” It added that this was a measure to increase Sceptre’s APY and linked its May recap.

The admitting reply has since been deleted from X. As of the report snapshot, the original X status URL renders a page titled “Post Not Found - X | 404 Error,” and X’s public syndication lookup returns an empty JSON object. The deleted post nevertheless remains recoverable and verifiable through the Wayback Machine in two forms:

  • raw archived JSON, where Wayback’s id_ modifier returns the archived original bytes without rewriting them; the payload records tweet ID 2086928614298120586, author ID 1772917948883111936, username SceptreLS, creation time 2026-08-10T21:32:09Z, the full parent question, and the linked May recap; and
  • the CDX index record, which records capture timestamp 20260810213209, MIME type application/json, digest SFKNUX5YNH6QTBJVS44ZPRCGIMQ35V5H, and capture length 4082.

The live deletion does not erase the admission. The archived payload preserves the post’s author identity, text, timestamp, reply context, linked May recap, and archive digest. The original X URL and the two Wayback links should all be included in any forum submission so reviewers can verify both the post’s present absence and its archived contents.

This is substantially stronger than the earlier statement that Sceptre was merely testing a validator. However, the parent question does not publish a NodeID or address. The archived reply therefore proves that Sceptre ran the node then being discussed, but it does not, standing alone, identify which defendant. Address-level attribution comes from the self-bond/reward-owner evidence in section 1.3 and the other layers of the combined record.

1.5 Sceptre’s delegated-stake wallets also span both identities

Current P-chain delegation records identify five recurring reward-owner wallets across the seven validators. The linked transactions below establish at least one delegation by each wallet to every referenced validator, including one wallet that delegates across Provider A and Provider B:

P-chain delegation reward owner C-chain account Target validator and delegation transaction evidence
P-flare1qrs9…c57f 0xf299…5918 Provider A: 436a tx, C3cw tx
P-flare1ez7a…ryt4 0x5801…7D61 Provider A: QK6w tx; Provider B: Q3Mp tx
P-flare10ylj…e0gfu 0x8d17…d188 Provider A: LwpT tx
P-flare1n0fk…x58x 0xDa27…8CcF Provider B: QcDi tx
P-flare14cyr…90gr 0x4CBC…f470 Provider B: K8GP tx

All five C-chain accounts received their first normal C-chain gas funding from the same Sceptre role administrator, 0xF76a…0Ef9: f299 funding tx, 5801 funding tx, 8d17 funding tx, Da27 funding tx, and 4CBC funding tx.

The same administrator also granted every account the Sceptre withdrawal, reward-accrual, and deposit roles. Each action is linked below:

Delegation C-chain account ROLE_WITHDRAW grant ROLE_ACCRUE_REWARDS grant ROLE_DEPOSIT grant
0xf299…5918 tx tx tx
0x5801…7D61 tx tx tx
0x8d17…d188 tx tx tx
0xDa27…8CcF tx tx tx
0x4CBC…f470 tx tx tx

This evidence strongly establishes that the delegation wallets are Sceptre operating wallets. It does not, standing alone, prove that Sceptre owns a validator: Sceptre says it spreads customer assets across more than 50 selected nodes. The materially stronger additional fact is that the accounts owning the validators’ 20M-FLR stake outputs and validator rewards in section 1.3 are also Sceptre-privileged operating accounts.

Evidence notes and reproducibility

Transaction-citation standard

Every statement in this report that an address performed an on-chain action is supported by an exact transaction link. Section 1.3 links all seven validator registrations, nine P-chain imports, twelve self-bond-account role grants, seven privileged withdrawals, six buffer-management calls, and two reward claims. Section 1.5 links all seven representative delegations, five initial C-chain funding transfers, and fifteen delegation-account role grants. The executive assessment, analysis, and charges summarize those same actions and expressly cross-reference the transaction tables; they do not introduce uncited on-chain events. Address pages are used only for identity/address mapping, not as substitutes for transaction evidence.

A. Source hierarchy

Primary/on-chain evidence

  • Flare P-chain platform.getCurrentValidators records for NodeID-to-FTSO association, self-bond, validationRewardOwner, and delegator reward owners, plus each immutable registration transaction decoded with platform.getTx.
  • Flare C-chain grantRole transactions and subsequent Sceptre/reward-manager calls.
  • Sceptre/Rome Blockchain Labs’ public contract source and the sFLR contract’s explorer metadata.

First-party statements

  • Rotko’s TowoLabs listing application and Rotko-associated GitHub author/commit metadata.
  • Sceptre’s May 2026 validator-test statement and its deleted 10 August X admission, preserved as original JSON and indexed by the Wayback Machine.
  • Sceptre’s description of its multi-node delegation model.

Independent dashboards

  • Catenalytica provider and validator pages.
  • Flare Builders entity and validator pages.
  • flare.space P-to-C address mapping.

B. Reproduction procedure

  1. Query platform.getCurrentValidators for each NodeID using any Flare P-chain RPC, following the official Flare stake-tool example.
  2. Record validationRewardOwner.addresses, not the similarly named reward owners inside the delegators array.
  3. For each returned validator TxID, call platform.getTx with encoding: "json". Verify that stake[].output.addresses, validationRewardsOwner.addresses, and delegationRewardsOwner.addresses all contain the same owner shown in the table above.
  4. Open each P-chain owner on flare.space and record the corresponding C-chain address. The official stake tool explains why both addresses derive from the same key.
  5. Open the linked C-chain grantRole transactions. Verify:
    • sender 0xF76a…0Ef9;
    • target 0x12e605…51c2BB;
    • method grantRole(bytes32,address);
    • grantee matching the self-bond C-chain account; and
    • successful status.
  6. Compare each role hash to Sceptre’s published role constants or the sFLR contract’s role getter values.
  7. Open each linked privileged-withdrawal transaction in the direct-funding timeline. Verify the sender is the mapped self-bond owner, the target is the Sceptre sFLR contract, the input begins with selector 0x2e1a7d4d, the amount is approximately 20M FLR, and the status is successful. Sceptre’s published source and the verified live implementation define that selector as withdraw(uint256); this avoids relying on an explorer’s mutable method-name label.
  8. Compare its timestamp with the corresponding validator start time. Confirm that all seven self-bonds followed within ten minutes and six followed within 24–26 seconds.
  9. Open the two linked Provider A ValidatorRewardManager.claim transactions and verify the sender and _rewardOwner match the applicable self-bond/reward-owner account. Do not infer a Provider B claim: none was confirmed at the snapshot.
  10. Open the original X status URL and confirm it is no longer available. Then open the archived Sceptre reply with Wayback’s id_ modifier to inspect the original JSON bytes and compare its tweet ID, author ID, timestamp, parent text, and digest with the CDX index record.

C. Evidentiary limits and fair-response standard

This report establishes on-chain Sceptre ownership/control of the operational wallet accounts, validator self-bonds, and validator reward rights. It does not claim to adjudicate:

  • that the two providers submit copied or statistically correlated prices;
  • that common hosting by itself proves common control; or
  • that Sceptre delegation to a validator, by itself, proves validator ownership; or
  • that the archived X reply, by itself, identifies a particular NodeID or FTSO address.

The ownership finding rests on the exact registration transactions: the Sceptre-controlled accounts own the validators’ self-bond outputs and both reward streams. The privileged role assignments and withdraw-to-self-bond sequences independently establish that those are Sceptre operational accounts. A statement that Sceptre delegates broadly or that Rotko sells hosting does not rebut ownership of the self-bonds and validator rewards.

3

Independent reproduction, plus three additions to the record

I reproduced sections 1.3 and 1.5 against Flare mainnet on 2026-08-31 from a clean start — P-chain RPC, C-chain atomic transactions, explorer — without following the links in the evidence reply, to check the record rather than re-read it. Every mapping, amount and interval reproduced: the four self-bond owners, the same P-chain address in stake[].output.addresses, validationRewardsOwner and delegationRewardsOwner on all seven registrations, the 24–26 second intervals, and the delegation wallet spanning both identities.

Three things I can add.

A. The P-to-C address mapping is provable from the chain alone

Step 4 of the reproduction procedure resolves the mapping by opening each P-chain owner on flare.space. That works, but it makes a third-party site load-bearing for the identification. The mapping can be derived instead, with no external source: recover the secp256k1 public key from any transaction the C-chain account has signed (standard ECDSA public-key recovery from v, r, s and the signing hash), compress it, then take bech32("flare", ripemd160(sha256(pubkey))). This is the same derivation the official stake tool describes, run in reverse from public data.

Done for all four self-bond accounts:

C-chain account Recovered P-chain address Self-bond owner of
0x9d2f…2481 P-flare1gwds…j3v0 A — LwpT, 436a
0xDEBa…18dC P-flare1hwyq…4mcf A — QK6w, C3cw
0x65b2…e843 P-flare13hg2…dm53 B — QcDi, K8GP
0xcE62…76b6 P-flare10rcs…59hp B — Q3Mp

All four match the owners in section 1.3 exactly. The C-chain account that holds Sceptre’s pool roles and the P-chain account that owns the self-bond are the same key, provably, not merely the same row in a lookup table.

B. The withdrawal amounts carry through into the self-bond exports

Node names below use the report’s shorthand — the first four characters of the NodeID — and link to the corresponding self-bond registration. The report states the withdrawals as “approximately 20M FLR”. They are exact, and the exact figure is what makes the transfer traceable: each pool withdrawal has a distinctive amount above the round 20M, and the same figure reappears in the C-chain ExportTx that funds the corresponding self-bond.

Node Withdrawn from the sFLR pool Exported to the P-chain
QK6w 20,000,016.00 20,000,016.01
C3cw 20,000,000.05 20,000,000.01
LwpT 20,000,015.00 20,000,015.01
436a 20,000,001.30 20,000,001.01
QcDi 20,000,012.00 20,000,012.01
K8GP 20,000,000.06 20,000,000.01
Q3Mp 20,000,012.00 20,000,012.01

The whole-FLR figure matches in all seven cases, including the non-round ones — 20,000,016 for QK6w, 20,000,015 for LwpT, 20,000,012 for QcDi and Q3Mp. This is no longer two events close together in time; it is the same balance leaving the pool and arriving as the validator’s stake.

The C-chain export transactions, which complete the chain on the C-chain side of the P-chain imports already linked in 1.3:

Node C-chain ExportTx
QK6w pxuoEhVvLTsEdvQPu24uUqrac5M5EFcgT1hJfBE2qCCx9YHj
C3cw SiJcg9a2QtPfdLSgsyQfGvCmWnbDEb8iZCU7uBTLE5RS2J3uQ
LwpT J8i6rdg7jXa23JEBMStNMCHs8UVnh3pt1zFsUSM9u58Zyfr6o
436a rDhVxYL1irvQANKWxU84bHDa6NvDqEPkdvyKS9drZWDtoqBHm
QcDi uU2kQE3qCBQ4ZDJa2jSBxtgWeuyAHvk5rCpoLdKJxa1JKiiBz
K8GP 36RSbZdiu8L4JYh9QwXzANRofz3Dz7CHuhvQU5s5q5757JoQx
Q3Mp 2G4Ha9cex9rRAthY1YtQXyWitudgy33f5UL4xYi9hwMx5U4bD4

Each export page names the sending C-chain account from the table in section A, and its destination is that same key in C-chain bech32 form — C-flare1gwds…, C-flare13hg2… and so on. To read the raw bytes instead, call avax.getAtomicTx on /ext/bc/C/avax: the first 20 bytes of the transaction’s input are the exporting EVM address, the 8 bytes following it are the amount in nanoFLR.

C. Provider B has a fourth registered NodeID with no validator behind it

Beyond the three live Provider B nodes, 0xb70c…49df registered a fourth NodeID in the same batch on 2026-08-14 — 5XbN, in full NodeID-5XbNmzyxPNk3HNJj3iqv6NcBcqr6SzBaB — in this registerNodeId transaction. platform.getCurrentValidators returns no validator for it as of 2026-08-31.

It is dormant, not active, so it does not change the seven-validator count. It matters for the remedy: a registry entry is the thing being asked for, and any deregistration order should name all four of Provider B’s registered NodeIDs, not only the three that are currently validating.

On every node the self-bond output and both reward streams belong to the Sceptre-controlled key. Capital, returns and risk sit with Sceptre; what is independent about the second identity is the name on the registration. Worth a separate look, because it is not what this proposal is about: funding a validator’s self-bond out of pooled depositor money is hard to reconcile with FIP.05’s treatment of the self-bond as the operator’s own stake.

PriceKraken is an FTSO provider and competes with both identities for the same reward pool. That is precisely why we re-derived this from the chain instead of endorsing a summary. On the evidence, we support the proposal and the remedy it asks for.

4

Much to read through and digest here. Proposal is thorough and establishes clear intent of circumventing rules.

Deleted comment history adds insult to injury as this implies the entity knew what they were doing.

I’d argue this proposal would 100% apply to Rome Blockchain Labs as they are the established protocol owner whereas “Sceptre” is merely the brand implicated by the on-chain evidence.

1 Like
5

The precedent set by allowing that many validators to remain active and controlled by a single entity is not good for the security of a decentralized network. We would support this proposal which should happen immediately if their second set of validators are not immediately removed.

1 Like
6

Sceptre has publicly acknowledged that they did circumvented the rules. They still have not made the corrective actions as stated in their blog. We should move forward with the vote.

1 Like
7

Since they still haven’t taken down the validators even after publicly acknowledging the issue and apologizing, I’m voting in favor of the proposal.

8

Sceptre has acknowledged publicly that they have broken the rules, so Flarebus will vote in favour of the proposal.

9

We support this proposal. Nothing to add, self explanatory.

10

FTSOCAN supports the proposal.

11

Posting on behalf of Burst Nodes as they sort out login issues-

## Additional evidence: the node cap, the seven minutes, and the /24

Pricekraken has already reproduced the transaction record, so I have not repeated that work. What
follows is new material, gathered from a Burst Labs archive node (C-chain and P-chain) plus the RIPE
and APNIC registries. None of it depends on Catenalytica, Flare Builders or flare.space.

A word on what it is aimed at. The defendants have an obvious answer available to this proposal, and
I do not think it has been addressed squarely yet:

Rotko is an infrastructure business with its own FTSO identity. Sceptre said in May it was
considering running its own validators. Sceptre contracted Rotko to host them and registered its
own identity. Two companies, two identities, one host. No rule broken.

Rotko Networks OU and Rome Blockchain Labs are, on the public record, distinct entities, and nobody
has produced a corporate link between them. So a finding that rests on inferring common control
between two named companies is the version of this proposal most likely to fail. Sections A to D
below are the four facts that the host-and-customer reading has to explain. “Why I am voting for it”
at the end sets out the finding I think survives it, which is about capital rather than corporate
structure.

—

### A. The protocol caps an entity at four nodes, and both identities sit exactly at the cap

EntityManager.maxNodeIdsPerEntity()

returns 4. It was set to 4 on 2024-09-09 in block
29,548,985 (tx

0x336192c907ed28ec3e9fce839c22dead6c95781853472af6770b1ee55f192ed2

) and has not
been changed since, so it was 4 throughout the period in question.

getNodeIdsOf()

today:

Identity Node IDs registered

0x7e74…63D3

(A) | 4 of a maximum 4 |
|

0xb70c…49df

(B) | 4 of a maximum 4 |

Both are full. Eight nodes is not something one registered entity can hold, at any point in this
timeline. Keep the cap in mind for section B, because it is per registered identity, not per
host. Nothing about Rotko’s rack capacity is limited by it.

### B. Provider B was created seven minutes after Provider A ran out of room

Provider A registered its node IDs in EntityManager on 29 May, 4 June and two on 6 July, reaching
four at 2026-07-06 07:28:58 UTC. The self-bonds followed on 15 July, 17 July, 29 July and finally
14 August. That last one is the interesting date, because it is the moment A became not just full on
registrations but fully bonded, with nothing left to grow into.

Time, 14 August 2026 UTC Event
05:21:04 ~20M FLR leaves the sFLR pool (section 1.3 of the proposal)
05:21:28

436a…78NR

, Provider A’s fourth and last node, starts validating. A is now 4/4 registered, 4/4 bonded |
| 05:28:40 | The wallet that becomes Provider B receives the first FLR of its existence: 1,250.223 FLR from

0xb46bb95e…ccac5

, tx

0x8ab3caa6357f678f5f629f6d770f496b8c5f932394c3ccdf26957e0e0cfd8853

|
| 05:29:18 to 05:29:56 | That wallet funds seven helper addresses in 38 seconds |
| 05:30:16 to 05:30:47 | It registers submit, submit-signatures and signing-policy addresses (

0x9d1bf87d…

,

0x07b7b1ef…

,

0x2322aab2…

) |
| 12:12:48 to 12:13:02 | It registers four node IDs in 14 seconds (

0x3d80e362…

,

0x78d80bc6…

,

0xef3e6fe0…

,

0xaf22ceba…

), immediately filling its own cap |

Seven minutes and twelve seconds. Provider B’s identity address has no history of any kind before
05:28:40 on 14 August: no balance, no counterparty, nothing. It was created in the gap between
Provider A running out of capacity and lunchtime the same day, and the first thing it did was take
four more slots.

I want to be careful about what this does and does not show. It does not by itself prove common
ownership, and it is not offered as though it did. Ownership is established by the self-bond
evidence in section 1.3, which pricekraken has already reproduced. What the seven minutes shows is
intent: whoever stood up Provider B was reacting to a limit reached minutes earlier on a
different registered identity, which is only possible if they were watching both.
Every one of the five was first funded by 0xF76a23626c2527638b3EAF3d497a7c111F6D0ef9, which is
the same address that granted all four self-bond accounts their privileged sFLR deposit, withdraw
and instant-redeem-buffer roles on 15 July 2026. That address was itself first funded by
0xdf0BB66416aE4e07f7F8ade1d66fCa5576d4f386, the account that took DEFAULT_ADMIN_ROLE on the sFLR
contract at deployment on 2024-05-08. The role grants have never been revoked: all four accounts
still hold those rights today.

The first row is the one to look at. A single account delegates 230M FLR to a Provider A node and
230M FLR to a Provider B node.

The exclusivity test. Sceptre operating a liquid staking pool that delegates to validators is
its ordinary business, so “the pool delegates to Provider B” would prove nothing on its own. The
question is whether these five accounts behave like a pool spreading stake across the network. They
do not. I walked the delegator set of all 179 network validators. Those five accounts have
1,525,079,584 FLR delegated in total, of which 1,495,079,584 FLR, or 98.03%, sits on the seven
validators of Providers A and B.

The entire remainder is 30,000,000 FLR on NodeID-4Ytvw…g7JBF at 37.27.63.222, a validator with 137
distinct delegators, an 8.5M self-bond and a 15% fee. That is a useful control, because it shows what
an arm’s-length delegation from this pool looks like, and it looks nothing like the other 98%.

In summary

  • The cap. maxNodeIdsPerEntity() is 4 and has been since September 2024. Both identities hold
    exactly four node IDs. Eight validators is not something one registered entity can hold, so the
    eight can only exist across two registrations.
  • The seven minutes. Provider B’s identity address received the first FLR of its existence
    7 minutes 12 seconds after Provider A’s fourth and last node became a funded validator, and took
    four more slots the same day. The cap binds registered identities, not hosts, so an independent
    customer of Rotko had no reason to key off it.
  • The /24. All eight registered node IDs are live peers in 160.22.180.0/24, originated by
    AS142108, APNIC registrant Rotko Networks OU. Of 453 IPv4 Flare peers, exactly eight sit in that
    block and all eight are these. No unrelated operator is hosted there.
  • The stake. The seven validators carry 1,495,079,584 FLR of delegated stake from exactly five
    accounts, every one first funded by the same address that granted the four self-bond accounts their
    privileged sFLR roles. One of those accounts delegates 230M to a Provider A node and 230M to a
    Provider B node. Across all 179 network validators, 98.03% of what those five accounts have staked
    sits on these seven.
  • And from the original proposal, which pricekraken and I have both now confirmed by independent
    routes: every one of the seven self-bonds, and both reward streams on every node, belong to those
    same privileged accounts.

Why I am voting for it

The proposal asks the Management Group to find that one entity operates two registered identities.

The fact that does not depend on it is the capital. Every one of the seven 20M FLR self-bonds came
out of the sFLR pool, and on every node the self-bond output and both reward streams belong to
accounts holding that pool’s privileged roles. That leaves two readings and no third:

  1. One entity operates both identities, which is the charged violation; or
  2. Provider A’s registration carries no capital of its own, and the economics of its four validators
    belong entirely to someone else.

Both engage what the one-identity rule is for. The rule exists so that
concentration is visible to delegators and to this group, and here is the concentration it is being
used to obscure. On VoterRegistry weight for epoch 429, Provider A is rank 3 of 100 at 3.059%
and Provider B is rank 10 at 2.141%. Combined, 5.200%, against 3.502% for Bifrost Wallet,
the largest single provider on Flare. Registered as one identity, as the rule requires, this operator
would be the network’s largest voter by roughly 48% over second place. Split in two, it reads as a
third-placed provider and a tenth-placed one, and nobody looking at either in isolation sees a
participant of that size.

One thing in fairness, which I would rather state myself than have produced against us. The two
identities’ price submissions are not correlated. Over voting rounds 1,444,328 to 1,444,447 they
agree on 3.95% of comparable feed cells, 294 of 7,440, which is below the baseline for unrelated
providers. Provider A’s closest peer is an unrelated provider at 13.33%. They are demonstrably
running different price pipelines, and that is the best fact the defence has. It is also beside the
point. The proposal alleges no copied prices and should not, because the charge is ownership.
Separate code is not separate capital, and nothing about running two price stacks changes who owns
seven self-bonds.

So: chill both, on a finding framed on ownership of the validator capital and reward rights rather
than on common control of two companies. Same harm, much lower evidentiary burden, and far less to
argue about.

How to reproduce

Everything above comes from a Flare node and two public registries.

  1. Node cap and registrations. On EntityManager 0x134b3311C6BdeD895556807a30C7f047D99DfdC2,
    call maxNodeIdsPerEntity() and getNodeIdsOf(voter) for each identity. For the history, filter
    NodeIdRegistered(address indexed voter, bytes20 indexed nodeId) on the voter topic. The cap’s
    own history is the MaxNodeIdsPerEntitySet event.
  2. Node IDs to IPs. info.peers on the /ext/info endpoint of any Flare node returns nodeID and
    publicIP for every peer. To go from the bytes20 in EntityManager to the NodeID- string, base58
    encode the 20 bytes with a 4-byte SHA-256 checksum appended.
  3. IP to operator. https://stat.ripe.net/data/network-info/data.json?resource=160.22.180.201
    gives prefix and origin ASN; https://rdap.apnic.net/autnum/142108 gives the registrant.
  4. Weights and ranks. VoterRegistry 0xA480457953Af3583E54DCd630b219353B8FC9Af7,
    getRegisteredVoters(429) then getVoterRegistrationWeight(voter, 429) for each.
  5. Delegators. platform.getCurrentValidators with a single nodeID in nodeIDs returns the
    full delegators array. Note the gotcha: passing several nodeIDs at once, or none, returns
    delegatorCount and delegatorWeight but omits delegators entirely. One call per node is what
    the exclusivity scan needs.
  6. P-chain to C-chain. AddressBinder 0x57c5149c6cdC7bA379aFAe28e6497Ae26c252738,
    pAddressToCAddress(bytes20), taking the 20 bytes from the bech32 payload of the P-chain address.
    This is a third route to the mapping in section 1.3, independent of both flare.space and
    pricekraken’s key recovery, and it agrees with both.
  7. Role grants. RoleGranted and RoleRevoked on the sFLR contract
    0x12e605bc104e93B45e1aD99F9e555f659051c2BB, over the full block range.
12

Thanks for putting together such a comprehensive analysis. I don’t understand why Sceptre hasn’t shut down the 2nd entity already, despite acknowledging the error that’s been made. I support the proposal, and will vote in favour of it.

13

The part I don’t understand is where they publicly state they’ve already come in to compliance when they clearly have not and continue to accrue rewards on the second set that should not be running.

14

We vote for, it’s self explanatory.

16

Mirsflr agrees. The rules are clear and should apply equally to everyone.

17

Sceptre currently can’t register on the forum, so they’ve posted their response and remediation status on their blog instead:

Sceptre response and remediation status

  • Writer: Joel Monteiro

Joel Monteiro

  • 20 hours ago
  • 2 min read

Due to the current inability to register on the Flare Forum, we are posting Sceptre’s response and remediation status on our blog.

Sceptre response and remediation status

The recent post raises three issues regarding our validator infrastructure. Here is what happened, what has already been done, and the schedule for the remaining steps.

Background. Following the fee structure introduced by FIP.16, Sceptre engaged Rotko Networks as an infrastructure operator to run validator nodes, a decision made to protect depositor yields and operational sustainability. Rotko operates under contract to Sceptre. Sceptre is accountable for its vendors’ compliance with Flare governance, and we accept that accountability without qualification.

The FIP.05 issue. A second provider organization with three validator nodes was established. This violates the one-identity limit under FIP.05. That is a compliance failure and it is ours. Every registration was executed through public transactions under identifiable addresses; nothing was concealed and no attempt was made to gain influence or rewards beyond what a single compliant identity would hold. Wind-down began the day the issue was raised.

The provider listing. Although the second identity was not registered, nor is registration mandatory, no material steps were taken to conceal its relationship with Sceptre.

Remediation and wind-down

Surviving identity: 0x7e74D30eF4dd811830118645633a9471f6cc63D3

NodeID-LwpTuHwv3BdGhT1y7RcPY1t4rx494uExo

NodeID-436aEkcwxBo9Z5Ud9Rr7mWEgHnjDu78NR

NodeID-QK6w1Ryp8kfgPBYSyNgHbRTjEhYfLkyBE

NodeID-C3cwgDrgNHRCpqd7GGBZ6qhcBFNmKh3a3

Winding down: 0xb70c6987626A96df66C9068bd10b84Ecb8e949df

NodeID-QcDi1guqnomkd4zX9wZGqPpyUjZVVbY8

NodeID-K8GPcA8hRBYHBUE62TfJXVvc9XfrbiXMq

NodeID-Q3Mp12xwbqm9Byj46mxawQtKaETY1vJs

NodeID-5XbNmzyxPNk3HNJj3iqv6NcBcqr6SzBaB — registered to contract, never staked/active

Ceased on 2026-09-01: all listing and whitelisting activity, all new registrations, and acceptance of any new delegations to the second identity.

What continues, and why: 3 third-party delegators with 575 million FLR are protocol-locked to the second identity’s nodes until expiry dates fixed at registration. Their stake cannot move before expiry. Halting the nodes today would not release anyone’s funds; it would only forfeit the remaining rewards of locked users. The second identity therefore continues the minimum operations required for those delegators to earn until the final lock expires on 2026-09-16.

Sceptre earns nothing from this window . 100% of provider-side rewards accrued by the second identity from 2026-09-02 onward will be passed to depositors, verifiable at 0x12e605bc104e93B45e1aD99F9e555f659051c2BB.

On 2026-09-16 the second identity will be deregistered and permanently cease operation. Confirmation and TxIDs will be posted in this thread. No replacement address, brand, nominee, or successor arrangement will be created.

Should the Management Group direct an earlier shutdown notwithstanding the locked user stake, Sceptre will comply. We ask only that the decision be made with the figures above in view, since the cost falls on delegators, not on Sceptre.

We will post confirmation of final deregistration with TxIDs once complete. The Management Group can reach us directly at any point for anything further.

18

Sceptre has posted their response.
On the subject of shutting down immediately the conditions for remediation presented have been unambiguous,
The conditions of the proposal still stand.
IPMG will proceed to a quorum vote for sentiment to move forward with the official chill vote.
If anybody has anything further to add or any interjection or conditional change to be debated now would be the time.

1 Like
19

Without commenting on the chill vote itself, we’d just like to raise an important technical point to the discussion. Some entities proposed that validators should be shut down immediately however, from pure network security and healthiness perspective, such a move would actually harm the network by removing a substantial stake and introduce slowness and perhaps even an occasional block gap. Alternatives that do not remove active stake are preferable.