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
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.
i donāt know how many machines one operator has to manage, but hereās my configuration from one of your recommended providers:
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.
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.
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.
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.
@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
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
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.
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:
The economic design and underlying infrastructure costs associated with running a production MPC node.
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.
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.
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.
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
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.
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.
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.
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
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.
Finally, there were a number of questions raised regarding the maturity of House of Stake to govern an economic policy vote of this nature.
House of Stake went live less than 180 days and is rapidly maturing into a key governance forum and mechanism within the ecosystem.
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.
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.
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?
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.
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.
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.
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?
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!
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.
