NEAR said on October 15, 2026, that House of Stake-approved proposal HSP-007 moves its multi-party computation node infrastructure from discretionary grants to a standing funding program backed by protocol emissions. The announcement described 17 operating mainnet nodes and capacity to fund up to 21. It is an infrastructure financing development, with consequences for both operator reliability and tokenholder oversight.
Multi-party computation, or MPC, enables several participants to create signatures without one participant holding the complete private key. In NEAR's system, that signing layer supports transactions on other blockchains. Paying the people who operate it is therefore part of maintaining cross-chain access, even when the user experience hides those operators.
What the funding proposal actually changes
The published HSP-007 text establishes retrospective monthly compensation tied to service requirements. It says payments are calculated and checked off-chain, then explicitly authorized and transferred on-chain. The proposal does not change consensus rules, smart-contract logic, or the network's emissions rate.
That last point is important for NEAR token holders. Allocating existing protocol emissions is different from raising the issuance rate. Either approach has economic implications, but the document describes a treasury distribution program, rather than a new consensus upgrade.
The proposal sets a maximum of 4,600 NEAR per eligible node per month, with funding capacity for 21 nodes. Its maximum annual allocation is 1,159,200 NEAR. These are ceilings, not evidence that the maximum has been spent. Actual disbursements depend on eligibility, performance, and the approved calculation.
It also sets payment reductions for missed uptime requirements, public reporting, and a governance challenge process. Those mechanisms create a record against which token holders can compare service delivered with compensation paid. An approved budget alone cannot demonstrate that the program is meeting its objective.
Signing across chains is a distinct service
NEAR's technical documentation describes three ingredients in Chain Signatures: derivation paths that identify external accounts, a contract that receives signing requests, and an MPC service that produces signatures. A request identifies the transaction payload, the path, and the signing scheme. The resulting signature can then be submitted on the destination network.
This means a NEAR application can coordinate transactions involving an account on another chain. It does not mean those external assets stop depending on that chain's rules, fees, or confirmation process. The signing capability and final transaction settlement remain separate parts of the workflow.
The documentation also describes Chain Signatures as an outbound signing solution. Reading or proving external blockchain state requires other infrastructure. That boundary helps explain why a signing service is not interchangeable with every component described as a crypto bridge.
Developers must additionally guard against replaying signed transactions on an unintended compatible network. NEAR's documentation recommends distinct derivation paths for different chains. Funding node availability does not remove the need to construct and identify each requested transaction correctly.
Where the security assumptions remain
Near One's network overview explains that signatures require a threshold of cooperating operators. If too few are available, signing fails. The same overview distinguishes that availability problem from key compromise, which would require a threshold of participants colluding.
It also says operators vote on participant-set and threshold changes. These network-level decisions are a separate governance function from the tokenholder-controlled funding arrangement. More predictable compensation may support operator participation, but a funding vote is not itself a change to the signing threshold.
The overview describes distributed key generation without a trusted dealer and the use of trusted execution environments to restrict access to key material. It also points to public security audits. Those are meaningful engineering controls, but their presence does not establish that every application using the service is secure or that operators cannot encounter outages.
What the October announcement does and does not establish
NEAR's October 15 post says the approved arrangement will reward delivered performance, publish monthly results, and support an operator set of up to 21. That gives readers a testable operational claim: future reports should make eligibility, uptime assessments, and payments visible.
The announcement date should not be confused with the proposal's creation date or an independently verified date for its first payment. The public proposal was created earlier in 2026, and this article does not establish the governance execution block or a completed first payment batch.
The next useful evidence is therefore administrative as well as technical. Monthly reports can show whether compensation follows the rules; the signing contract can show which operators actually participate. Together, they can help readers judge whether a standing budget is producing durable infrastructure rather than merely replacing one funding label with another.