Front Matter

hsp: HSP-007 
title: Establish a Sustainable MPC Node Infrastructure Financing Program Funded via Protocol Emissions
description: Establishes a sustainable incentive program to fund MPC nodes supporting NEAR Intents using protocol emissions.  
author: Sal Ternullo, Kendall Cole  
discussions-to: https://github.com/houseofstake/proposals/blob/main/HSPs/hsp-007.md  
status: Voting 
track: Decision  
type: Simple Majority  
category: Economic Governance   
stakeholders: MPC node operators, NEAR Intents developers, Chain Signatures users, NEAR token holders  
created: 2026-01-29 
requires: HSP-001

Abstract

This proposal establishes a MPC Node Infrastructure Incentive Program funded via protocol emissions accrued to create infrastructure incentives and is governed by House of Stake. The program provides performance-based monthly compensation to up to 21 MPC node operators supporting NEAR Intents and Chain Signatures. Compensation is NEAR-anchored at a fixed rate per node, with payments executed on-chain from House of Stake wallets following off-chain SLA validation and calculations.

The program transitions MPC infrastructure funding from discretionary grants to a transparent, governance-controlled mechanism aligned with NEAR’s emissions mandate. Payments are binary and SLA-gated, ensuring emissions-backed funding is issued only for delivered performance.

Context

NEAR Intents and Chain Signatures rely on MPC nodes to provide secure, distributed cryptographic signing across chains. These nodes are core production infrastructure that underpin NEAR’s intent-based execution model and multi-chain strategy.

Today, MPC node operations have been supported primarily through off-chain grants. While grants enabled early adoption, grant-based funding is discretionary and time-limited, which is structurally misaligned with permanent protocol infrastructure. As House of Stake assumes governance responsibility for protocol emissions allocation, MPC infrastructure should transition to a transparent, rule-based program governed by token holders. This proposal establishes that transition without modifying protocol parameters, smart contract logic, or emissions rates.

The MPC nodes powering Chain Signature are critical infrastructure enabling NEAR Intents which have proven exceptional product market fit with over $10B in volume processed to date. The system leveraging MPC nodes is also extensible to other use cases including privacy which are on the roadmap for NEAR Protocol in 2026. This proposal represents a significant and important milestone in establishing a sustainable funding mechanism from protocol emissions for core infrastructure.

Problem

MPC nodes that secure NEAR Intents and Chain Signatures lack a stable, governance-approved funding mechanism appropriate for mission-critical protocol infrastructure. Reliance on discretionary grants creates operator uncertainty, inhibits scaling to the target operating state, and misaligns long-term infrastructure incentives with emissions governance.

Without an emissions-backed, SLA-gated program, the protocol risks degraded reliability, slower scaling of the MPC set, and reduced resilience and decentralization of signing infrastructure.

Approach

The MPC Node Infrastructure Support Program operates with retrospective monthly payment based on adherence with performance requirements. This structure ensures protocol emissions are only distributed for delivered service, incentivizes continuous SLA compliance, and provides predictable economics for scaling MPC infrastructure as NEAR Intents and Chain Signatures mature.

Maximum Monthly Payment: 4,600 NEAR per qualifying MPC node, distributed monthly in arrears for each month of the program term (using a trailing 180-day average NEAR/USD price, where $1.50 represents the floor economic scenario, corresponding to approximately $6,900 per node per month: $5,750 infrastructure, monitoring, and maintenance costs plus a 20% margin). This scenario represents the floor price and economics for MPC nodes. It should be clearly noted that the prior discussions in the forum have run to ground the pure hardware costs on a monthly basis (in the lowest cost available provider) arriving at a minimum of $4,500 USD to operate 3 nodes (production mainnet, back-up mainnet, and testnet) required per provider without contemplating software costs or human resource costs. This program will be revisited annually in context of changing cost structures across the hardware landscape and integration support for Chain Signatures.

Cap on Program Incentives: Similarly, this proposal provides a structure which caps the USD equivalent upside at $3 as NEAR prices rise materially to protect the protocol from overpaying for MPC nodes. In this scenario, MPC nodes provide a profitable economic model with a margin of up to ~$8,000 USD per month relative to infrastructure, monitoring and maintenance costs of $5,750 USD. The examples of calculations for a Floor, Actual and Cap scenario are enumerated in Exhibit 1. Conversely, this proposal introduces a floor mechanic at a price of $1.50 USD per NEAR token to ensure that the MPC node operators are not operating at a loss.

Compared to alternatives:

• Continue grant funding: simple short-term, but discretionary and mismatched to permanent infrastructure.
• Purely market-based/operator self-funding: risks underinvestment in reliability and slower scaling.
• Fully automated on-chain distribution: reduces human involvement but increases execution surface and governance change risk; this proposal keeps execution explicit while retaining on-chain transparency.

Benefits

• Establishes predictable, governance-controlled funding for critical MPC infrastructure.
• Ensures emissions are distributed only for delivered, SLA-verified performance.
• Aligns MPC operator incentives with protocol reliability and decentralization goals.
• Protects the protocol from overpayment during periods of significant NEAR price appreciation.

Limitations

• Requires monthly operational verification and reporting overhead.
• NEAR-denominated payments expose operators to price variability below the cap.
• Changes to compensation parameters require formal House of Stake tokenholder vote and cannot be adjusted dynamically.

End-to-end Value Hypothesis

This proposal delivers complete, standalone value by ensuring that MPC nodes supporting NEAR Intents and Chain Signatures are funded through a transparent, governance-approved mechanism aligned with protocol emissions policy.

By defining eligibility, compensation, enforcement, and administration within a single proposal, the program removes reliance on undefined follow-up actions or discretionary decision-making. All components necessary to realize the intended value, funding source, payment logic, performance gating, and governance authority, are explicitly specified.

Objective

• Allocate a maximum 4,600 NEAR per MPC node per month (at a floor price of $NEAR = $1.50) to cover infrastructure, monitoring and maintenance costs with a 20% incentive margin.
• Transition MPC node funding from discretionary grants to House of Stake–governed protocol emissions.
• Provide positive expected profit for MPC node operators to incentivize long-term participation.
• Enforce service requirements to realize gated payments so emissions are paid only for delivered performance.
• Support scaling to the target state of 21 MPC nodes without changing per-node economics.

Outcome

• Up to 21 MPC nodes are funded and operational, within a maximum allocation, with funding sourced from protocol emissions held in treasury.near.
• Monthly payments executed in arrears.
• Monthly public reporting by proposal authors via House of Stake proposal updates.
• Emissions slashed for nodes failing to meet SLA requirements in any month (see Exhibit 2).
• Governance-ready data to reassess node count, margins, and pricing assumptions.

Dependencies

• Existing MPC node infrastructure supporting Chain Signatures and Intents (currently live; 9 nodes noted in current state).
• Existing monitoring + performance evaluation process (“NEAR One” monitoring process referenced).
• Service Level Requirements framework (Exhibit 2) establishing 99.0% and 95.0% Monthly Uptime thresholds and forfeiture mechanics.
• Treasury execution capability from House of Stake to perform on-chain transfers.
• Governance forum challenge process allowing participating MPC providers to contest SLA failures (Exhibit 2 procedure) in the Governance forum.

Key Performance Indicators (KPIs)

1. SLA Compliance Rate (Monthly): % of eligible MPC nodes achieving Monthly Uptime requirements (Exhibit 2).
2. Active MPC Node Count (Monthly): number of nodes funded (≤21) and number of nodes live.
3. Payment Integrity: % of months where payments match the approved payment formula and SLA outcomes.
4. Challenge/Dispute Incidence: number of governance-forum challenges filed and resolved per month.

Technical Specification

Compensation Formula

To protect the protocol from overpaying for MPC infrastructure during periods of material NEAR price appreciation, monthly compensation is subject to a USD-equivalent cap based on a $3.00 per NEAR reference price. See Exhibit 1 for example calculations.

Price reference: The NEAR/USD price used for monthly payment calculations shall be determined using a trailing 180-day arithmetic average calculated from a single, publicly verifiable price source being Coinmarketcap NEAR/USD as of 0:00 UTC. The averaging window (180 days), data source, and calculation methodology are fixed and shall be published as part of the Program Charter at launch. While the resulting average price updates monthly by design, no discretionary adjustments to the averaging window, data source, or calculation methodology are permitted during the program term. Any modification requires a new House of Stake governance proposal.

Eligibility

• Node must be an MPC node supporting Chain Signatures on NEAR mainnet.
• Maximum eligible nodes: 21
• Node Requirements: Hardware and software specifications are documented in NEAR’s MPC Github.

Performance Requirements

• Must meet Monthly Uptime Percentage (Exhibit 2).
• Failure: 50% of monthly rewards forfeited for uptime < 99.0%; 100% of monthly rewards forfeited for uptime <95.0%
• Challenge process: another participating MPC provider may submit a challenge on the governance forum with dates/times; claims may be rejected if incomplete/unsupported.

Payment Execution

• Program administrator validates SLA compliance and the applied cap logic (if triggered).
• On-chain transfers executed from House of Stake within 14 days after month-end
• Payments are not automated; each month’s transfer batch is explicitly authorized and executed.

Backwards Compatibility

No conflicts with existing protocol rules, contracts, or consensus mechanisms are introduced. The proposal establishes a new treasury distribution program and associated governance reporting. It is compatible with current operations and does not require protocol upgrades.

Security Considerations

This proposal does not introduce changes to protocol-level logic, consensus mechanisms, or validator operations. Risks are limited to correct application of the approved compensation formula, SLA validation, and treasury execution. These risks are mitigated through:

• A deterministic trailing 180-day price averaging mechanism and an explicit USD-equivalent compensation cap at $3.00 per NEAR
• Binary SLA-gated payments with full forfeiture on failure
• On-chain execution of transfers from House of Stake wallets
• Monthly public reporting of performance, calculations, and payments

No additional security risks have been identified.

Stakeholders

Screenshot 2026-01-29 at 2.41.26 PM1386×988 60.8 KB

Implementation Plan

Definition of Done includes:

• Publication of eligible MPC node list (up to 21 nodes)
• Confirmation of applicable SLA standards
• Activation of monthly payment and verification process
• On-chain payment execution from treasury.near and House of Stake wallets
• Monthly public reporting of performance and payments

Implementation steps:

1. Publish Program Charter: confirm node cap (21), average calculation logic to include floor and cap, and publish the monthly price reference methodology.

2. Publish Eligible Node Registry: list eligible MPC node addresses (up to 21).

3. Confirm SLA Reference: publish the authoritative SLA/service requirements (Exhibit 2) as the governing standard.

4. Establish Monthly Operating Cycle: payment deadline, SLA validation timeline, challenge window, and payment execution window.

5. Monthly Reporting: post monthly updates as HoS proposal comments including (i) eligible nodes, (ii) SLA pass/fail, (iii) payments made, (iv) cap triggered or not, (v) challenges and resolutions.

6. Annual Evaluation: The program will include an annual evaluation, starting at the end of Month 3, to address community feedback and ensure ongoing alignment with protocol needs. The evaluation will be led by Near One and reported publicly.
   Each evaluation will review:

• Cost assumptions and operational efficiency

• MPC node operators expectations and sustainability

• Program performance metrics and transparency to token holders

Based on the findings, there may be recommended program adjustments. Any program changes require a separate governance proposal. The program will not automatically sunset as part of this process, ensuring predictability for operators.

Milestones

Screenshot 2026-01-29 at 2.43.05 PM1312×1646 254 KB

Budget & Resources

This proposal is not requesting an upfront transfer of tokens to House of Stake. Calculated rewards will be remitted from Protocol Treasury to House of Stake Treasury on a monthly basis and then distributed to MPC node operators.

Cost Notes

• NEAR Price Assumption: NEAR-denominated payment amounts are calculated monthly using a trailing 180-day arithmetic average NEAR/USD price. The $1.50 reference represents the floor economic scenario used to illustrate baseline per-node economics. Actual monthly payments vary in NEAR terms as the trailing average updates, subject to the approved USD-equivalent cap at $3.00 per NEAR. The 180-day averaging window, price data source, and calculation methodology are fixed and may only be modified through a new House of Stake governance proposal. On a monthly basis, the calculated rewards will be distributed from the protocol treasury to House of Stake for distribution to MPC node providers.

• Maximum Per-Node Economics: The 4,600 NEAR monthly payment per node corresponds to approximately $6,900 USD per month, representing:

• ~$5,750 USD in average infrastructure, monitoring and maintenance costs, plus

• a 20% incentive margin to ensure positive expected maintenance costs are fully covered for MPC node operators.

• Hard Caps, Not Targets: The amounts listed above represent maximum allocations, not guaranteed spend. Actual monthly and annual emissions distributed may be lower.

• Any expansion or modification of funding levels requires a new House of Stake proposal.If no proposal changing these economic parameters is adopted, this mechanism will continuously renew.

Team & Accountability

Responsible: MPC node operators are responsible for operating, maintaining, and securing their respective MPC nodes in accordance with the required service-level requirements. Operators are responsible for meeting all uptime, availability, and performance requirements necessary to qualify for monthly payments under this program.

Program Administration: House of Stake, or a formally delegated operator acting on its behalf, is responsible for administering the program and authorizing off-chain payments in accordance with the approved pricing formula.

Accountable To: House of Stake governance and, ultimately, NEAR token holders. Program administration and outcomes are subject to public scrutiny through governance records, monthly reporting, and publicly disclosed payment outcomes.

Governance of Continuation

Unless modified or terminated by a subsequent House of Stake governance proposal, the program will continue operating under the same parameters in successive terms. House of Stake retains full authority to amend or discontinue the program at any time through governance or where such action is required for legal, operational, or risk-management reasons.

Conflicts of Interest

The authors of this proposal are involved in NEAR infrastructure development. Sal Ternullo serves as the CEO of SVRN which is a NEAR-focused treasury company while Kendall Cole serves as the Founder of Proximity Labs, which has previously provided grant funding to MPC node operators within the ecosystem. The proposed transition of MPC node incentives from Proximity-funded grants to protocol-level funding could reduce or eliminate the need for such grant funding going forward. SVRN has a clear and expressed intention to become an MPC node provider in the system."

Copyright

Copyright and related rights waived via CC0 1.0.

Exhibit 1- Scenario Calculation: Actual December close, Floor and Cap

image1600×173 68.4 KB

Exhibit 2

Service Level Requirements
SERVICE AVAILABILITY COMMITMENT.

1. Monthly Uptime Percentage. The MPC node provider will use commercially reasonable efforts to maintain a Monthly Uptime Percentage with respect to the MPC node provider infrastructure supporting the Node infrastructure. MPC node provider’s uptime support activities include:
   ( a ) 24/7 network-wide system monitoring;
   ( b ) 24/7 technical support for Critical Priority tickets; and ( c ) response to platform-level issues and upgrades.

2. Monthly Uptime Percentage Calculation.
   2.1. “Monthly Uptime Percentage” means the percentage of total minutes in a calendar month during which the [production environment of the Services] is operational and available, as measured and determined solely by Provider using its monitoring tools and logs.

The Monthly Uptime Percentage is calculated as:

Monthly Uptime Percentage =
[(Total Minutes in Month – Unexcused Downtime) / (Total Minutes in Month)] × 100

Where:
“Unexcused Downtime” means the number of minutes during the month when the Services were unavailable, excluding Excused Downtime.
“Excused Downtime” means time when the Services were unavailable due to ( a ) scheduled maintenance, ( b ) emergency maintenance, or ( c ) an Exclusion.

2.2. MPC node provider will use reasonable efforts to notify Client of scheduled and emergency maintenance and schedule maintenance during off-peak hours.

1. Foregone Rewards. If MPC node provider fails to meet the Monthly Uptime Percentage commitment in a given calendar month, and such failure is not the result of an Exclusion, as described in Section 5, the Protocol will be eligible to forgo payment of rewards as set forth in the following table, subject to requesting such Service Credit in accordance with Section 4. All Forgone Rewards will be calculated based on the actual Fees payable for the impacted month.

2. Forgone Rewards Procedure. In the event there is an uptime and service issue, another participating MPC node provider in the network can submit a challenge citing the specific dates and times of the alleged outages to the House of Stake governance forum. MPC node provider reserves the right to reject incomplete or unsupported claims in its reasonable discretion.

1. Performance Exclusions. MPC node provider shall not be responsible for system downtime, degraded performance or other failure that is the result of resulting from:
   ( a ) Protocol software, or network configuration;
   ( b ) any third-party system or technology not within MPC node provider’s direct control;
   ( c ) a Force Majeure Event; or
   ( d ) suspension or restriction of Services due to Client non-payment, compliance violations, or misconduct under the Agreement (each, an “Exclusion”), and MPC node provider will have no obligation to issue Service Credits to the extent that a failure to meet the monthly uptime percentage is the result of an Exclusion.

Exhibit 3- MPC Node Hardware Requirements

The following hardware specifications and cloud provider recommendations apply to all MPC node operators participating in the network following the upcoming upgrade to the Trusted Execution Environment (TEE) MPC architecture.

Hardware Requirements

• CPU: 5th Gen Intel Xeon Scalable or Intel Xeon 6 (TDX-enabled)

• CPU cores: 16 or more

• Memory: 64 GB*

• Disk: 1 TB or larger NVMe SSD (or equivalent performance)

• BIOS: must have TDX support

* At least one DIMM must be installed in slot 0 of each memory channel. All memory channels must be symmetrically populated.

Networking

• Firewall: allow inbound traffic on port 80 (MPC) and port 8080 (web interface)

• IP address: a public static IP is required

Cloud Providers

The following cloud providers have been verified to offer hardware configurations compatible with TEE deployment. Other providers may also be capable of meeting these requirements. We recommend confirming TDX support with your existing provider before migrating to a new one.

• OVHcloud.com

• PhoenixNap.com

• OpenMetal.io

• Hivelocity.net (will require a custom configuration)

• DigitalOcean.com

• Cloud.Google.com

Alternative Hosting Option

Server colocation remains a viable option at any data center that offers colocation services, provided that the hardware meets the requirements listed above.

Additional Information
Refer to the Intel Hardware Selection page for additional information.

I’m in support of this proposal. Just a few follow up questions:

The proposal states that the mechanism “continuously renews” unless modified by a new governance proposal. Would the authors consider a fixed authorization term (e.g., 12 months) with an explicit renewal vote to preserve periodic governance consent and cumulative performance review?

The proposal caps the program at 21 MPC nodes. What observable metrics (latency, geographic distribution, fault tolerance, volume throughput) would justify proposing an increase or decrease in this cap in future governance cycles? I know you mentioned the math and modeling checked out when we were on the HoS governance call but I feel that understanding how these metrics affect the network would help the community better assess the monthly reports.

I welcome this proposal. I do however have some small questions:

- Is the current NEAR MCP architecture capped to 21 nodes? What happens if we were to onboard more than 21, would eligibility for rewards be FCFS or will it be based on performance?

- There’s many stakeholders within HoS. Who within HoS do you think should be the program administrator?

- Will there be a public dashboard for community members to have a look?

Thank you for the note Othman, glad to hear that you are supporting.

We debated framing this on a defined term basis but ultimately given the criticality of the infrastructure we concluded that it was best to make this proposal continuous. Please keep in mind that a future HoS vote can modify the economic terms or eliminate the program altogether.

The current cap of 21 nodes is based on comparables for distributed signing systems with a bar that exceeds the most distributed today in the market. This was also designed in context of the total cost that the protocol should pay for the infrastructure to prevent a scenario where the spend exceeds.

In Exhibit 1 there is an example of the economic calculations for three scenarios, while in Exhibit 2 there are defined SLA requirements with related observable metrics.

Thank you for the feedback and support. Please find responses below to the questions you raised all of which are good.

1.) The system itself can scale beyond 21 MPC nodes but there becomes a question regarding the point of diminishing returns from a security / resiliency perspective relative to economic cost to ensure a viable mechanic for the providers.
2.) On the program administration point, there are a number of key stakeholders playing different functions in administering the program which are outlined in the RACI chart

3.) In the early days, we will be providing posts on the governance forum that provide reporting but are certainly open to building tools and dashboards in the future.

Strong support for this proposal

This is exactly the kind of proposal that House of Stake was built for.

Transitioning critical protocol infrastructure from discretionary grants to a transparent, governance-controlled funding mechanism is precisely what emissions governance should be doing.

1. As an infrastructure provider, we’d like to know more details about $6000 per month infrastructure cost. That seems extremely expensive even with failover nodes and separate monitoring nodes. To support this proposal, we need a clear breakdown from the current operators to justify the costs.

2. The payment should be calculated in USD. The 180 trailing price doesn’t make sense. We have intents to convert the monthly payment into USDC or another stablecoin. Node operators should receive the infra cost in USD, while rewards can stay in NEAR if they chose so.

Thanks for the comment and feedback. In contemplating the run-rate USD cost of the infrastructure, monitoring and management we’ve scope out the following components which compose the $6k run-rate average cost:

Hardware & Infrastructure

- Procurement of dedicated confidential-compute (TDX) enabled servers

- Enterprise network security infrastructure (firewalls, etc)

- Redundant deployment across physically separate environments

Software, Security & Licensing

- Network firewall and security licensing

- Monitoring and alerting

- Endpoint and OS-level protection

Deployment & Configuration

- Secure physical rack installation and cabling

- Virtual environment setup and hardening

- MPC software installation, validation, and testing

Ongoing Operations & Support

- Continuous monitoring and incident response readiness

- OS and security patching

- Health checks, maintenance, and uptime management

The actual timeline of USD cash requirements depends on whether hardware is purchased or rented.

On point 2, I do appreciate your perspective with regards to the USD / USDC payment for cost coverage with rewards in NEAR but the proposal is directed towards the utilization of emissions which are in the form of NEAR.

Happy to discuss either or points further.

Assuming 3M of total emission that goes to treasury.near based on the current inflation rate. The proposal is looking to allocate 1.2M towards MPC operations. That’s a huge allocation and requires extensive research for a proper decision making

In order to justify not only the cost, but the proper distribution the operation and selection of MPC nodes has to be public for stakeholders to decide whether it’s fair.

The proposal in the current state is looking to be other way around. First secure the money, then decide on who (node operators) and how (undefined or private) the funds or used.

Currently we (the NEAR stakeholders) don’t know who are the MPC node operators. We also don’t know what are the requirements to operate an MPC node, e.g. hardware/security/software.

So there are question:

• Can anyone become an MPC operator to earn funding? If so how does the security enforced? Since TEE has limitation on security based on the physical access.
• Where is the documentation for MPC operators to justify the costs?
• Who are the current MPC operators and how they were selected and compensated before?
• Why do we transition to 21 nodes with this proposal instead of just covering the cost of existing 9?

Hi Sal, thank you for putting this proposal forward. It was helpful to meet you during the governance call yesterday and get an early preview of this proposal.

Undoubtedly, this is an important and exciting proposal for House of Stake, as it begins to answer the question of what HoS will be governing in practice. As the first proposal of its kind, it is inherently precedent-setting. For that reason, it is important that the proposal includes well-defined processes and positions HoS for success.

It is also critical that the benefits and tradeoffs of this program are clearly articulated for all stakeholders, including tokenholders, NEAR builders, and validators — who may be impacted by this proposal. I will elaborate on these considerations in more detail below.

Before this proposal proceeds to a vote, it’s imperative to address the following material considerations:

Per-node cost assumptions

The proposal states that funding corresponds to approximately $7,200 per node per month. However, based on the emissions outlined in Exhibit 1 and a NEAR price of roughly $3, the effective monthly amount appears closer to ~$14.5k per node.

Please clarify the pricing assumptions used.

Source of emissions

The proposal does not clearly specify whether MPC node funding would come from:

• newly issued emissions, or

• a reallocation of existing validator rewards.

Please clarify the source of emissions so delegates and the community can understand the potential impact to tokenholders and validators.

Tokenholder dilution

If this program is funded via new emissions, then the cost is borne by tokenholders through dilution. Given that this would be an ongoing program, this tradeoff should be made explicit so delegates can properly assess the long-term implications.

MPC node requirements and operator expectations

The proposal states that “Node Requirements: Hardware and software specifications are documented in NEAR’s MPC GitHub.” However, after reviewing the referenced repository, I was unable to find clearly documented hardware and software requirements for MPC node operators.

While I see that you have outlined the requirements in bullet form in your response to fastnear, these requirements should be documented in a repository or other canonical source of truth so that delegates can properly assess cost assumptions.

HoS as program administrator

The proposal designates HoS as the program administrator responsible for maintaining the MPC node registry and executing ongoing payments. This represents a significant operational responsibility.

However, there is currently no proposed process, operating model, resourcing plan, or set of next steps from the HoS side. As written, this places ownership on HoS for an ambiguous and complex process that would be defined and scoped after approval rather than prior to it. Given the precedent-setting nature of this program, it is important to define governance structure and operational readiness before moving forward.

Overall, this is a very important proposal for HoS and will likely set precedent for how HoS manages similar mission critical infrastructure programs in the future. For this reason, the cost assumptions, emissions source, and administrative/operational framework should be clearly defined.

Looking forward to your responses and working together to keep iterating on this proposal.

Tagging community members who have not yet provided feedback, and whose perspectives on this proposal would be valuable. @KlausBrave @vinibarbosa @coffee-crusher @cloudmex-alan @charleslavon @jlwaugh @Cameron @Tane @Gus @Yuen

Thanks for the follow up and hoping that my response here helps to shed more color and light on the thought process as well as answering some of the questions you’ve raised.

There are currently 9 MPC node operators:

• NEAR One

• HOT

• Aurora

• Everstake

• Node.monster

• Staking4All

• Luganodes

• Stakin

• Black Sand

Historically, these node operators were recruited to help bootstrap the system using grants and thus far they have been performant despite having no established incentive for doing so. The goal of this proposal is to establish the basis for an incentive structure that can be used to recruit proven infrastructure partners into the system.

Please keep in mind that the proposal is simply for budget allocation and the actual utilization of funds is on a ‘look-back’ basis for actual performance. If the system does not scale to 21 MPC nodes, the full budget will not used. The ‘slashing’ logic for nodes who do not adhere to performance requirements are described in Exhibit 2.

In regards to the hardware and software requirements, these are documented in the section below explicitly.

The current state of the proposal is defined to define a budget allocation, rather than explicit funding in order form an incentive structure that would attract MPC node providers to engage.

1. The goal of establishing a budget allocation is to form as the basis of a recruitment process for nodes to join and run them. In the current form, the MPC nodes are distributed across geography and physical footprint security models in different data centers

2. See the detailed documentation below which covers the hardware requirements with variable costs based on the provider. The software costs and resource costs for the other line items in the response above are variable based on tooling selection and specific resources.

3. Previous compensation: NEAR One, HOT, and Aurora haven’t been compensated at all; the other 6 received grants which covered infra costs only without considering overhead

4. The rationale for transition to 21 MPC nodes is to scale the system to increase both decentralization and resiliency of the MPC node which will become increasingly important as Intents continue to grow and institutional flows begin to come online.

I hope this is helpful in addressing the points above and also happy to answer any questions.

MPC Node Hardware Requirements

The following hardware specifications and cloud provider recommendations apply to all MPC node operators participating in the network following the upcoming upgrade to the Trusted Execution Environment (TEE) MPC architecture.

Hardware Requirements

• CPU: 5th Gen Intel Xeon Scalable or Intel Xeon 6 (TDX-enabled)

• CPU cores: 16 or more

• Memory: 64 GB*

• Disk: 1 TB or larger NVMe SSD (or equivalent performance)

• BIOS: must have TDX support

* At least one DIMM must be installed in slot 0 of each memory channel. All memory channels must be symmetrically populated.

Networking

• Firewall: allow inbound traffic on port 80 (MPC) and port 8080 (web interface)

• IP address: a public static IP is required

Cloud Providers

The following cloud providers have been verified to offer hardware configurations compatible with TEE deployment. Other providers may also be capable of meeting these requirements. We recommend confirming TDX support with your existing provider before migrating to a new one.

• OVHcloud.com

• PhoenixNap.com

• OpenMetal.io

• Hivelocity.net (will require a custom configuration)

• DigitalOcean.com

• Cloud.Google.com

Alternative Hosting Option

Server colocation remains a viable option at any data center that offers colocation services, provided that the hardware meets the requirements listed above.

Additional Information
Refer to the Intel Hardware Selection page for additional information.

Axia:

Hi Sal, thank you for putting this proposal forward. It was helpful to meet you during the governance call yesterday and get an early preview of this proposal.

Undoubtedly, this is an important and exciting proposal for House of Stake, as it begins to answer the question of what HoS will be governing in practice. As the first proposal of its kind, it is inherently precedent-setting. For that reason, it is important that the proposal includes well-defined processes and positions HoS for success.

It is also critical that the benefits and tradeoffs of this program are clearly articulated for all stakeholders, including tokenholders, NEAR builders, and validators — who may be impacted by this proposal. I will elaborate on these considerations in more detail below.

Before this proposal proceeds to a vote, it’s imperative to address the following material considerations:

Per-node cost assumptions

The proposal states that funding corresponds to approximately $7,200 per node per month. However, based on the emissions outlined in Exhibit 1 and a NEAR price of roughly $3, the effective monthly amount appears closer to ~$14.5k per node.

Please clarify the pricing assumptions used.

Source of emissions

The proposal does not clearly specify whether MPC node funding would come from:

• newly issued emissions, or
• a reallocation of existing validator rewards.

Please clarify the source of emissions so delegates and the community can understand the potential impact to tokenholders and validators.

Tokenholder dilution

If this program is funded via new emissions, then the cost is borne by tokenholders through dilution. Given that this would be an ongoing program, this tradeoff should be made explicit so delegates can properly assess the long-term implications.

MPC node requirements and operator expectations

The proposal states that “Node Requirements: Hardware and software specifications are documented in NEAR’s MPC GitHub.” However, after reviewing the referenced repository, I was unable to find clearly documented hardware and software requirements for MPC node operators.

While I see that you have outlined the requirements in bullet form in your response to fastnear, these requirements should be documented in a repository or other canonical source of truth so that delegates can properly assess cost assumptions.

---

HoS as program administrator

The proposal designates HoS as the program administrator responsible for maintaining the MPC node registry and executing ongoing payments. This represents a significant operational responsibility.

However, there is currently no proposed process, operating model, resourcing plan, or set of next steps from the HoS side. As written, this places ownership on HoS for an ambiguous and complex process that would be defined and scoped after approval rather than prior to it. Given the precedent-setting nature of this program, it is important to define governance structure and operational readiness before moving forward.

---

Overall, this is a very important proposal for HoS and will likely set precedent for how HoS manages similar mission critical infrastructure programs in the future. For this reason, the cost assumptions, emissions source, and administrative/operational framework should be clearly defined.

Looking forward to your responses and working together to keep iterating on this proposal.

Hi Axia,

Thank you for your thoughtful note and comments. I’m hopeful the responses below are helpful to share comments and can serve as the basis for iteration to a final refined proposal following the comment period.

Per node cost assumptions

The structure is designed to place a floor $1.50 NEAR for $7,200 USD per node per month with a cap based on a NEAR price of $3. Given that the proposed incentive is in native NEAR, when NEAR’s price is higher the rewards should be capped to prevent overpending on the MPC Nodes relative to their loaded operating cost.

Source of emissions

The source of emissions are from the 10 basis points of the total 2.5% protocol emissions that are accruing but are currently utilized to treasury.near. This is NOT a reallocation of existing validator rewards.

Tokenholder dilution

The program is not funded from new emissions so there is no impact to the dilution of tokenholders.

MPC node requirements and operator expectations

Thank you for reviewing the prior post. I just responded to the Fast NEAR comment and pulled through very clearly defined hardware and hosting requirements for everyone.

HoS as program administrator

There are multiple ongoing workstreams to explicitly define the processes required to administer the program with multiple stakeholders from House of Stake engaged in the process. Based on the progress made to date, the requisite processes and procedures for program administration will be prepared well in advance of March which is the proposed inception date for operational mechanics. It is also important to note that several different stakeholders have responsibilities for the execution model to deliver the program.

I hope the explanation above is helpful and happy to address further questions or comments that you may have.

Thanks for your responses, Sal.

SalTernullo:

with a cap based on a NEAR price of $3

Correct, which means that if NEAR’s price increases to $3, operators will be paid a ceiling amount of ~$14.5k/month.

SalTernullo:

The source of emissions are from the 10 basis points of the total 2.5% protocol emissions that are accruing but are currently utilized to treasury.near.

Thanks for clarifying.

SalTernullo:

Based on the progress made to date, the requisite processes and procedures for program administration will be prepared well in advance of March which is the proposed inception date for operational mechanics. It is also important to note that several different stakeholders have responsibilities for the execution model to deliver the program.

Good to know. However, since the vote is expected to close on February 12, it is important that these operational mechanics are clearly outlined prior to that date so delegates can make an informed voting decision about HoS’s operational readiness to act as the program administrator.

Of course! I look forward to continuing to collaborate to address feedback and I fully agree with regards to the operational mechanics to ensure seamless execution and administration.

Thank you to the @SVRN for the preview in yesterday’s governance call and for this detailed and thoughtful proposal that is very balanced and fair.

This proposal is a significant step forward in positioning NEAR as an enterprise-grade protocol, which is important for the future growth of NEAR products. I specifically support the inclusion of the Floor and Cap price as a sensible fiscal management that protects both the DAO and the node operators.

To ensure this program meets the high standards for the HoS, I have a couple of comments and questions:

• I want to echo @Axia comments (tk u for the ping! ) regarding the operational responsibility placed on the HoS. Defining the operating model and resourcing plan is critical before the vote.

To address the ‘ambiguous and complex process’ Axia mentioned above, I recommend that the author considers moving towards an automated transparency rather than manual forum-post reporting as suggested in the proposal, especially since we’re talking about a 1M+ yearly program.

This could be created with a live dashboard similar to Meta Pool’s StakeVote UI or a public Dune Analytics report. This provides a real-time ‘Health Dashboard’ that reduces the administrative burden on HoS, it makes the ‘Challenge Process’ objective and trustless, and allows delegates to verify SLA compliance before the executing of payments by the HoS.

• The proposed 180-day window seems quite slow to be able to react to market shifts. A 90-day average would be closer to a ‘Goldilocks’ zone that provides the stability node operators need for planning while ensuring the DAO isn’t using ‘stale’ pricing that detaches from NEAR’s current value:

Ques: Does the author see any blockers to moving to a quarterly lookback?

• Regarding defining the scaling and a fair selection process to grow from 10 (including the author) MPC operators to 21 Nodes:

Ques: Is there a staged rollout plan (i.e. something like adding 3 nodes per quarter) to monitor network stability and budget impact as we scale?

Ques: How will the selection process for these new nodes be made transparent? Given that the authors are managing the GTM plan, will there be an open ‘Call for Operators’ with a public scoring rubric to ensure a competitive and decentralized selection or is there already a pre-selected target list from the NEAR team or HoG? And can you provide some more details of the strategy and tactics regarding the implication of the Go-to-Market plan to attract these additional 11 operators?

• Governance Integrity: Regarding the noted Conflicts of Interest by the author (thank you for that transparency), to ensure this program carries a clean mandate from the community, I suggest the author commit to an abstain vote in the Tally vote as well as providing a brief public statement of their reasoning.

Thank you for your comments and feedback Coffee Crusher. I agree with your point of view with regards to automated reporting rather than manual posting and we will work on automation of this reporting create a dashboard should the proposal be approved. This has always been the intention but with the first priority goal being to operationalize the program, manual reporting in the short seems a sensible first step.

In regards to the program management, I want to make sure the collective group is consistent in understanding the requirements in the proposal that actually fall on House of Stake which are narrow in scope to including: 1.) AML / KYB of node providers and 2.) execution of on-chain payment pursuant to monthly receipt of calculated rewards. While not trivial in any manner, the resource and time requirements to execute these functions are manageable in-scope and do not represent material overhead.

We initially began with a 90 day average calculation and after consideration of the dramatic and volatile swings that we’ve seen over the trailing 24 months and elected 180 as the period that would smooth this volatility in the most meaningful way on both the upside and downside. We can revisit this and discuss further, but I do feel confident that we landed in the right approach.

I am not opposed to the idea of a quarterly look-back but it could place a cash flow burden for the ongoing operating costs to the MPC node providers.

In regards to your recommendation on abstaining from the voting process, I do appreciate your perspective here and want to air on the side of full transparency. The foundation of conflict management is rooted in disclosure, which we have done from the onset of this process. In the House of Stake community call we clearly stated that we intend to vote with 500k veNEAR which we believe is the right approach, but for the benefit of those who could not participate I want to state this plainly here in the forum. This places us as a significant delegate with the other large delegates in the system having greater voting power than us, but it is balanced and does not utilize our balance sheet to governance attack the system.

SVRN is the largest NEAR token holder outside of the Foundation with public disclosure of 50M+ NEAR on our balance sheet. We are long term incentive aligned to the success of NEAR and believe that expressing our vote, both in the context of this proposal, as well as through active participation in future governance proposals within House of Stake is our responsibility.

I hope the thoughts above are helpful in reacting to your comments, all of which are thoughtful and constructive.

Thank you so much for your response to my comments and questions, and your continued engagement with the community.

If you can move towards an automated reporting process that is open and transparent for all community members, not just to the the HoG, this allows for the delegates and token holders to have full viability and information.

Thank you for more details regarding the R&R’s for the HoS (i.e. HoG) regarding admin responsibilities. If this proposal passes, it would optim if @AK_HoG could provide more details to the community on actual admin time spent per month, to understand the resource allocations and requirements.

I totally understand your decision about the 180 day period due to the past volatility of the market recently. Since any changes to this proposal (if it passes) will require a follow-up proposal, I suggest that after six months that we could revisit and review if the 180 days is working correctly to mitigate larger pricing swings or it needs to be adjusted with a follow-up proposal.

Regarding my abstain voting comment, I actually intended that I’m in support of SVRN voting on Agora for this proposal, but requesting that if you do vote, to vote “abstain” or registering your vote after the minimum quorum requirement has already been reached. While still providing a voting rational either path on the Forum for full transparency.

Also, I’m not sure if you saw my questions the selection process for the 11 additional operators and about the implementation of the GTM plan that I mentioned above?

image681×278 6.78 KB

Of course, I want to make sure that we are good stewards of the process and set a strong example in leading by engaging with the community given this is the first material economic design related proposal going through HoS.

We are committed to work towards automation and can share a timeline once we have scoped the effort and begin delivering on it. It should not be too difficult to execute against and I think feasible to have live for the first payout period.

I agree with your logic on the approach and six months into this process we can evaluate opportunities for optimizations and then carry forward a new proposal and voting process.

I had misinterpreted your logic previously on this point. We will evaluate your thoughts as a team and ultimately take the decision that we think is in the best interest of the community. There are pros and cons on every approach but I very much appreciate your perspective.

I apologize for missing these questions here are some quick responses:

-There are currently 9 nodes live today that would be migrated to the program and then the objective would be to scale this to the 21 target throughout the year.

-There is no pre-selected target list to date, and we can work on sharing the evaluation criteria which largely center on capability and controls around the infrastructure to ensure the highest likelihood of compliance with SLA requirements. These are generally measured through ongoing third party attestations over technology controls expressed through SOC (service organization control) reporting where third party auditors validate that technology controls are designed and operating effectively to ensure availability and performance, amongst other control objectives. The plan is to leverage the successful approval of a budget and defined incentive system to recruit mature infrastructure businesses and regulated financial institutions to participate in the system.

I hope this is helpful and apologize for missing these questions previously.

Thank you so much for your thorough and quick responses to comments, and I truly appreciate your demonstrated intentions of strong community engagement.

I also appreciate the commitment to work towards report automation, and especially in time for the first payout period.

The six month evaluation to allow for optimization (and resolving any refinements needed) will increase the strength of this proposal and it’s success.

No worries regarding misinterpretation of my comments about abstaining, thank you for taking this into consideration to have a transparent and fair voting cycle.

Thank you also for the further details about the selection process for these additional 11 operators, and I’m looking forward to reading when available, the evaluation criteria.

I do have a question about your Go-to-Market plan and specifically your tactics on how you will identify (once you have the evaluation criteria) and engage with these potential operator prospects to have them become a part of the MPC program?

SVRN:

Conflicts of Interest

The authors of this proposal are involved in NEAR infrastructure development. Sal Ternullo serves as the CEO of SVRN which is a NEAR-focused treasury company while Kendall Cole serves as the Founder of Proximity Labs. SVRN has a clear and expressed intention to become an MPC node provider in the system.

Could you please clarify whether Richard Muirhead is currently a member of the SVRN Board?

Additionally, was any internal NEAR Foundation resource involved in promoting or advancing this proposal?

I would also like to note that Richard Muirhead serves as a Council member of the NEAR Foundation Board and as Chair of the Compensation Committee.

In this context, if Richard Muirhead is indeed a member of the SVRN Board, then submitting this proposal for a vote — as well as any subsequent voting on it by individuals affiliated with the NEAR Foundation, including contractors — could constitute a conflict of interest

I would appreciate your clarification on this matter.

Thanks for raising this @Axia totally agree with the concern. The operational model needs to be clear before a vote, not figured out afterward. We’ve been pushing for exactly that while this proposal was still in draft.

HoS’s Role and Scope:

We’ve gone through a few iterations to clearly define HoS’s role and make sure it’s something we can actually deliver on. The outcome is a clear RACI where HoS is accountable for three things:

1. Maintaining the eligible MPC node registry
2. Verifying performance and computing Monthly Uptime %
3. Executing monthly payments

All three require HoS to build new operational capacity, intentionally so. Transparency, eligibility enforcement, and payment execution are core governance functions for NEAR protocol-funded infrastructure, both for this MPC program and future, similar efforts.

How we plan to handle this in practice:

• Node registry: We’ve already started outlining the steps to establish and publish the registry if the proposal passes, working closely with NEAR One.
• Monitoring & uptime: HoS will build on NEAR One monitoring data, with the HoS Security Council verifying correctness, validating rewards, and administering the challenge process defined in the proposal. In this role, HoS will also provide input on onboarding or replacing MPC signers where needed. We’ll publish as much of the process as possible without creating attack vectors.
• Payments: HoS Foundation will handle KYC/KYB and act as the interface between protocol emissions and compliant MPC signer payments in NEAR or otherwise. We’re already coordinating with service providers to make this workable.

On funding HoS operations:

Longer-term, HoS operations should be funded via HoS’s own active treasury (pending Citizens House approval of the Proposal to Terminate the NEAR Community Purpose Trust by the transfer of all of its assets to the House of Stake Foundation). To avoid any execution gap, NEAR Foundation has confirmed a grant to cover the costs needed to get program administration up and running.

Summary

Bottom line: The scope is clear. Readiness and risks have been assessed. Funding is secured. We’ll start simple and increase sophistication over time.

HoS will grow capacity in line with real governance needs, building our muscles to matter, while ensuring the program is executable from day one, if approved.

Hi Dacha,

Thanks for your note. Richard Muirhead’s time serving as a member of Near Foundation Council concluded in early December. Subsequently he was nominated to the Board of SVRN and after a period of diligence he was approved unanimously by the BoD as cited in the 6K filed in December.

To be abundantly clear, there are no members of Near Foundation involved with this proposal.

Of course glad the comments were helpful. I am traveling today but will loop back to respond and provide clarity on the GTM motion.

SalTernullo:

Hi Dacha,

Thanks for your note. Richard Muirhead’s time serving as a member of Near Foundation Council concluded in early December. Subsequently he was nominated to the Board of SVRN and after a period of diligence he was approved unanimously by the BoD as cited in the 6K filed in December.

To be abundantly clear, there are no members of Near Foundation involved with this proposal.

I want to be explicit that this does constitute a potential conflict of interest, and it should be addressed clearly.

I generally support initiatives aimed at strengthening critical infrastructure, and I agree that sustainable funding models are needed. At the same time, I strongly believe that such programs require precise calculations, clear governance boundaries, and strong transparency guarantees.

In this context, it would be very helpful if Richard could publicly confirm:
• that he has no conflict of interest with respect to this proposal,
• that he did not participate in drafting, sponsoring, or advocating for this proposal in any capacity.

In addition, it would be important to explicitly state that your company will not be involved in administering, allocating, or managing payments to MPC node operators.

My understanding is that:
• the administration of this program should be clearly assigned to House of Stake (HoS),
• and that veNEAR token holders retain the ability to review, amend, and influence the program parameters through governance.

Clear statements on these points would significantly reduce governance risk, improve optics, and strengthen trust in the proposal and the process overall.

Hi Dacha,

If Richard were to serve on both NFC and the Board of SVRN at the same that would certainly warrant a conflict of interest, however that is not, and has never been the case. I take COI very seriously and have been approaching this process with upfront disclosures and transparency at the center of the approach.

I’m glad that you are aligned with mechanic design for critical infra, this is what emissions from the protocol should be utilized for and we’ve been thoughtful to ensure in its design that the protocol does NOT overpay, as it historically has, and in my view still does for economic security with a run rate annual cost greater than $75M.

I can send a note to Richard and ask him to respond directly as well, but I can state plainly and directly that he had NO involvement in the proposal development and never saw the content until it went live (if he has even seen it yet). I actually drafted this myself personally and tried my best to take care in doing a good job. The drafting and publication of proposal like this is not within the scope of responsibilities for a Board Director of a public company.

I can confirm as well we have zero role in the payment flow. Your understanding of program administration is correct and you are well correct regarding future changes to being governed by veNEAR holders.

I hope the above is clear and helpful for you and others.

Great conversation going on here. Some remarks:

1. Thank you @SalTernullo and @SVRN for the time put into elaborating this proposal, which is obviously not perfect (nor in the final form for its ideal execution, as correctly pointed out in the comments) but it’s a notable and very much needed improvement over the current financing structure (or the lack of) for MPC Nodes. It’s a solid first step and I hugely appreciate your work here.
2. Thank you @Othman @fiatisabubble @fastnear @Axia @coffee-crusher @Dacha and @AK_HoG for your respective remarks and follow-up comments – I have been reading and carefully meditating on them and I believe most of what was said makes sense and were relevant points. Sal also did a fantastic job addressing each of them through rejoinders.
3. Most of my doubts and concerns were successfully addressed in the convo and we also had the opportunity to learn more about the MPC node infrastructure, which had been a recurrent community request – so this was already a very positive outcome as we can only benefit from transparency and understanding how this layer works.

My remaining concern and improvement proposal would be regarding the UoA and MoE of this program, as FASTNEAR already mentioned here and I agree:

fastnear:

The payment should be calculated in USD. The 180 trailing price doesn’t make sense. We have intents to convert the monthly payment into USDC or another stablecoin. Node operators should receive the infra cost in USD, while rewards can stay in NEAR if they chose so.

THE CONCERN

IMHO, we should either change the way we are accounting for the infra costs or rewards (currently in USD) or the means of payment (currently in NEAR). Doing it has many benefits.

Basically, the payment must be done in the same currency the reward is calculated in, and it should be in USD because this is how the underlying costs to run the infrastructure are nominated.

1. It removes the friction and challenges of calculating the correct payment amount in a highly volatile environment (crypto) - i.e., what price-avg we should use, is 180D the correct magic number? Hard to say.
2. It removes the downside risk for MPC Node operators and the overspending risk for the Treasury.
3. It generates exchange volume for the pair and activates these venues, which benefits the entire ecosystem.
4. I can’t think of any clear, strong opposing argument to doing that (if properly executed), while the way it is designed has some, as already discussed in the comments – but I would really appreciate it if someone could cover my blind spot and explain the negative aspects of doing as proposed below…

THE PROPOSAL

So, IMHO, we should:

Change the payments to dollar stablecoins to meet the reward’s calculation UoA, as first proposed.

For that, the Program Administrator would need a simple script to DCA from NEAR to USDC/T every epoch (I suggest 50% for each stablecoin to reduce the risk exposure to each project) during the respective month until a predetermined amount ($7,200 (?)) per potentially-eligible-node-operator is met –> let’s say 21, in the best-case scenario, making it a maximum of $151,200 swapped NEAR at a rate of $5,040/day and ~$1,680/epoch).

In case one or more of the node candidates do not qualify for a month’s payout, this value remains reserved for the next month, reducing the NEAR-USDC/T swapping amount needed for this next month. This could or couldn’t be deposited into liquidity pools to increase the treasury’s capacity, yet tbd.

Once receiving the payments, node operators then have the possibility to (i) swap back to NEAR if they want to keep their holdings that way and operate under a specific financial strategy or (ii) immediately use the dollar-nominated value to pay for their costs.

Another benefit this brings is that the (ii) tier will have its NEAR-selling pressure reduced due to a gradual, recurrent selling done beforehand; instead of an individually-managed off-ramp strategy for each node operator, which could be, in many cases, a single token dump.

Curious to hear back from you or other commentators.

Best regards,

VB

Hi, Simon here.

This is my first post participating in a discussion in the House of Stake.
I have much to learn about operating the MPC Network, which is not common within the L1 Ecosystem.

In this scenario, MPC nodes provide a profitable economic model with a margin of up to ~$8,500 USD per month relative to infrastructure, monitoring and maintenance costs of $6,000 USD. The examples of calculations for a Floor, Actual and Cap scenario are enumerated in Exhibit 1. Conversely, this proposal introduces a floor mechanic at a price of $1.50 USD per NEAR token to ensure that the MPC node operators are not operating at a loss.

As @vinibarbosa proposed earlier, eligible node participants will receive remuneration in $USDC, with those ideas i think it would be secured for this funding.

In line with this, i will also add suggestions on how to incentivize MPC node operators as $NEAR increases in volume and token price. My understanding is that NEAR has significant potential for growth, and it would not be advantageous for node operators to miss out on these potential upsides.

Trailing renumerations based on NEAR price might be justified, and would attract more MPC node participants in the near future. It would be a good addition if the price of near growth over 20% in a one month timeframes, is serve as the additions after the USDC rewards (base rewards).

Is it possible to be implemented fully on-chain ?

Fully automated on-chain distribution: reduces human involvement but increases execution surface and governance change risk; this proposal keeps execution explicit while retaining on-chain transparency.

This is a question, and I am learning myself.

Hi Coffee Crusher,

I am looking back on this, apologies for the delay. With regards to the evaluation process we are going to be adding a clause that covers this topic.

With regards to the GTM motion, we have a pipeline of mature infrastructure companies and regulated financial institutions in the custody, exchange and banking segments that we intend to pitch once the proposal passes and economics are clear. I am going to hold naming specific targets for this until we further mature and validate whether they are interested.

Hi Vini,

Thank you for your note and kind words. I agree we’ve had a constructive community dialogue on key topics and am thankful to everyone for engaging in good faith on important topics.

I understand your point of view as it relates to the incentives being paid in USD but I am not aligned that this is the best outcome for the network and NEAR token holders. The incentive structure should not introduce, by design, consistent sell pressure on the token in order to pay our MPC node infrastructure providers. Instead, the MPC node providers should be paid in NEAR and take a decision as to whether they can stay long the asset or if they need to sell portions to fund op-ex. I have fairly limited concern regarding the actions of each node provider as it relates to sales given the size. The precedent for a NEAR based payment approach is consistent in every public blockchain for all node infrastructure providers and I believe creates a STRONGER incentive alignment to NEAR token holders and the protocol.

The depth of thinking that you articulated in your analysis is extremely helpful so thank you for the detailed walk through in your thinking. I hope this is helpful in sharing my thoughts on the topic.

Hi Simon, nice to meet you. I just shared a long response to Vini but my view is that the approach to pay out in USD or USDC weakens the incentive alignment between MPC node providers and NEAR token holders while also introducing a consistent selling pressure on the token, which I do not believe is a good design.

In regards to payments, these will be executed on-chain by HoS and will be reported publicly.

We are all learning together every day so thank you for jumping in and sharing your thoughts.

This is a strong and important proposal for House of Stake.

MPC infrastructure is foundational to NEAR intents and cross chain execution, and as intents continue to scale, the reliability and decentralization of the MPC set becomes increasingly important to the protocol’s long term health.

Because MPC is a signing layer for intents, operator concentration creates correlated liveness risk and increases the chance of censorship or policy capture. More independent operators reduces this risk and improves resilience as intent volume continues scaling.

Establishing a structured, emissions backed program with clear eligibility requirements and SLA style performance gating seems like a reasonable step toward supporting that infrastructure sustainably and scaling the MPC set over time. It’s important to ensure that this program meets product goals, and we are keen to see the impact.

It’s also worth highlighting that users in House of Stake are currently earning an additional ~7.5% APY on their locked NEAR, aligning economic incentives for governance with the successful operation and security of the protocol. Lock your NEAR in house of stake at https://houseofstake.org/

Looking forward to the discussion on the community call!

Hi Angela,

Thanks for your response. Please provide clarification on a few points:

1. Program Administrator vs. House of Stake

The proposal states that House of Stake is the Program Administrator however in the RACI chart, Program Administrator and House of Stake appear as two different parties.

SVRN:

Program Administration: House of Stake, or a formally delegated operator acting on its behalf, is responsible for administering the program and authorizing off-chain payments in accordance with the approved pricing formula.

image1398×420 66 KB

Please clarify the distinction between Program Administrator and House of Stake. Is Program Administrator a sub-group within House of Stake? If so, which individuals from HoS are also Program Administrators?

2. Clarification on “We”

AK_HoG:

Node registry: We’ve already started outlining the steps to establish and publish the registry if the proposal passes, working closely with NEAR One.

Related to the above question, who specifically does “we” refer to here?

Given that House of Stake is a broad group, clarity is needed on which specific individuals or teams within House of Stake will be responsible and accountable for program administration.

Thank you again.

whoever supports this proposal (by voting or delegating to someone who voted for it) should be slashed and i will make a slashing proposal if this passes. no idea if slashing is a thing, but it should be, to protect against governance attacks, which i believe this is (person writing this proposal clearly doesn’t know what he’s talking about, using unrelated projects like near intents to boost trust). spending 1.2 million near on some experimental tech that is (as far as i know) not used by any project with >10 users (maybe except Dew, a new defi project). and it all goes to handpicked operators, whose margin is probably like over 80% already (i run higher spec servers for my rpc nodes for $100-150/mo on the same recommended cloud providers). Imo it would be best to just shut down that mpc network and cut NF (or whoever issues the grants) losses, instead of transferring these losses to house of stake. or optimize the mpc network to be less expensive. currently, the mpc network processes around 1-3 signatures per minute (usually 1), 1 of which is tx-bench.near which is just uptime tracking, not a real app, you can see it on https://nearblocks.io/address/v1.signer, i dont think 1-3 signatures per minute (actually 0-2 if you exclude uptime tracking) costing 1.2m near is sane use of money. i’m not against increasing emissions, but when it comes to hands of some 21 people that were picked by one person / team, that’s a very stupid proposal at best and an attempt of governance attack with “good pretext” at worst.

according to my analytics, which i will not get into today, almost all house of stake power is coming from one person delegating to different people from different obviously fake wallets, so i dont think it would change anything anyway, but in case there’s someone believing the bs about mission-critical infrastructure, posting this here. tbh in a perfect world decisions like this should be made when more stake is onboarded to house of stake, and that stake is more provably decentralized

also, wrong name of the proposal. there’s nothing sustainable in printing tokens out of thin air. sustainability, at least, in my definition, is when users and apps pay fees and that’s how the network makes money. in this case, even if the fee was $0.01 (quite high, but critical / defi / enterprise apps could afford in some cases), the network would’ve made $5000 in 1.5 years. if we exclude tx-bench.near, that would very likely be less than $100 in 1.5 years (i don’t have the tools to calculate exact amounts, so i’m judging by transaction counts on nearblocks). spending 1.2m near yearly on that doesn’t scream sustainability to me.

My concern with this proposal is multi-fold.

1. NEAR Intents being deemed as critical infrastructure. It adds zero value to the protocol and the network overall. The net effect and gain is that whomever controls the intents wallet receives the fees. that’s it. Which a portion should go to supporting the operators. Aka its the new kind of bridge that does not likely have lasting network effect and does not grow the actual protocol. there is no moat.

2. House of Stake legitimacy. There is not enough stake in HoS to make it a legitimate governance mechanism. the original discussed threshold was 30% of stake 30M near and then lowered to 10M which i’m unsure has been met. there was a deadline of Dec 31st '25. The current state of HoS does not make it a legitimate governance mechanism to dictate protocol fee allocation. This should be a validator vote until HoS is legitimized. the other challenge is that the stake in HoS at the moment is heavily concentrated among 2-3 nodes in the ecosystem and 1 lockup account.

Seems at best a ploy to fund HoS by moving the protocol emissions from NF to HoS without a legitimate governance decision. Let the validators vote for such a critical proposal since there is not another legitimate governance system in near.

Hi Slime,

Your analysis lacks factual accuracy in a number of places and its clear from this post and your prior comments regarding the MPC network that your current understanding is not aligned to the actual technical implementation of the system. This proposal is certainly not a governance attack, given the commitment to transparency, proper disclosure and public discourse.

Chain Signatures and the MPC nodes that power it, are a foundational building block that are used to enable Near Intents and dozens of projects that are utilizing the 1-click API. Please take the time to review the documentation (What are Chain Signatures? | NEAR Documentation). There are hundreds of thousands of users currently using Near Intents, all of which is utilizing Chain Signatures and MPC nodes.

Your comparative analysis of running RPC nodes relative to MPC nodes is not grounded in the facts of the hardware specifications and associated costs, which are orders of magnitude higher than what you are citing for running RPC nodes. The documentation I’ve shared will show you the pure hardware costs from different hosting providers. Further, the uptime and availability requirements for the MPC nodes must be at the highest level to ensure no negative impacts to users transacting on the system which incurs additional costs.

in regards to the cost of the program, and your comments with regards to ‘increasing emissions’ I want to follow up and clarity two distinct points which I believe you’ve missed entirely. First, this proposal DOES NOT increase emissions, it relies on tapping existing emissions that are utilized today and the total budget proposal is just that, ‘a budget’, not a guaranteed spend.

You can have your own view regarding the naming convention of the proposal, but again, the emissions are already occurring and are utilized today and your calculation of the network revenue opportunity is only contemplating protocol level fees without thinking through monetization of NEAR token holders benefit at the solver and front-end layers, which have the potential to generate $20M+ in 2026 alone.

I doubt given the tone and approach in your comment that you are interested in discussing these topics to get to technical veracity, but if you are I am happy to spend the time.

Thank you for your response, Sal.

I understand the selling pressure argument, but I don’t think it would be relevant if done as I proposed, considering the daily volume we already have (at very poor market conditions) on NEAR-USDC/T pairs is more than enough to cover these operations with low-to-none liquidity impact.

The selling pressure is also a fair trade-off against risk paying 2x more than what MPC nodes would need (according to your cost estimations) if the 180D price average approaches its cap at the high end of the exchange rate range – something very likely to happen considering NEAR’s historical price action and volatility.

If USDC/T payments are out of the table, the only way I could agree with payments done in NEAR would be to change the cap range and distribute the risk equally between the treasury and node operators. → Effectively reducing the rewards below the proposed 10bps to meet the following scenario.

For that, the estimated costs (which @slimedrgn argues is just too high and I agree it looks high, but I don’t have the knowledge or had time to research and check the estimations yet) should be in the mid-range, not at its bottom.

Let’s say: $7,200 should be at ~$2.25/NEAR, not $1.50/NEAR.

This way, if the price drops below the mid-range, operators would be receiving slightly less than needed. However, this would be balanced when the price reaches the cap at $3, paying nodes slightly more than needed.

The way the proposal is currently designed, HoS treasury takes all the price volatility risk and operators take none.

• For no price volatility risk, the USDC/T model makes more sense.
• If we want to add risk, then it must be bilateral, shared risk.

I would love to see further research/data on the cost estimations (I’ll do some research my self when I have time)

Wdyt?

Hi Blaze,

Thanks for your note. I wanted to follow up quickly and dispel what seems to be a misconception.

1.) I just shared a response to Slime in another post, but your computation of the value capture to NEAR from Near Intents is not accurately measuring the capture across the stack. There is value capture at multiple levels which we believe can generate $20M+ in network revenue for NEAR token holders in 2026. The analysis comparing this to a new kind of bridge ‘without a network effect’ is at odds with the data which shows extremely strong user retention across the implemented surfaces to date. If there was no moat, you would not see integrations from major L1 ecosystems, you would see rapidly evolving features that aim to directly compete, which thus far has not panned out.

2.) House of Stake has increased its maturity over the past 2-3 months and is ready now, in our opinion, to complete a vote of this manner. I understand your comments regards the scale of voting participation today, and do encourage everyone to lock their NEAR and actively participate in this process. The validator set is the wrong layer of the system to contemplate a vote of this manner for a number of reasons, not the least of which is a conflict of incentives with their own objectives.

Hi Vini,

Thank you for the follow up and note here. In the cheapest provider of the MPC node specification we are paying $1800 x 3 which is $5,400 solely for the hardware rental required to run the system. If the system is designed in such a manner where there is no upside to the MPC node operators, in the form of NEAR token price appreciation, then there is no reason for anyone to run the system. A $1,200 USD margin per month is an extremely weak incentive structure for any mature infrastructure business, let along for regulated FSIs.

This includes a primary node, a main-netback-up fail-over node, and a test net node.

I feel quite strongly that the incentive structure should emulate existing validators being paid out in NEAR which creates upside incentive alignment. The market analysis in terms of 24 hour depth is accurate, but lacks the color regarding its variability over time. In thin-market windows this could have a disproportionate impact on the market price. We should be designing a system which celebrates collective upside success where NEAR performs well at spot, while designing the incentive structure in the manner that gives the highest confidence outcome on MPC node reliability, uptime and performance which are the key principles required for the system to scale.

We can agree to disagree. any data can be presented in any view. Competitors have much larger partnerships and network effect. this is an overpriced subsidy to seemingly take near off the market.

if this was a real business model. L1’s that integrated would be subsidizing the MPC network with additional protocol emission fees or share or revenue models or there would be a pay to play model. Any of which would support the MPC network providers. Instead this an infra play that has limited impact on near protocol itself and cannibalize near as a utility layer. Maybe that is the real vision. If so, it needs to be more clearly stated and providing protocol emissions to this program is 100% the wrong move, especially without a sunset timeline to get profitable. this statement alone shows the reality.

No. House of State is not legitimate. It can not make such decisions and if it does it violates ever principle of governance systems.

Lets stop shoveling paper. NEARs MPC network is centralized and prone to attack. unless the players are fiduciaries, there is a timeline for program sunset without real revenue and HoS is legitimized this proposal is non-additive.

It’s time for near to determine how they actually create true network effect to use the actual protocol instead of subsidizing infra that looks cool, but on paper has zero real network effect for the protocol itself and creates no value for the price of near.

Hi Blaze, I totally agree, we can differ in perspective and agree to disagree. Thank you for the comments and feedback.

I want to make sure you and everyone else has proper context re: MPC

It is currently used in production on Omnibridge for Ethereum, Bitcoin, Zcash, and Solana, and is securing > $75M in TVL. It is a critical system with no pathway to deprecation without offboarding substantial TVL or weakening security: https://dune.com/proximity_team/near-chain-signatures-tvl

Additionally, if you are aware of any cloud providers offering machines that meet or exceed these specs for the costs you described, please share them

MPC Node Hardware Requirements

MPC Node Hardware Requirements The following hardware specifications and cloud provider recommendations apply to all MPC node operators participating in the network following the upcoming upgrade to the Trusted Execution Environment (TEE) MPC...

SVRN:

Chain Signatures and the MPC nodes that power it, are a foundational building block that are used to enable Near Intents and dozens of projects that are utilizing the 1-click API.

we won’t get anywhere by just repeating our point, please prove it if you think it’s true. here’s my proof that it’s not: Telegram: View @near_intents. also, if you have source code (i believe near intents infra is not open source) or at least any endpoint that provides any kind of attestation / way to verify that it’s used (the current endpoints don’t), or a way to verify that through a web browser, i would accept that as proof as well. and let’s add it to public docs, while at it. i only use public information in my research, and it could help other people as well. i didn’t dig too deeply into the code, maybe there is some way to verify your claims, but i’d like to not spend 100 hours trying to find it, it should be clearly documented, or at least attached in your response, rather than just saying that my analysis lacks factual accuracy and providing no facts to counter. i’ve read that link to docs that you sent, and in fact, i was one of the first people to build with chain signatures, wrote a technical article 2 year ago (can’t find the link, never used medium since then, but maybe someone still remembers where it is, please believe me on that one) about it with one of the core developers, all before docs were even written, even before it went live on testnet, so please don’t treat me as someone unknowledgeable in this topic by sending a link to “What are Chain Signatures?”. but i understand that you may be confused or believe the wrong thing if that’s what you read on that topic. to get beyond the marketing claims and reach the truth, you need to dig deeper, in explorers, code, documentation, ask the developers.

SVRN:

Your comparative analysis of running RPC nodes relative to MPC nodes is not grounded in the facts of the hardware specifications and associated costs, which are orders of magnitude higher than what you are citing for running RPC nodes.

i don’t know how many machines one operator has to manage, but here’s my configuration from one of your recommended providers:

image1391×1277 132 KB

image1477×406 25.9 KB

this costs $174/month. i know that it’s a consumer CPU and doesn’t support TDX, but I used to have a similarly spec’d 32-core xeon (don’t remember exact model) for roughly same price from a different provider, consumer cpus just perform better for rpc tasks. i don’t know if a custom tdx configuration makes a $174/mo server go to $6000/mo, never asked their support, but i sure hope it doesn’t, that technology is present in literally any modern intel server cpu afaik.

SVRN:

First, this proposal DOES NOT increase emissions, it relies on tapping existing emissions that are utilized today and the total budget proposal is just that, ‘a budget’, not a guaranteed spend.

in the end what matters is the ratio of sell pressure to value. if the ratio is good and a lot of useful projects are being funded, i wouldn’t be against even increasing the treasury emissions. but if the project is not worth the money, it doesn’t matter if it’s a new emission or existing emission that is unlocked from a treasury that just holds tokens and never sells them, the sell pressure is the same, the difference is just whether you decrease or don’t decrease the treasury budget for other things, which this proposal does. which is not really changing anything since house of stake is not funding a lot of stuff right now.

regarding ‘a budget’ / ‘a guaranteed spend’, i consider it to be a guaranteed spend while evaluating, because when i analyze spending, i do it pessimistically. nothing good will come out of making a 1.2m budget but assuming that only 600k is going to be spent, and using 600k in calculations of sell pressure / future budget constrains.

kendall-near:

It is currently used in production on Omnibridge for Ethereum, Bitcoin, Zcash, and Solana, and is securing > $75M in TVL

this is from near-one/omni-bridge:

image1253×485 30.9 KB

not seeing zcash or solana using chain signatures here. it has been “transitioning” for like a year or so, and still in this state. near intents supports 27 networks. even if 2 of them actually use chain signatures (benefit of which is still debatable, since there’s no way for end user to verify that it’s true, and other integrators just ask 1-click api for the deposit address, which is a centralized custodial trusted agent), the value is hardly worth the money. chain signatures have been in development for a while, and in 1.5 years after going live on mainnet, are used on 2 blockchains (per the public information), idk how justifiable this is. i would wait for when fees are started to be used for buybacks and see if the tech is worth it, before making annual commitments that dilute every near holder.

tbh even these 2 networks using chain signatures is new to me, i was not aware that near intents switched btc and eth networks to omnibridge, this probably happened without any changes in documentation or public announcements. you can also verify that only a small minority of transactions uses MPC by checking number of “sign” transactions per minute to v1.signer on nearblocks, and number of swaps on explorer.near-intents.org, numbers don’t quite add up. there was a request to add this in documentation (Telegram: View @near_intents) but it was not added, so i genuinely have no idea when they change something, since infra is not open source (only frontend and contract are), 1click is centralized and “trusted”, docs don’t mention which networks use poa, which use hot, which use chainsigs, no announcements (unless i missed something), so i get why everyone is confused including me. if anyone wants to respond or prove me wrong, please attach a proof and not just say that i’m wrong, my first message included a lot of verifiable facts, unlike the original proposal or responses to me. let’s keep the discussion constructive and factual.

and even if you somehow convince me that it’s worth the dilution, i would still need the network to have a clear and open and (hopefully) decentralized selection process, so that anyone, or any mainnet validator with proven uptime if reliability is the issue, can run a node and be part of this incentive program, not just companies hand picked by someone, that’s not how decentralized systems work.

How is this related to NEAR Protocol driving chain utilization and ecosystem growth that drives value to near? zero sum game.

Proximity was sitting on an absolutely huge war chest of near why not sponsor it seems aligned with the original mission?

Protocol emissions must go to ecosystem growth. this will do nada to drive near protocol growth or value accrual to near.

what are we doing folks. driving near to zero. someone needs to pull up. NEAR Intents was a good idea. Rainbow bridge 2.0 it will require the same life support and drive no onchain utilization or value accrual.

Hi Slime, there are number of community stakeholders here that can to answer your questions and provide specific citation of the underlying repository and functions. Kendall just followed up with a note regarding the current TVL security by Omnibridge, which is the basis of the roadmap to scaling Intents. I’ll let @Bowen or someone on engineering side tag in to give you this information.
To be clear, I’m not questioning your engagement with Chain Signatures two years ago, I am making statements regarding the current state of the system and asserting that it is ‘critical infrastructure’ powering the most important system with recognized traction in the ecosystem today.

Thanks for walking through the configuration of the system, but to be clear having TDX enabled with access secure enclaves to manage key materials, is the foundation of the system. So spec’ing out a CPU through the same cloud provider and citing the cost structure is, again, the wrong basis from which to compare. In the current list of providers, the CHEAPEST option is OVH which incurs $1800 per node, which is then applied 2x for redundancy and again for monitoring =$5,400 for hardware alone putting aside resources and adjacent software technologies.

On your next point related to tokenomics broadly, I am aligned and agree. At the end of the day, the success of NEAR is subject to the inflation of the total system relative to the demand economy for the token as expressed by either burned, long duration positions and permanently locked tokens. The entire basis of making this proposal is from the point of view, supported by data, that paying a maximum of 1.2M NEAR per year, for the core infrastructure powering a system that has track to generate $20M and eventually $100M into token sinks is a worthwhile investment for the protocol to make, especially given the fact these emissions were designed to allocated for systems of this nature (ie. critical infrastructure).

Based on my understanding, the screenshot that you are citing is out-dated and needs to be updated further, which I am sure the team will do in due course. The proposal as it stands, is the first step in advancing discourse around economic policy and progressively working towards decentralization of the system.

It is clear that we are miles apart in our point of view on the importance of Chain Signatures, supporting MPC nodes and Near Intents, so I don’t imagine that we will materially changing our stances vis-a-vis each other on this topic. Regardless, I’d like to that you for sharing your thoughts and contributing in the discussion.

SVRN:

hat paying a maximum of 1.2M NEAR per year, for the core infrastructure powering a system that has track to generate $20M and eventually $100M into token sinks is a worthwhile investment for the protocol to make

this is the entire talking point and should have been the entire convo. how does that work? fees are auto burned. a toll tax is added?

this was not clearly laid out as the value prop. all discretionary power must be removed to actualize this and the scope extended to the run teams where is that budget coming from?

I’d like to provide a few clarifications on this topic:

• Chain Signatures is used in Omnibridge starting from Day 1. Near → Foreign Chain always uses chain signatures, whether the destination chain is Bitcoin, Zcash, Solana, Ethereum, etc. The other direction (foreign chain to Near) uses a variety of proving mechanisms including light clients and wormhole. However, we are also working on migrating that entirely to chain signatures.
• Indeed the cost of a bare metal TDX machine is high. The reason is that only Intel 5th or 6th gen Xeon machines properly support TDX and 4th gen doesn’t work. Such a machine on OVH costs ~$1500 per month. We are working on adding AMD SEV-SNP support which should help reduce the cost dramatically.
• Technically we can scale beyond 21 nodes and we are working on new cryptography to improve the scalability of chain signatures. At the same time, it is not clear that we need many more nodes in the short to medium term. From a spending perspective it makes sense to have up to 21 nodes for the time being.

SVRN:

In the current list of providers, the CHEAPEST option is OVH which incurs $1800 per node, which is then applied 2x for redundancy and again for monitoring =$5,400

• @Bowen found one for ~$1500 (i didn’t search myself), big W. operators / those who give “recommendations” really have to put in a lot of effort to find the best deals, because going down from $1800 to $1500 is $272,160 saving annually (x 3 for redundancy & monitoring x 12 months x 21 nodes + 20% margin), it’s not an insignificant amount. i heard that intel recently reduced prices of their new server cpus by a lot, i’m expecting hosting prices to drop sometime soon as well, so that could be looked into as well. if this proposal was made in good faith, the least you could do is minimize the sell pressure as much as possible before the product can generate its own revenue.
• 2x redundancy is ok, but depending on what the monitoring server has to do, maybe having the exact same $1500 spec is not required, but i dont have time to get involved too much so let’s assume this is actually needed
• i would like to keep the cost as low as possible, and it should’ve been prioritized since day one, because that’s literally millions of near of sell pressure that affects and will keep affecting every holder

Bowen:

We are working on adding AMD SEV-SNP support which should help reduce the cost dramatically.

W as always, amd has been providing much better performance with much better pricing, i think depending on the expected timeline the budget should be reconsidered, because again i don’t like having the burn so high

SVRN:

Based on my understanding, the screenshot that you are citing is out-dated and needs to be updated further, which I am sure the team will do in due course

seeing a PR in the repo, it seems Ethereum, Bitcoin, and Zcash are using chain signatures + light client, which is 3 chains, better than 2 but definitely not 27. i don’t consider chain signatures + wormhole, or PoA, as a benefit of MPC for near intents, because wormhole remains a weak point and it doesn’t matter if you use wormhole for everything or wormhole for receiving and chain signatures for sending, the weak point is not totally gone. but W change, happy to see that my time spent on forum led to improvement in docs. even if you do consider chain signatures + wormhole an added value, it’s still just 5 chains, can’t take full credit for near intents supported 27 chains.

SVRN:

The entire basis of making this proposal is from the point of view, supported by data, that paying a maximum of 1.2M NEAR per year, for the core infrastructure powering a system that has track to generate $20M and eventually $100M into token sinks is a worthwhile investment

then why not spend <10% of that $20M to fund that infrastructure. near intents has already made $10B in volume, if they can monetize, they can fund their infrastructure themselves, and maybe even buy back some $near tokens to keep the price up. or chain signatures can start charging a fee, that near intents (and other protocols using chain signatures) pay for. in my opinion, useful tech that secures hundreds of millions needs revenue, not external funding because it’s “critical infrastructure”. changing from NF grants to HoS incentives (basically grants, since nobody is allowed to join) is not the vision of sustainability that i have.

none of the above will change my vote, i still believe that the chain signatures network is too centralized and being gatekept way too much, but in the case it gets supported by other people, at the very least i want to reduce the amount of long term sell pressure on my bag. and even though treasury.near doesn’t fund anything as of now, i guess it’s supposed to become owned by house of stake if house of stake proves to be successful, so spending like 37% of these emissions on just MPC network technical operations alone (not even including development of MPC network or development of intents or omnibridge or financial / legal operations that are still funded externally, and mpc is responsible only for 3 or 8 chains out of 27 that are supported on near intents) is like, idk, 37% of treasury emissions seems like a high price to pay for a fraction of a fraction of near intents, at least until the apps have revenue to cover this expense.

instead, i’d like to see a proposal for increasing near intents fees, and when it’s clear how much value it actually brings, either intents as a company funds the mpc network, or that revenue goes to house of stake, which in turn funds the mpc network (not sure why have house of stake as an intermediary, but i wouldn’t be against it if they wanted to for some reason). or if there’s no way to solve centralization, high costs, and revenue is not enough and is not projected to be enough anytime soon, there is a hard but possible way to a shutdown (biggest contracts utilizing mpc on mainnet are upgradable afaik, or can be made upgradable with a protocol upgrade, teams utilizing them are very active in the ecosystem, majority of networks supported on near intents don’t even use near mpc). i’m not suggesting his be done, would definitely be horrendous for the entire ecosystem if this thing shuts down, but after 2+ years of development, $11b volume, it still relies on grants / incentives to run, and is short 37% of the entire treasury’s emission rate, and now the current sponsor (or not the current sponsor, but SVRN, not sure about your connection to the MPC project) wants to move this liability onto the holders?

also, the apps using mpc networks should always be ready for unexpected issues, such as outages on recommended cloud providers, which can bring the entire network down when passed the mpc threshold, or bad actors colluding to stop the network, which is not impossible with less than 10 nodes, no stake / slashing afaik, and all node operators being connected to one person / team that chose them. this is also one of the reasons i’m personally bearish on storing significant amounts of money on mpc-owned addresses.

tldr, my reason for not liking this proposal and voting against it when the voting starts:

• sell pressure from node operators
• not enough value provided (if there was enough value, there’d be revenue to cover the expenses, we have $11b volume, i hope i’m not being dumb to expect seeing some revenue by now)
• network is highly centralized, all this money goes to the people that someone handpicked, which introduces ways that this “someone” (a person or a team) can abuse the power of choosing who receives the incentives, and there is no published intention of the selection process changing in the future
• i don’t like that the proposal has ‘sustainable’ in its name, and promotes incentives / grants as a solution for maintaining a revenue-less product

i would vote for this proposal if:

• the amount is decreased by 4-5x (potentially possible with some optimizations, including usage of amd cpus, reducing requirements of the monitoring node, crypto optimizations that allow to run on cheaper lower-core CPUs, or even shared servers if the confidential virtualization tech supports nesting, i’m not really confident in this topic so will leave it to the knowledgeable people to optimize). also, not sure if the current hardware requirements will stay for when the network has 21 participants, from what i’ve heard about MPC networks, the scaling is far from free
• network is less centralized, a clear, unbiased, and decentralized process of node selection is created and used for onboarding the rest of the 21 nodes. ideally, something like how near validators work, so everyone with enough $near (or if staking is not implemented, reputation of running a validator node with high uptime, or something like that, that anyone can achieve, with no personal or business connection required) can participate. there can be concerns about someone running multiple nodes (same way as there are people running multiple validators today), this would need to be solved as well to maintain the security if the key shares are not stake-weighted (afaik they’re not)

Thanks to everyone in the community for your engagement over the past week with a number of constructive conversations and comments that have led to an optimized proposal we are pleased to share where you can track edits in this post.

The key themes that we heard over the past week centered on:

1. The economic design and underlying infrastructure costs associated with running a production MPC node.

   1. The resulting conclusion from these deep dive discussions arrived at the infrastructure costs alone being a bare minimum of $4,500 USD to run the three required nodes: 1.) a production mainnet node, 2.) back-up mainnet node, and 3.) a testnet node, all of which are required for the system. This represents the bare-bones, minimum cost in the cheapest hosting provider without contemplating any of the required software for security / monitoring, or the costs associated with people required to do the work.

   2. While not a material change, we have shifted the cost structure from $6,000 USD to $5,750 USD while retaining a 20% margin. In doing so, this reduced the per node incentive from 4,800 NEAR to 4,600 NEAR.

   3. We also discussed the idea of making the incentives payable in USDC rather than NEAR, to which we explained our stance in the comments expressing concern over consistent sell-side pressure on NEAR to facilitate the system, and the muted incentive that is provided by doing so, where the majority of the node providers are long NEAR and view the forward opportunity on USD value of the token to be much higher.

   4. Bowen pointed out in the forum that there are alternative hardware solutions from AMD on the horizon that offer material price advantages as compared to the Intel TEEs. These solutions will not be implemented within the production system for several quarters, but given the fact there will be future optimization opportunities for cost structure, we have implemented an Annual Program review which covers evolutions infrastructure and cost

2. We also reviewed and discussed in a number of comment threads, the decision for the go-to-market motion to be driven by the SVRN team, rather than having a full blown decentralized voting process out of the gate to select and de-select MPC nodes.

   1. We’ve thought long and hard about this decision, and ultimately concluded that the best approach is to progressively decentralize the approach, rather than boil the ocean.

   2. To this point, we are committed to revisiting the maturity of House of Stake in conjunction with the performance of MPC nodes over the first 12 month period, to assess whether we’ve reached a point of maturity that warrants opening a stake-based voting mechanism on MPC nodes included within the system.

   3. In the meantime, we will provide clear guidance regarding the selection criteria and new MPC node providers that join the system if the proposal passes

   4. This will not meet the expectations of all parties who have shared their feedback, however we feel confident that it is the right path forward.

3. Finally, there were a number of questions raised regarding the maturity of House of Stake to govern an economic policy vote of this nature.

   1. House of Stake went live less than 180 days and is rapidly maturing into a key governance forum and mechanism within the ecosystem.

   2. Bringing proposals that carry gravitas and are significant in nature build credibility within the system which will drive more NEAR token holders to participate in future proposals and votes.

   3. It is our duty as pioneers in the system, to lead by example and expect that by doing so we can help to steer the course for HoS to develop and mature.

In closing, I wanted to share a note of thanks to the community for your engagement and thoughtful discourse. We’ve done our best to internalize comments and provide a revised proposal which aims to address the feedback that we can, while understanding that based on some of the views expressed, this revision will not result in your support. We hope that everyone appreciates our genuine efforts to advance this proposal in a manner that is transparent for the community and thoughtful as stewards of the protocol itself.

Best,

Sal

Thanks for the update, Sal.

Since the payout mechanics are contentious, have you considered the program administrator recalculating payments monthly using real-time NEAR prices vs. 180-day trailing average?

And have you considered a hybrid payment structure where base operational costs are paid out in USDC and the 20% margin in NEAR for long-term alignment?

Hi Rika,

Yes we discussed this over the course of the week as we reviewed the payout mechanics in context of community feedback. Introducing a dependency in the system on a monthly basis will incur material operational overhead. As we compared approaches we aimed to align most closely with PoS / staking mechanics which are programmatic, protocol-defined and already widely supported, while introducing controls to govern and manage the short-comings of PoS systems, namely with regards to the amount of cost the protocol incurs on a run-rate annual basis in terms of inflation, relative to actual requirements to ensure strong economic security.

We had a number of conversations regarding the idea of paying out base fees in USDC or USDT on Near mainnet, rather than NEAR natively and for the same reasons that I’ve explained in previous comments, arrived at the stance that incentives designed in NEAR are the strongest and most directionally aligned.

Regardless of whether you land in support of the proposal or not, I do appreciate your thoughtful engagement in last week’s call, on X and through this forum.

Best,

Sal

Thank you so much, @SalTernullo for additional refinement of this proposal. In general I am in support of this proposal with these revisions.

I especially appreciate the inclusion of Service Organization Control (SOC) reporting (that you mentioned above) as a requirement for new operators. Leveraging third-party attestations is a gold standard for enterprise-grade infrastructure, as it provides the HoS with the necessary assurance that these businesses have the rigorous security and technology controls required for mission-critical protocol rails.

Some additional thoughts:

• Price Stability & Evaluation Period: I appreciate the commitment to evaluate the 180 day price average at the 6 month mark. While I initially suggested a 90-day window to ensure closer alignment with market value, I am satisfied with this trial period to gather data and revisit the logic during the first program optimization cycle. Keeping it simple in the beginning allows for an ease of implementation.

• The Selection Rubric & GTM transparency: Since @SVRN will lead the recruitment for the additional 11 slots using these SOC standards, I suggest that a clear Selection Rubric be published alongside the Month 1 Charter.
  Defining how the team will weigh factors like SOC compliance, geographic distribution, and technical history will provide transparency.

• Automated Reporting: It’s fantastic to hear that an “Automated Dashboard” is feasible for the first payout period! This is a vital tool for the HoS to verify SLA compliance objectively and will significantly reduce the manual administrative burden.

We will have NEAR MPC Proposal Livestream: With Sovereign and NEAR One
Discuss the House of Stake Proposal to Establish a Sustainable MPC Node Infrastructure Financing Program Funded via Protocol Emissions.

Monday, Feb 02
7pm UTC

It would be interesting if we got direct access to the discussions, so we can ask our concern “as a person”.

Hi Axia,
Thanks for the question, happy to clarify:

For now, consider the House of Stake Head of Governance as both responsible and accountable for House of Stake and for the Program Administrator role.

However, we all want to see House of Stake’s organizational structure and fund operations to evolve in 2026. This may include introducing dedicated roles responsible for program operations, either within House of Stake or through formally delegated operators or contributors.

Any such changes will be addressed through separate future proposals related to House of Stake’s organizational structure and do not affect the current accountability described above.

Hope this helps!

Conflict of interest violation warning. This is a direct conflict of interest and a clear governance violation when the proposer is voting for themselves. HSP-007: Establish a Sustainable MPC ...

In the Exhibit A image of the proposal’s published GitHub repo, the simulation pays more NEAR per node when the $3.0 ceiling is triggered.

Shouldn’t it be the opposite?

Nodes should receive less NEAR at higher NEARUSD price averages to guarantee a cap on the nominal amount they are being paid to prevent treasury.near from overpaying the nodes when NEARUSD is trading at higher levels. Right?

Or did I misunderstand something?

HSPs/hsp-007.md

## **Front Matter**

```yaml
hsp: 007  
title: Establish a Sustainable MPC Node Infrastructure Financing Program Funded via Protocol Emissions
description: Establishes a sustainable incentive program to fund MPC nodes supporting NEAR Intents using protocol emissions.  
author: Sal Ternullo, Kendall Cole  
discussions-to: https://gov.near.org/t/hsp-xxx-establish-a-sustainable-mpc-node-infrastructure-financing-program-funded-via-protocol-emissions/41984
status: Review
track: Decision  
type: Simple Majority  
category: Economic Governance   
stakeholders: MPC node operators, NEAR Intents developers, Chain Signatures users, NEAR token holders  
created: 2026-01-29 
requires: HSP-001
```

## Abstract

This proposal establishes a MPC Node Infrastructure Incentive Program funded via protocol emissions accrued to create infrastructure incentives and is governed by House of Stake. The program provides performance-based monthly compensation to up to 21 MPC node operators supporting NEAR Intents and Chain Signatures. Compensation is NEAR-anchored at a fixed rate per node, with payments executed on-chain from House of Stake wallets following off-chain SLA validation and calculations.

image-1769712307864-177rk87fl1600×173 68.4 KB

My opinion and voting reasoning fully explained in this X thread (still open for discussions)

Vini Barbosa |「 thecoding 」

HSP-007 is live for voting on @NEARGovernance The proposal is to "establish a sustainable MPC node infrastructure financing program" that is funded via ~10% of the treasury.near allocation (2.5%) from protocol emissions I'm leaning towards an AGAINST vote (253k veNEAR) 🧵+↓ pic.x.com/6EgY6JGob4

Thanks for flagging @Dacha.
Indeed, we did discuss how to approach conflicts of interest in this case. Result: No rules have been broken.
As we are getting ready to ratify an updated COI policy, the next GM HoS Community Call will be dedicated entirely to this topic.
More here: HSP-XXX: House of Stake - Conflicts of Interest Policy - #28 by AK_HoG

I really value your thoughts here, @vinibarbosa . In addressing your question about the ceiling cap price at $3.00/4,800 NEAR per Node, I totally missed reading that in the spreadsheet image, while the current proposal on Agora text does mention a consistent 4,600, and reinforced by @SalTernullo who did post this in this thread that all ceiling/floor/average would be consistent with 4,600 NEAR. @SalTernullo can you please clarify this, and it’s not a mistake? Thank you!

image902×516 11.3 KB

AK_HoG:

we did discuss

Who are in this miracle circle called by “we” and why the discussion is happening behind the closed doors?

Another thing that I would like to point out here as a strong reason to vote AGAINST this proposal in its current form (so we can later improve it) is that the 21 handpicked MPC node operators would be receiving higher NEAR-based monthly rewards than what the top 5 NEAR validators get from a 5% pool fee.

For the calculation:
#5 bitwise_1.poolv1.near | Ⓝ20M delegated | 5% fee | 4.90% APY (per near-staking)
→ Ⓝ20,000,000 x 0.049 = Ⓝ980,000 (near-staking estimated APY)
→ Ⓝ980,000 x 0.05 = Ⓝ49,000/year (validator’s fee)
→ Ⓝ49,000 / 12 = Ⓝ4,083

While beneficiaries of this proposal would receive Ⓝ4,600

So, I do agree that the Chain Signatures and NEAR Intents infrastructure is important to NEAR but I don’t see how it could be more important than the NEAR infrastructure itself.
Paying more protocol-based rewards to the former creates weird incentives and dynamics, imo.

I really don’t think I can agree with that, having NEAR and HoS best interests in mind, sorry.

image1054×491 59.4 KB

**

Too Rushed Proposal IMO
**
This is what i get from HSPs-001, and what im thinking Right now: im Voting AGAINTS this.

Process Flow

Idea - Before drafting, authors should discuss their idea on the governance forum to gauge interest and refine the concept.

Draft Submission - Author writes the proposal following the HSP template and submits it as a PR to the https://github.com/houseofstake/proposals repository. Once properly formatted, it receives an HSP number and is merged as Draft.

Community Discussion - The Draft HSP is discussed on the governance forum. Authors incorporate feedback and iterate on the proposal.

Review - When the author believes the proposal is ready, they move it to Review status. This signals that the proposal is complete and ready for formal evaluation.

Last Call - An editor moves the proposal to Last Call, setting a 14-day deadline. This is the final opportunity for community feedback before voting.

Voting - Proposal proceeds to an on-chain vote by veNEAR holders. Voting period is 14 days (this is a parameter on the voting contract which can only be changed by the security council). The proposal must meet quorum and approval thresholds defined in the House of Stake governance documents.

Final/Rejected - Based on vote results, the proposal becomes Final or Rejected.

The initiative, which first @SalTernullo proposed on 23 January, has not addressed several community concerns.

Then, on 6 February (exactly 14 days later) it was launched by the HoS administrator, without properly accounting for the time required for community discussions, reviews, and final calls within that same 14-day window.

I think some papers need to be addressed first, and we need proper discussions before implementing any changes to our treasury, especially regarding Yearly Budgets.

GM community, and thanks @beek520 for the feedback. I just want to clarify with some data.

This is what I get from HSPs-001

Please note that this document also states:
Last Call - Final review period before voting. This status may be shortened or skipped entirely.

Now, looking at the actual timeline for this proposal:

• First AMA: Jan 22
• Proposal first published: Jan 23
• Extensive forum Q&A: Jan 23–29
• Proposal update published: Jan 29
• Second AMA: Feb 02
• Additional forum Q&A: Jan 29–Feb 05
• Ongoing Q&A engagement: continuing since Feb 05

As of now, this proposal ranks 12th in engagement (!) of all time since the forum was established (2021), which is great to see.

I’m sharing this to add context and data around the process.
I’ll leave addressing the proposal-specific questions to the authors again.

Voting abstain

I feel uncertain about this. On the one hand, I really relate with the comments saying that the base layer infrastructure should be paid more than the “superfluous” infrastructure built on top of it.

But on the other hand, Intents is kind of the claim to fame right now. Without NEAR Intents, the tech wouldn’t be half of what it is.

I don’t really know if there is a game theory issue here with having a layer that isn’t the base layer be paid or valued higher. It feels intuitively off, even though investing in NEAR Intents is a really good idea. We should double down on the products that have product market fit, which NEAR Intents definitely does.

Vini, for the sake of completeness I am linking our thread from X here on this topic.

Sal Ternullo

@vinibarbosabr With all due respect, this is the essence of the debate. We are discussing what is the right incentive structure for specialized nodes based on their operating costs relative to standard validators, their top line revenue in near, and their margin (which is the element you are pic.x.com/ZCh9rBLC28

Update / Proposal Execution

This proposal has passed the House of Stake voting process on 2026-02-20:
https://gov.houseofstake.org/proposals/24

The program charter, the monthly reports as well as any challenges are available in the new thread HSP-007 Execution: MPC Node Infrastructure Financing Program.

Gm, @SVRN , congratualations on the first month completion and the great performance report by @AK_HoG .

I wanted to follow up with you, to see how your G2M strategy is moving forward to gradually on-board the remaining 11 MPC node operators? In your comments below, you mentioned that you would be posting the selection criteria for the new MPC node providers and also to see if you had any updates of any new MPC node providers that will be going online shortly? Tks!

image662×426 6.48 KB

GM SVRN AK_HoG. Congratulations on bootstrapping a successful initiative.
I noticed that of the 9/21 MPC operators, there are now 8/21.

We at Vitwit have been eager to participate and contribute to running an MPC node. Vitwit has been running validator and relayer infrastructure since 2018, for institutions, VC funds, and for ourselves. We have a proven track record of exceptional uptime alongside being the first responder to any mishap for partner ecosystems.
We are also one of the leading open-source contributor teams in Web3.

What would be the steps or the best way to share a proposal/Due Diligence to be a participant?

Hi @vitwit ,
Thanks for reaching out, and for your interest in joining the MPC operator set! Your team’s track record is indeed relevant to the kind of operational expertise we’re looking for.

Could you please send a brief email to [email protected]. From there, we’ll share the DDQ and walk you through the onboarding and evaluation process.

Looking forward to continuing the conversation!

Hi there ops team,

I sent an email to ops at houseofstake dot org but haven’t gotten a response yet so thought I’d post here: We’d love to help support the expansion of your node operator set if/when the time comes.

We’ve been running node infra since 2022, exclusively on our own hardware (owned, not rented), and have experience with MPC protocols including Arcium, Seal (Mysten Labs), TACEO, and Ika. We also have experience running a Near validator since last year.

Would love to connect!

-Max

Hi Max!
Thank you for sending a message through here as well, and sincere apologies for the delay in getting back to you. I’ve heard back from the program proposal authors and responded to your email. Thank you for your interest!