HSP-007 Execution: MPC Node Infrastructure Financing Program

This thread serves as the canonical source for all program execution updates related to the MPC Node Signer Program approved under HSP-007.

Here, we will publish all operational outputs of the program, including:

  • Monthly Performance Reports
  • Monthly Payout Reports
  • Eligible Node Registry updates
  • Payment execution records
  • Any relevant program disclosures or adjustments

All reporting follows the processes and methodology defined in the original proposal:
https://gov.houseofstake.org/proposals/24

This thread is intended to ensure full transparency, auditability, and ease of reference for the community. All stakeholders are encouraged to use this thread as the primary point of review and discussion for program execution.

For any disputes or clarifications, please refer to the challenge and dispute process outlined in the Program Charter and the proposal.

1 Like

Program Charter

This Program Charter defines the operational framework for the MPC Node Infrastructure Financing Program as approved in HSP-007.

For full context, rationale, scope, and parameter definitions, please refer to the original proposal. This Charter focuses on how the program is executed in practice, ensuring transparency, predictability, and reproducibility.

1. Program Design

The MPC Node Signer Program provides ongoing incentives for eligible node operators contributing to MPC infrastructure.

Eligibility & Participation

  • Participation is limited to nodes meeting the requirements defined in HSP-007.
  • The program enforces a maximum node cap of 21 nodes.
  • An Eligible Node Registry will be maintained and published monthly in this thread.

Compensation Model

  • Node operators are compensated on a monthly basis (in arrears).
  • Compensation is determined using the methodology defined in HSP-007, including:
    • Fixed floor and cap mechanics
    • A non-discretionary calculation model
  • All calculations are deterministic and reproducible by third parties.

Price Reference Methodology

Token price inputs follow the exact methodology defined in HSP-007:

  • Step 1:

    • Determine the 180-day trailing arithmetic average of NEAR/USD
    • Source: CoinMarketCap daily close at 0:00 UTC
    • Window: 180 calendar days ending on the last day of the service month
  • Step 2: Calculate the NEAR payment

    • If 180d_avg ≀ $3.00 β†’ payment = 4,600 NEAR
    • If 180d_avg > $3.00 β†’ payment = $13,800 / 180d_avg
  • Step 3: Apply SLA adjustment

    • Monthly Uptime β‰₯ 99.0% β†’ 100% of payment
    • 95.0% ≀ Monthly Uptime < 99.0% β†’ 50% of payment
    • Monthly Uptime < 95.0% β†’ 0% (full forfeiture)
  • Monthly uptime will be tracked and reported on a monthly basis in this thread.

  • This methodology is fixed and cannot be altered without governance approval.

Example scenarios (per node, per month):

180d Avg Price | NEAR Payment | USD Equivalent

$1.50 (floor) | 4,600 NEAR | $6,900

$2.25 | 4,600 NEAR | $10,350

$3.00 | 4,600 NEAR | $13,800

$4.50 | 3,067 NEAR | $13,800

$6.00 | 2,300 NEAR | $13,800

SLA Requirements

  • Node performance is evaluated against SLA criteria defined in the proposal, and the SLA agreement signed by House of Stake Foundation and node operators.
  • Payout eligibility is strictly tied to SLA compliance.
  • Failure to meet SLA requirements results in reduced or forfeited compensation, per defined rules.

2. Operations & Process

Each cycle corresponds to a calendar month. Reporting and payments are executed within a defined period after month-end (as operationally feasible).

  1. Monitoring
  • Node performance is continuously monitored by NEAR One.
  1. SLA Evaluation
  • At the end of each period, node performance is evaluated against SLA thresholds.
  1. Report Publication (5th)
  • Performance report (current cycle, e.g. April 1–30 for report on May 5th)
  • Payout report (finalized cycle, e.g. March 1–31 for report on May 5th)
  1. Challenge Period (5th–12th)
  • Operators review and raise disputes for current cycle if needed.
  • HoS will start the payout process once the challenge window has closed, and will compensate only for services that remain unchallenged or have had their challenges resolved.
  1. Finalization & Compliance (12th–18th)
  • Disputes resolved
  • AML checks completed
  1. Payment Execution (13th–20th)
  • Payments are executed based on finalized results.

3. Transparency & Reporting

Transparency is a core principle of the program.

Monthly Public Report

Each cycle, the following will be published:
a) Performance Report (current cycle, e.g. April 1–30 for report on May 5th):

  • Eligible Node Registry
  • Per-node SLA performance results
  • Detailed payment calculations, cap triggered or not
  • Price inputs used in calculations

b) Payout Report (finalized cycle, e.g. March 1–31 for report on May 5th)

  • Eligible Node Registry
  • Challenges and resolutions
  • Final payout amounts

Reproducibility

  • All data and formulas used are publicly available.
  • Any third party should be able to independently verify:
    • SLA outcomes
    • Payment calculations

Data Integrity

  • Reports are considered the canonical record of program execution.
  • Any corrections or amendments will be clearly disclosed.

4. Dispute & Challenge Process

A structured process is in place to handle disputes regarding SLA evaluation or payment calculations.

Submission

  • Node operators may submit a dispute via the this forum.
  • Disputes must:
    • Specify the precise dates, times, and nature of the alleged outages or calculation discrepancies
    • Be published at this thread replying to the respective monthly report

Scope of Disputes

Valid disputes may relate to:

  • Incorrect SLA evaluation
  • Incorrect data inputs
  • Calculation errors

Disputes cannot challenge:

  • The predefined methodology
  • Fixed parameters established in HSP-007

Resolution

  • Disputes are reviewed by program administrators in coordination with relevant stakeholders.
  • Resolution follows the process defined and agreed between node operators and the House of Stake Foundation.

Timeline

  • Disputes must be raised within a 7-days window after report publication.
  • Late submissions may not be considered.

Final Notes

This Program Charter is designed to:

  • Ensure predictable and rule-based execution
  • Eliminate discretionary decision-making
  • Enable full transparency and auditability

All program parameters, constraints, and governance authority are defined in HSP-007, which remains the single source of truth for the program.

1 Like

March 2026 – Performance Report

Reporting Period: March 1 – March 31, 2026

1. Summary

  • Total Eligible Nodes: 8

  • Reported Uptime Range: 99.1% – 100.0%

  • Operators at 100% Uptime: 7

  • Cap Triggered: Floor

  • Total Payout: 36,800 NEAR |

  • Challenge period starts: April 9, 2026 (23:59 UTC)

  • Challenge period ends: April 16, 2026 (23:59 UTC)


2. Eligible Node Registry

Operator Name Node Address NEAR Account Status
Near One https://multichain-mainnet-0.nearone.org n1-multichain.near Active
Blacksand https://multichain-mainnet-0.near.blksnd.xyz blacksandtech.near Active
Luganodes https://near.mpc.lgns.net mpc-lgns.near Active
Aurora https://multichain-mainnet.aurora.dev multichain-mainnet-aurora.near Active
Staking4all https://multichain-mainnet-0.staking4all.org near-mpc-staking4all-01.near Active
Node Monster https://near.node.monster nodemonster.near Active
Everstake http://nearmpc-mainnet.everstake.one everstake-mpc-1.near Active
Stakin http://near-mpc-mainnet-1.stakin-nodes.com stakin-mpc.near Active

3. Per-Node SLA Performance Results

Operator Name NEAR Account Uptime % SLA Threshold Met
Near One n1-multichain.near 99.1 YES
Blacksand blacksandtech.near 100.0 YES
Luganodes mpc-lgns.near 100.0 YES
Aurora multichain-mainnet-aurora.near 100.0 YES
Staking4all near-mpc-staking4all-01.near 100.0 YES
Node Monster nodemonster.near 100.0 YES
Everstake everstake-mpc-1.near 100.0 YES
Stakin stakin-mpc.near 100.0 YES

4. Payment Calculations

Operator Name NEAR Account Performance Factor Final Payout USD Value
Near One n1-treasury.sputnik-dao.near 100% 4,600 NEAR 7,824.50 USD
Blacksand blacksandtech.near 100% 4,600 NEAR 7,824.50 USD
Luganodes mpc-lgns.near 100% 4,600 NEAR 7,824.50 USD
Aurora multichain-mainnet-aurora.near 100% 4,600 NEAR 7,824.50 USD
Staking4all near-mpc-staking4all-01.near 100% 4,600 NEAR 7,824.50 USD
Node Monster nodemonster.near 100% 4,600 NEAR 7,824.50 USD
Everstake everstake-mpc-1.near 100% 4,600 NEAR 7,824.50 USD
Stakin stakin-mpc.near 100% 4,600 NEAR 7,824.50 USD

5. Price Inputs Used in Calculations

Metric Value Source Timestamp
180-day Average NEAR Price 1.7010 NEAR CoinMarketCap daily close at 0:00 UTC 3/31/2026
Applicable Floor / Cap Threshold 4,600 NEAR As defined in HSP-007 3/31/2026
Cap Triggered Floor Derived As defined in HSP-007

6. Supporting Evidence

  • Uptime source snapshot: Grafana
  • Source file: operator-uptime.html

7. Notes & Disclosures

  • This report reflects the operator uptime data provided for March 2026.
  • SLA pass/fail determinations and payout amounts should be completed using the methodology defined in HSP-007.
  • This report is subject to the program challenge process before payout finalization.

Update 2026/04/13:

We found a small calculation error. The average USD price is $1.7010, not $1.6414 as originally posted. Our updated price source is CoinMarketCap daily close at 0:00 UTC.
This update does not affect node payouts; it only changes the reported USD value.

1 Like

Thank you so much for this very detailed performance report, @AK_HoG ; I can tell that there was a lot of work put into complying it. I noticed that HOT was not included in the March performance results, eventhough they were one of the nine current MPC node operators . Did they not meet the minimum of 95.0% uptime to be eligible to receive the March payout?

HOT team decided to step down from their operator role due to their internal reasons. Since they are no longer a part of the network they were not included into the report.

1 Like

Awesome, thanks for the update and clarification about HOT.:folded_hands: