HSP-007: Establish a Sustainable MPC Node Infrastructure Financing Program Funded via Protocol Emissions

House of Stake Proposals
21

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.

6 Likes
22

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.

4 Likes
23

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

1 Like
24

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.

25

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.

6 Likes
26

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:

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

4 Likes
27

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.

1 Like
28

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.

2 Likes
29

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.

4 Likes
30

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.

3 Likes
31

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!

3 Likes
32

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.

image
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”

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.

1 Like
33

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.

6 Likes
34

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.

1 Like
35

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.

3 Likes
36

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?

2 Likes
37

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.

1 Like
38

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.

3 Likes
39

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.

1 Like
40

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

1 Like