{"proposals":[{"id":"dQv2iTC6Q3hb7c5z46WczhBNxqon6xbyFMcU6MzB34h","proposalType":"SimpleMajority","approvalThreshold":"5000","approvedAt":"2026-10-19T16:48:08.461Z","approverId":"arrr_tems.near","createdAt":"2026-10-19T16:31:36.841Z","creatorId":"svrnaiemissions.near","hasVote":true,"isApproved":true,"isRejected":false,"proposalDescription":"## Frontmatter\n\n```\nTitle: Establish a 24-Month Issuance Ramp to a 1.6% Target Rate Of NEAR Token Emissions\nDescription: Reduces NEAR's maximum protocol issuance from 2.5% to a target 1.6% target rate on a smooth 24-month per-epoch ramp, retaining the measured 90/10 split.\nAuthor: Sal Ternullo (SVRN), @salternullo\nDiscussions-to: https://houseofstake.org/proposals/cmuyez8j80000ru0sz6emyqpe\nStatus: Draft\nTrack: Decision\nType: Supermajority\nCategory: Economic Governance\nStakeholders: Validators, delegators, NEAR token holders, House of Stake\nCreated: 2026-10-07\nRequires: HSP-001\n```\n\n\n## Actionable Insights\n\nThis proposal reduces NEAR's maximum annual issuance from **2.5% to 1.6%** on a smooth 24-month per-epoch ramp of roughly 3.75 basis points per month (0.0375%), with the measured 90/10 staker-treasury split retained exactly.\n\n**Only one parameter changes.** No new emissions mechanism, no redirected validator rewards, no new spending program, no oracle, no administrator. This is the simplest protocol change that delivers a material reduction.\n\nModeling indicates the ramp avoids **11.8M NEAR of issuance over two years and 66.1M over six years** which is a supply 4.36% smaller than the status quo and worth roughly $153M at today's price, while gross staking yield declines **from 4.80% to 3.93% and 3.07%** across the first two years.\n\nThe cost to a token holder that is staking their assets is small and measurable. A holder staking 1,000 NEAR ends year two with about **20 fewer NEAR** than under the 2.5% inflation regime. In this context, NEAR needs to be worth **1.66% more, or 7.9 cents**, for that holder to be exactly whole.\n\nEvery holder who does not stake, which is currently 57.3% of supply, is better off immediately and with no offset at all.\n\nImpact on validator viability is real and disclosed: on measured ownership, **24 of 405 pools** lose economic self-sufficiency at spot at the target rate, however the measured evidence in Section 4 shows issuance was never sustaining the long tail in the first place.\n\nSolana ratified an equivalent change on **28 August 2026 (SGP-0002, 67.001% of stake)**. NEAR's proposed path reaches a **higher target yield (3.07% vs 2.25%) on a shallower yield cut (36% vs 62%)** while delivering a **deeper six-year supply reduction (4.36% vs 2.60%)**.\n\nEvery simulation below is measured against NEAR mainnet at block 216,701,043 on 22 September 2026, at a **spot price of $4.30** cross-checked across Kraken, Coinbase, and CoinGecko, and reproduces from public endpoints using the method in the Reproducibility section.\n\n## Abstract\n\nThis proposal reduces NEAR's maximum annual protocol emissions issuance from 2.5% to 1.6% over 24 months on a smooth per-epoch ramp, retains the measured 90/10 split exactly.\n\n**Why this, and why now.** On August 20 Illia Polosukhin withdrew the Sovereign Fund proposal and, in doing so, named the problem more precisely than forum discussions previously had. A fund that generates yield needs discretionary management to determine where capital allocation and determination of who receives it; both are judgment calls; and replacing validator rewards that are algorithmic today with an allocation, however well governed, converts security from something the protocol guarantees into something a human process decides. In his words, these are \"risks the protocol should not internalize.\" He asked that the alternatives raised in that thread be proposed on their own terms. This is one of them.\n\nSVRN engaged in that discussion on August 5 in support of the fund's direction and proposed a controls framework for it. The feedback that followed from validators, token holders, and finally from Illia persuaded us that the problem was discretion itself, not the controls around it. This proposal is what follows from taking that conclusion seriously and iterating on the idea. In this proposal we suggest a change to one parameter on a published schedule, with no fund, no administrator, no allocation, and nothing left for anyone to decide.\n\n**What this proposal does not do.** It creates no spending program, no eligibility test, no oracle, and no registry. Earlier drafts paired the ramp with a treasury-funded Node Floor guaranteeing machine-cost coverage for validators; every construction we tested required either a price oracle and an administrator, or a beneficial-ownership registry to resist Sybil farming, which is incompatible with the privacy architecture NEAR is building. The evidence that motivated the floor is retained in Section 4, because it is the reason the ramp is defensible. The mechanism is not.\n\n**It does not touch protocol revenue.** Intents fee-switch buybacks, and any other revenue removed from circulation, stay removed. Nothing in this proposal creates a path for that NEAR to re-enter the market, and nothing here should be read as reopening that question.\n\nEvery simulation below is measured against NEAR mainnet at **block 216,701,043** and reproduces from public endpoints using the method in the Reproducibility section.\n\n## Context\n\nThree measurements taken directly from mainnet drive this proposal.\n\n**First, the issuance split is 90/10.** Measured by observing total supply growth against treasury.near inflow over identical block windows of 7, 28, and 92 days: the treasury's share is 10.13% in every window, and gross realized issuance is 2.45%, slightly below the 2.5% cap because transaction fees are burned. This supersedes the commonly cited 96/4 figure.\n\nNote for implementers: the protocol_reward_rate config field returns 0/1 following the July 2026 network upgrade and must not be used to verify the split. Supply-drift measurement over an identical window is the reliable method.\n\n**Second, the long tail of the validator set holds almost no capital of its own.** We labeled all 406 active pools by owner identity, delegator count, and owner staked balance. In the 163-pool entry cohort between 30k and 60k of stake, the median operator runs 40,130 NEAR of delegated stake against 19 NEAR of its own, which is 0.05% of the capital. The median owner's liquid balance is 1.4 NEAR. Across the whole set the median owner self-stake is 128 NEAR.\n\n**Third, stake is leaving while the price rises, and that tells us something about what retains it.** NEAR has appreciated 86% in the two weeks before this measurement, from $2.31 to $4.30. Over the same fortnight the staking ratio fell from 46.92% to 42.71% as roughly 54.5M NEAR was unstaked, and the active set contracted from 424 validators to 406. Gross staking yield did not fall during that period; it rose, from 4.796% to 5.268%, precisely because the denominator shrank.\n\nThis matters for the central question this proposal is asked to answer. If yield were what retains stake, a period of rising yield would retain it. Instead stake left into price strength, and the proposal queue grew from 416 candidates to 459 — more candidates now wait for a seat than hold one. Stake responds to price and to the opportunity cost of liquidity, not principally to the emission rate. The active set stands at 406 validators, 100 block producers and 306 chunk-only.\n\n### The network measured on September 22, 2026\n\n| Metric | Value |\n| --- | --- |\n| Measurement block | 216,701,043 |\n| Total supply | 1,306,946,399 NEAR |\n| Total staked | 558,165,227 NEAR (42.71%) |\n| Active validators | 406 (100 block producers, 306 chunk-only) |\n| Proposal queue | 459 candidates |\n| Minimum active stake | 9,428 NEAR |\n| Issuance split | 90% to staking participants / 10% treasury (measured 10.13%) |\n| Realized gross issuance | 2.45% (below the 2.5% cap; fees burned) |\n| Distinct pool owners | 397; no owner controls more than 3 seats |\n| Median owner self-stake | 128 NEAR (entry cohort: 19 NEAR) |\n| Gross staking yield | 5.268% at 2.5%; 3.372% at 1.6% |\n\n## Problem\n\nNEAR emitted roughly $51M more per year than validator economics require, and continues to do so. The bootstrapping job that high issuance performed is largely complete: the network is established, the validator set is oversubscribed, and continued elevated issuance now adds sell pressure without the offsetting distribution benefit it once purchased.\n\n**Dilution is a transfer with deadweight loss.** Issuance beyond the security threshold transfers value from holders who do not stake to holders who do. Just over half of NEAR supply at 57.3% is not staked and receives nothing in return for that transfer.\n\n**Tax drag leaks value out of the network entirely.** Staking rewards are ordinary income in many jurisdictions, so a portion is sold to cover tax. At the roughly 17% effective drag estimated in the Solana debate, NEAR leaks about 20M in emissions per year`. This proposal reduces that leak by $8M to $17M annually. That value does not move between NEAR holders, it just gets absorbed by tax authorities.\n\n**Persistent issuance distorts the price signal.** At 2.5%, NEAR issues about 89,517 new tokens every day. In equity terms this resembles a company consistently selling shares in the open market indefinitely. Most charts and dashboards do not properly adjust for it. At the target rate, daily issuance falls to 57,291.\n\n## Approach\n\n**The ramp.** Maximum annual issuance declines linearly from 2.5% to 1.6% over 24 months, applied per epoch at roughly 3.75 basis points per month, with no step dates to anticipate or defend. The measured 90/10 split is retained exactly. A grace period of 90 days follows before the first basis point comes off, allowing wallets, exchanges, custodians, and staking providers to update disclosures.\n\n![image](https://api.houseofstake.org/api/upload/image/public/new/3b1d19a1-1620-4dba-99ce-b1d9c2242e69.png)\n\n*Figure 1. Maximum issuance and gross staking yield under the 24-month per-epoch ramp.*\n\n| Anchor | Issuance cap | Gross staking yield |\n| --- | --- | --- |\n| Adoption (M0) | 2.500% | 5.268% |\n| Month 6 | 2.275% | 4.622% |\n| Month 12 | 2.050% | 4.320% |\n| Month 18 | 1.825% | 3.847% |\n| **Month 24 (target)** | **1.600%** | **3.372%** |\n\n*Notes: ~3.75 bp/month, no step dates, staking ratio held at 42.71% as measured*\n\n## What This Means for NEAR Holders\n\nStaking rewards are a transfer from holders who do not stake to holders who do. Cutting issuance shrinks that transfer: a token holder staking receives fewer new tokens, and every holder's ownership share is diluted more slowly. Both sides are computable.\n\n### The breakeven for a token holder who is staking\n\nA token holders count grows at 0.9 × π ÷ staking ratio. Compounding the ramp monthly against the current system in which issuance stays at 2.5% forever:\n\n| Horizon | Cap | Gross yield | Shortfall | **Breakeven price move** | **At $4.30** |\n| --- | --- | --- | --- | --- | --- |\n| Today (M0) | 2.500% | 5.268% | - | - | - |\n| Year 1 | 2.050% | 4.320% | 0.434% | **+0.434%** | **+3.9¢** |\n| Year 2 (target) | 1.600% | 3.372% | 1.827% | **+1.827%** | **+16.2¢** |\n| Year 3 | 1.600% | 3.372% | 3.770% | **+3.770%** | **+16.2¢** |\n\nA token holder staking 1,000 NEAR ends year two with about 20 fewer NEAR than under 2.5% forever. NEAR needs to be worth 7.9 cents more for that holder to be exactly whole which is about 1.1% a year over three years.\n\nThe breakeven percentage does not depend on price. The cents figure does:\n\n| Scenario | Price | Breakeven price | Cents needed | Shortfall per 1,000 NEAR staked |\n| --- | --- | --- | --- | --- |\n| Bear (half of spot) | $2.15 | $2.186 | +3.9¢ | $42.85 |\n| Spot | $4.30 | $4.379 | +16.2¢ | $85.71 |\n| +25% | $5.38 | $5.473 | +9.8¢ | $107.13 |\n| +50% | $6.45 | $6.568 | +11.8¢ | $128.56 |\n| +100% | $8.60 | $8.757 | +15.7¢ | $171.42 |\n\n### Where the breakeven comes from\n\n![image](https://api.houseofstake.org/api/upload/image/public/new/b27cec35-7378-4b66-bf18-1315b9adcb72.png)\n\n*Figure 2. The price move required to make a token holder who is staking whole, and how much of it the supply reduction delivers on its own.*\\\n\nBy month 24 the ramp has issued 11.8M fewer NEAR, a supply 0.857% smaller than the current system. At an unchanged network valuation, a supply 0.857% smaller is a price 0.857% higher. So of the 1.827% a token holder who is staking needs, 0.857% arrives from the supply reduction itself, or a little over half, and the remaining 0.970% must come from the network being valued more highly.\n\nWe state that rather than assert that lower issuance pays for itself. Measured against the current state which holds 2.5% indefinitely, it does not quite do so for a token holder who is staking. Two things work in the holder’s favor beyond the table and neither is assumed in it: as yield compresses, some stake unbonds, and a lower staking ratio mechanically raises the yield for everyone who remains; and the current 2.5% rate is not a stable baseline, but a policy under active challenge.\n\n### The non-staking holder\n\nFor the 57.3% of supply that is not staked there is no offset at all. The full supply reduction accrues as avoided dilution of roughly $86 on a $10,000 position at the target rate with no price change whatsoever.\n\n### Cumulative effect\n\n| Horizon | Issuance avoided | Supply reduction | Value at spot |\n| --- | --- | --- | --- |\n| 2 years | 11.8M NEAR | 0.86% | $51M |\n| 3 years | 24.5M NEAR | 1.74% | $106M |\n| 6 years | **66.1M NEAR** | **4.36%** | **$284M** |\n\nNone of this is spent. It is simply not emitted.\n\n### Time is of the essence\n\nThe saving is a function of when the ramp starts. Measured over a six-year window:\n\n| Ratification delayed by | Issuance avoided | Forgone vs acting now |\n| --- | --- | --- |\n| 0 months | 66.1M NEAR | - |\n| 3 months | 62.8M NEAR | 3.3M NEAR ($14M) |\n| 6 months | 59.6M NEAR | 6.5M NEAR ($28M) |\n| 12 months | 53.0M NEAR | 13.1M NEAR ($56M) |\n\n**Every month of delay costs roughly $4.7M in emissions that could be saved.**\n\n## Why the Rate Was Never What Protected the Validator Set\n\nThis section is the evidence base for the most common objection to any issuance cut: that it will break small validators.\n\nThe table below counts the number of validators whose measured revenue, which is commission on their actual stake plus yield on their actual owner balance, covers machine costs at published benchmarks of $500/month for block producers and $200/month for standard nodes which are deliberately conservative. The finding below holds at any cost assumption we tested, including halving both figures, under which the 300-node level remains unreachable at every rate and every price.\n\n### Validator viability against issuance. \n*The dotted line shows the hypothetical in which every operator self-stakes the stake it actually runs; the gap between it and the solid lines is capital the long tail does not have.*\n\n| Issuance rate | Bear (2.15)|Spot(4.30) | +50% (6.45)|+100%(8.60) |\n| --- | --- | --- | --- | --- |\n| 2.5% (today) | 133 | 170 | 191 | 209 |\n| 2.0% | 118 | 159 | 178 | 197 |\n**| 1.6% (proposed target) | 105 | 146 | 169 | 182 |**\n| 1.0% | 77 | 118 | 143 | 159 |\n\n\n![image](https://api.houseofstake.org/api/upload/image/public/new/deb230f8-130b-430d-8b92-8bd49d724433.png)\n\n*Figure 3. Validator viability against issuance. The dotted line shows the hypothetical in which every operator self-stakes the stake it actually runs; the gap between it and the solid lines is capital the long tail does not have.*\n\nThree findings follow, and they are the reason this proposal is a rate change rather than a support program.\n\n**No issuance rate at or below 2.5% sustains 300 self-sufficient validators at any price tested**, including a doubling of the token. At today's rate and a doubled price, only 209 of 405 cover their own costs. The 300-node level is not reachable by adjusting the rate in either direction.\n\n**The long tail runs on delegation, not issuance against their own stake.** The *dotted hypothetical* reaches roughly 390 viable validators at spot, but only because it assumes operators own the stake they run. They do not, by a factor of about 700 so cutting issuance does not remove protection the tail was receiving, because the tail was not receiving it.\n\n**Therefore the inflation rate is the wrong instrument for validator support, in both directions.** Raising it would not fix the tail and lowering it does not break the system.\n\n## Risks and Limitations\n\n**Operators who hold no NEAR have no offset.** vadim_hom put this precisely in the Sovereign Fund discussion: a real share of the validator set holds no token at all, and for them an issuance reduction is pure downside; their revenue is being reduced, and they have no upside from price because they never held the asset, which our analysis confirmed. Median owner self-stake in the entry cohort is 19 NEAR. The breakeven analysis above does not apply to these operators; they lose roughly 36% of commission revenue. What we can say is this: their revenue is commission on delegated stake, and delegation follows service quality and fee competition rather than the protocol rate. Any discretionary alternative, i.e. a subsidy program, was rejected by this community and by the fund's author in writing; Solana accepted equivalent attrition three weeks ago; and an algorithmic support mechanism proposed separately would have our support, if one can be designed without an oracle or a registry.\n\n**Validator attrition is real.** On measured ownership, self-sufficient validators fall from 170 to 146 at spot and from 133 to 105 at the bear anchor, losses of 24 and 28 respectively. As a share of the set that is comparable to the 30-of-738 attrition Solana accepted in ratifying SGP-0002. The mitigating evidence is Section 4: these operators are largely sustained by delegation rather than by issuance. But this is a cost, and we do not present it as anything else.\n\n**Yield compression may reduce the staking ratio.** Gross yield falls from 5.268% to 3.372% at today's participation. The target figure sits above Solana's ratified 2.25% and in the range of major proof-of-stake alternatives, but the equilibrium staking ratio at that yield is not known with confidence.\n\nNote that the relationship runs the other way as well: a falling staking ratio raises yield, because the same staker share is divided among less stake. At a 30% participation rate the target yield would be 4.80%, above where NEAR sits today. Participation and yield are self-correcting within a wide band.\n\n**Constituency risk.** The electorate for a stake-weighted vote is composed of the people this compresses. Our answer is the breakeven analysis above, disclosed rather than buried. Two features of the current market make the case easier than it was a fortnight ago: the target yield is now 3.372% rather than 3.069%, because the staking ratio fell, and the breakeven move of 1.827% sits against a token that has just appreciated 86%. The cost is 7.9 cents on a token that moved roughly two dollars in two weeks.\n\n**Measurement bounds.** Owner balances are measured in the owner account, so operator capital held elsewhere is not counted; the effect is to understate operator capitalization, and the entry-cohort finding is large enough to survive a generous adjustment. Historical validator-set membership is not retrievable from public RPC because epoch information is garbage-collected.\n\n## Precedent\n\nEvery major proof-of-stake economy has attempted emissions reform. The record is consistent and this proposal is engineered against it.\n\n| Network and measure | Design | Outcome | Lesson |\n| --- | --- | --- | --- |\n| Cosmos Hub, Prop 848 (Nov 2023) | Halve max inflation 20% → 10%, single step | Passed 41.1% to 31.9%, 72.7% turnout | Breakeven evidence shipped with the proposal |\n| Cosmos Hub, Prop 868 (Jan 2024) | Push minimum inflation to zero | Rejected | Communities ratify cuts and refuse zero |\n| Solana, SIMD-0228 (Mar 2025) | Dynamic market-based emissions targeting stake participation | Failed at 37.8% vs 66.67% needed | Novel mechanisms and no operator floor lose badly |\n| Solana, SIMD-0553 (Aug 2026) | Resource-based fee burn | Failed to reach supermajority | Complexity loses even in a favourable window |\n| Solana, SIMD-0550 / SGP-0002 (Aug 2026) | Double the disinflation rate; one parameter | Passed at 67.001% vs 66.67% needed | Simplicity wins |\n\nThe most instructive pair is the last two. SIMD-0550 and SIMD-0553 were proposed by the same team, in the same window, to the same electorate. The change to the single issuance parameter passed and the one that restructured a resource-based fee mechanism did not.\n\n### NEAR against the schedule Solana just ratified\n\n![image](https://api.houseofstake.org/api/upload/image/public/new/6ad55a5f-287a-4d58-8f42-dcdd9bc2eb96.png)\n\n*Figure 4. NEAR's proposed path compared to SGP-0002, ratified 28 August 2026.*\n\n| Metric | NEAR (proposed) | Solana (ratified) |\n| --- | --- | --- |\n| Start → target rate | 2.500% → 1.600% | 3.82% → 1.50% |\n| Time to target | 24 months | 2.8 years |\n| Parameters changed | 1 | 1 |\n| Gross yield today → target | 4.80% **→ 3.07%** | 5.84% **→ 2.25%** |\n| Yield compression | **36.0%** | 61.5% |\n| Supply reduction, 6 years | **4.36%** | 2.60% |\n| Validators losing viability | 24 of 405 (5.9%) | 30 of 738 (4.1%) |\n\nNEAR arrives at a **higher target yield on a shallower yield cut while delivering a deeper proportional supply reduction**, because NEAR starts from a lower rate with a higher staking ratio. A delegator comparing the two networks after both schedules complete finds NEAR paying more.\n\n## End-to-End Value Hypothesis\n\n### Objective\n\nReduce maximum issuance to a 1.6% target on a schedule the market can verify epoch by epoch, and make it the final scheduled change.\n\n### Expected outcome\n\nHolders retain 11.8M NEAR over two years and 66.1M over six that would otherwise be emitted; the schedule is predictable and bounded; monetary policy stops being relitigated.\n\n### Dependencies\n\nThis proposal cannot take effect on a House of Stake vote alone. The issuance cap is a protocol parameter, and changing it requires validator adoption through the standard upgrade process, which is the same path the 2025 halving took, at 68.41% approval. House of Stake ratification is necessary, however validator adoption is ultimately what makes it binding. That two-step structure is deliberate: it means the people who operate the network must independently consent to the change, and it answers directly the concern that House of Stake's current participation level does not by itself constitute a mandate over protocol economics.\n\n## Key Performance Indicators\n\n- **Ramp integrity:** realized issuance versus schedule, per epoch.\n\n- **Set health:** raw and distress-filtered operator counts, queue depth, staking ratio.\n\n- **Supply outcome:** cumulative issuance avoided against the 2.5% current state.\n\n## Technical Specification\n\n```text\ncap(t) = 2.5% − 0.9% × min(t, 24)/24\n```\n\nwhere t is months elapsed from activation, interpolated per epoch. Activation occurs one full quarter after ratification. The 90/10 split is unchanged.\n\n## Treasury\n\nThis proposal does not make a claim on the protocol treasury or establish a budget request.\n\n## Backwards Compatibility\n\nThe ramp is a protocol parameter change requiring validator adoption. No other consensus logic changes, the 90/10 split is unchanged, and no existing contract or staking mechanic is modified.  HSP-007 continue under their own terms.\n\n## Security Considerations\n\nReducing issuance reduces the cost of acquiring stake-weighted influence at the margin. At the target rate NEAR's yield remains above the level Solana has ratified, and the 24-month schedule provides time to respond to any observed decline.\n\n**There is no trigger under which emissions increase.** The question was asked in the Sovereign Fund discussion whether there should be a security-budget floor at which emissions automatically resume. Our answer is no, and the reason is not indifference to the security budget. An issuance schedule that can rise is a schedule the market cannot underwrite: every institution pricing NEAR would have to price the probability of re-inflation, and every adversary would have an incentive to manufacture the conditions that trigger it. If the network ever concludes that the target rate is too low, the remedy is a proposal clearing the covenant's thresholds, a deliberate, public decision, not an automatic one.\n\n## Implementation Plan and Milestones\n\n1. **Grace period of one full quarter** after ratification.\n\n2. **Activate the ramp;** cap moves per epoch thereafter.\n\n3. **Quarterly transparency reports:** realized versus scheduled issuance, set health metrics.\n\n4. **target rate in force at month 24**\n\n## Budget & Resources\n\nNone requested. This proposal changes a protocol parameter and creates no program, no disbursement, and no administrative function.\n\n## Stakeholders\n\n- **Validators** gross yield compresses from 5.268% to 3.372%.\n\n- **Delegators** roughly 5.00% to 3.20% at the median 5% commission fee, remaining above Solana's ratified target.\n\n- **Non-staking holders**- dilution falls; the full supply reduction accrues with no offset.\n\n- **House of Stake**- ratifies, then governs the covenant thereafter; cannot bind validators, whose adoption is separately required.\n\n### RACI Chart\n\n| Activity / Decision | Responsible | Accountable | Consulted | Informed |\n| --- | --- | --- | --- | --- |\n| Prepare proposal, substantiate modelling, submit for voting | Sal Ternullo / SVRN | Sal Ternullo, HSP Author | Validators, delegators, protocol developers | HoS community |\n| Finalize technical specification, including grace period and activation conditions | Sal Ternullo / SVRN | NEAR One | Protocol developers; validators | HoS community; NEAR ecosystem |\n| Implement, test, and release the protocol upgrade | NEAR Protocol Working Group —   | NEAR One —   | Validators; House of Stake Security Council | HoS community; NEAR ecosystem |\n| Independently adopt the upgrade through the standard protocol process | Validator operators | Each validator operator, for its own adoption decision | Protocol developers | HoS community; NEAR ecosystem |\n| Coordinate activation readiness and publish the confirmed schedule | NEAR One —   | NEAR One —   | Protocol developers; validators | Wallets, exchanges, custodians, staking providers, tokenholders |\n| Monitor issuance against schedule, validator-set health, and cumulative issuance avoided | Sal Ternullo / SVRN —   | NEAR One —   | Protocol developers; validators | HoS community; NEAR ecosystem |\n| Publish quarterly transparency reports and verify completion at the target rate | House of Stake team —   | Sal Ternullo / SVRN —   | NEAR One, protocol developers, validators | HoS community; NEAR ecosystem |\n\n## Reproducibility\n\n**Split measurement.** Read the chain head and an earlier block from the same node; take total_supply from each header and treasury.near account state at both heights. The treasury share is the ratio of treasury inflow to supply growth over the identical window. We measured over 7-day, 28-day, and 92-day windows and obtained 10.158%, 10.130%, and 10.129%. Do not use protocol_reward_rate.\n\n**Validator set and ownership.** validators for the active set and proposal queue; per-pool view calls get_reward_fee_fraction, get_owner_id, get_number_of_accounts, and get_account_staked_balance for fees, ownership, delegator counts, and owner self-stake. All 406 active pools were labeled.\n\n**Historical staking participation.** Epoch validator sets are not retrievable from public RPC, but pool state is: get_total_staked_balance resolves against archival RPC at any height. We summed that call across the 150 largest current pools — 96.5% of stake today — at monthly block heights over twelve months, divided by total_supply from the header at each height, and paired each point with the CoinGecko daily close. Because the sample is defined by today's composition, it understates the level by roughly 2.2 points at the calibration point (40.55% sampled against 42.71% measured across all 406 pools); the band cited in Clause B is stated on the adjusted basis. The correlation and the direction of the relationship are unaffected by the offset, since it applies uniformly across the series.\n\n**Endpoints.** rpc.mainnet.near.org and free.rpc.fastnear.com; archival via archival-rpc.mainnet.near.org and archival-rpc.mainnet.fastnear.com. Non-archival endpoints garbage-collect epoch validator information, so historical set membership is not retrievable from them.\n\n**Datasets.** The full validator dataset and ownership map accompany this proposal.\n\n## Conflicts of Interest\n\nSal Ternullo is CEO of SVRN (OceanPal Inc., NASDAQ: SVRN). SVRN holds approximately 55M NEAR, 90+% of which is staked, composing 8+% of staked supply. SVRN operates NEAR validator infrastructure through third party infrastructure partners. SVRN authored HSP-007, the MPC Node Infrastructure Financing Program, and operates an MPC node that receives payments under that program. SVRN intends to vote in favor of this proposal with these disclosures standing.\n\n**What this proposal does and does not touch.** It does not alter HSP-007, does not touch the treasury that funds it, and creates no program from which SVRN could receive an allocation. There is no spending, no eligibility, and no administrator anywhere in it. The only thing it changes is a protocol parameter that applies to every token holder who stakes identically.\n\n**On SVRN’s position.** This proposal reduces the staking yield SVRN earns on its entire staked position from 5.268% to 3.372%, costing roughly 855,000 NEAR per year at the target rate. On the breakeven arithmetic above, SVRN's position requires the same 1.827% price move as every other token holder who is staking to be made whole, and SVRN is on the losing side of that arithmetic in exact proportion to its size.\n\n**On SVRN's accumulation.** It was argued in the Sovereign Fund discussion that SVRN's stated intent to accumulate a significant share of supply already absorbs several years of issuance at 2.5%, and that no reduction is therefore needed. We would put it the other way around. A public company's treasury allocation is not monetary policy; it can change at any board meeting and a network should not rely on it as if it were. A network whose new supply is absorbed by a single buyer has concentration risk, not health. And a lower issuance rate means SVRN absorbs less of the float over any horizon, not more, which is the opposite of what a company seeking to maximize its share of the network would propose, and which should reassure precisely the people most concerned about SVRN's footprint.\n\n## Copyright\nCopyright and related rights waived via CC0 1.0.\n\n\n\n","proposalId":"29","proposalTitle":"Establish a 24-Month Issuance Ramp to a 1.6% Target Rate Of NEAR Token Emissions","proposalUrl":"https://gov.near.org/t/hsp-xxx-establish-a-24-month-issuance-ramp-to-a-1-6-target-rate-of-near-token-emissions/42644","receiptId":"dQv2iTC6Q3hb7c5z46WczhBNxqon6xbyFMcU6MzB34h","rejectedAt":null,"rejecterId":null,"forVotingPower":"3287728662259630503621537893926","againstVotingPower":"15456460682700000001","abstainVotingPower":"1070572816045588991017908399","votingDurationNs":"1209600000000000","totalVotingPower":"5274745154783239928996539106458","quorumAmount":"7000000000000000000000000000000","status":"Finished","votingStartTimeNs":"1792428488461000000","votingCreatedAtNs":"1792427496841000000"},{"id":"7C7fdpsMFSZ1qgeje3ZpEB14pijG2ZwBrqWE2f5PEHLz","proposalType":"SimpleMajority","approvalThreshold":"5000","approvedAt":"2026-08-27T16:04:01.008Z","approverId":"arrr_tems.near","createdAt":"2026-08-26T14:46:01.923Z","creatorId":"tlaproposal.near","hasVote":true,"isApproved":true,"isRejected":false,"proposalDescription":"## Frontmatter\n```\ntitle: Establish House of Stake as Registrar for the NEAR Top-Level Account Namespace\ndescription: Establishes the NEAR TLA namespace root under House of Stake governance on behalf of NEAR tokenholders and appoints the Security Council as Registrar.\nauthor: @Ozymandius @Filmer @AK_HoG\ndiscussions-to: https://houseofstake.org/proposals/cmt8tyqcw0000o00s951a7d9j\nstatus: Draft\nTrack: Decision\ntype: Supermajority\nCategory: Technical Governance, Legitimacy & Engagement\nStakeholders: NEAR Tokenholders, House of Stake Foundation, House of Stake Security Council, nearaccounts.com Platform Operator, Users\nCreated: TBD\ncreated: 2026-08-25\n```\n\n\n## 1. Abstract\nWith the launch of **nearaccounts.com**, NEAR Top-Level Accounts (“TLAs”) will open for broader use, enabling new namespace economies to develop beneath them.\n\nAs TLAs may become an important asset of the NEAR ecosystem, the exceptional authority to create Top-Level Accounts requires a **durable and credibly neutral governance model**. In particular, this authority should be separated from the commercial platform operations built on top of the namespace.\n\nThis proposal establishes that NEAR’s top-level namespace root should be governed by NEAR Tokenholders. To implement this principle, it places **governance of the top-level namespace within NEAR House of Stake** (“HoS”) and appoints the **House of Stake Security Council as Registrar (“Registrar”)**, authorized to perform **Registrar Actions** in accordance with the House of Stake Constitutional Documents, and the Registrar Charter in Appendix A (“Registrar Charter”).\n\n**nearaccounts.com (“Platform Operator”)** will operate as a dedicated NEAR product, with its product team responsible for commercial and operational decisions. The team works closely with **NEAR AI, NEAR.com, NEAR Intents, and other ecosystem stakeholders** to develop the TLA namespace as shared infrastructure supporting NEAR’s broader ecosystem and economic success.\n\nOnce a TLA or sub-account is created, its authorization and use remain outside the Registrar’s control. The applicable on-chain authorization mechanisms determine who may act through the account. **Users retain full control over the accounts** they lease and the assets held within them for the duration of their lease, neither HoS nor the nearaccounts.com product team has any mechanism to redirect, freeze, or take custody of those assets.\n\n## 2. Payload\nThe House of Stake approves the following decisions:\n1. **Establish House of Stake as the governance authority for the NEAR Top-Level Account namespace root and designate the House of Stake Security Council as Registrar for the NEAR Top-Level Account namespace**.\n2. **Adopt the NEAR Top-Level Namespace Registrar Charter** in Appendix A, defining the permitted Registrar Actions and the Registrar's rights, duties, limitations, and safeguards.\n3. **Confirm the required signing authority changes** under which the House of Stake Security Council will assume control of NEAR’s Top-Level Account namespace root.\n4. **Recognize the expanded House of Stake Mandate** described in NEAR Foundation’s mandate update (Aug 2026).\n5. **Authorize and direct the House of Stake Foundation** to take the corporate, administrative, technical, and other implementation actions necessary to give effect to the decisions approved by this proposal.\n\n\n## 3. Context and Problem\nNEAR accounts are hierarchical by design. A Top-Level Account (“TLA”) can serve as the root for potentially large numbers of subaccounts and the economic activity built around them. TLAs have been a design feature of NEAR since day one, but their potential as an ecosystem-wide namespace layer has remained largely unleveraged.\n\n**Examples: Top-Level Accounts and Subaccounts**\nFor example, the Top-Level Account:\n`agent`\nmay be used to create subaccounts such as:\n`alice.agent`\n`bob.agent`\n`wallet.agent`\n\nThis capability will soon become broadly accessible through nearaccounts.com, allowing TLAs to be opened and used as namespaces by projects, businesses, communities, and other participants.\nThe exceptional authority to create TLA’s requires a durable governance model. At the same time, operating a successful namespace platform requires the ability to make product and commercial decisions efficiently.\nThis proposal therefore separates two fundamentally different responsibilities to balance the long-term interests of NEAR stakeholders:\n- **Protocol governance** should control the exceptional authority to create Top-Level Accounts and ensure that this authority is exercised in the interests of the NEAR Protocol and NEAR’s broader ecosystem, and in accordance with the House of Stake constitutional framework.\n- **Product operation** should retain the freedom to make decisions on namespace allocation, pricing, marketplace rules, recovery, customer experience, and business models, enabling the platform to evolve and contribute to the commercial success of the NEAR ecosystem.\n\n## 4. Approach\n#### 4.1 House of Stake as Protocol Registrar\nHouse of Stake provides the governance framework for NEAR's protocol-level Registrar function, with the House of Stake Security Council serving as Registrar. The authority to perform Registrar Actions is established through this proposal.\nThe Registrar account shall be operated by the House of Stake Security Council through the applicable multisig or threshold-signing arrangement.\n**This proposal does not restructure HoS governance.** It is an extension of HoS's substantive mandate, using an already-existing on-chain execution body to perform a narrowly defined technical function.\n**The Security Council members remain bound** by the applicable House of Stake Constitutional Documents, Foundation Legal Documents, the NEAR Top-Level Namespace Registrar Charter (Appendix A), and conflict-of-interest requirements.\nThe Security Council does not gain independent discretion over namespace allocation. Its role is to **execute valid Top-Level Account creation instructions** issued by nearaccounts.com through the approved process.\n\n#### 4.2 Protocol Implementation\nNo NEAR protocol change is required. The NEAR protocol designates a single account, registrar, as the only account able to create named Top-Level Accounts, and this restriction applies at every name length.\n\nThat account already operates a multisig contract. Implementation is therefore a change of membership rather than a rotation of keys. The House of Stake Registrar multisig is added as a member, the incumbent members are removed, the confirmation threshold is set to the value House of Stake adopts, and the FullAccess keys presently on the account are deleted.\n\nThe multisig’s membership model accepts an account as a member, so the Security Council can be added directly and confirm through its own governance process. No individual signer keys are placed on the Registrar account and no contract change is required.\n\nFollowing tokenholder approval of this proposal, execution requires coordination with the parties currently authorized to administer the Registrar account and any necessary security review.\n\n#### 4.3 Scope of Registrar Authority\nUnder this proposal, the principal permitted Registrar Action is the creation of a valid bare Top-Level Account in response to a valid creation instruction.\nFor example, the Registrar may create:\n`universe`\n`ai`\n`intents`\n\nOnce `universe` exists, accounts such as `alice.universe` are created and managed without further involvement of the protocol Registrar.\n\nCreating a TLA does not give House of Stake or the Security Council any authorization to act through, administer, or access the created TLA.\n\nThe Registrar therefore has no authority over:\n- subaccount leasing or administration;\n- registry records or NFT-based rights and entitlements;\n- leases or marketplace transfers;\n- recovery;\n- pricing or commercial terms;\n- business namespace administration;\n- customer relationships; or\n- user assets.\n\n#### 4.4 Platform Operator and the TLA Platform\nThe Platform Operator funds, develops, and operates nearaccounts.com through its product team.\n\nThis includes determining the platform’s product and commercial model, including allocation and eligibility rules, pricing and fees, marketplace functionality, recovery mechanisms, customer relationships, and business namespace products.\n\nThese activities are independent of the Registrar function. HoS and the Security Council have no authority over the commercial or operational management of nearaccounts.com.\n\n#### 4.5 Allocation and Registrar Execution\nnearaccounts.com determines when a namespace has completed the applicable process for creation.\n\nThis process may include submission, classification, publication, challenge, allocation, payment, compliance, or other operational requirements.\n\nOnce the process produces a valid creation instruction, the Security Council may perform the corresponding Registrar Action to create the Top-Level Account.\n\nThe Registrar verifies that the instruction satisfies the requirements established by the Registrar Charter but does not reconsider the underlying commercial or allocation decision.\n\n#### 4.6 Registry and NFT-Based Ownership\nAt nearaccounts.com, the registry serves as the on-chain system of record for namespace registration, lease rights, and lifecycle information.\n\nLeased names are represented as NFTs, with each token corresponding to a specific account name and the associated rights defined by the applicable platform contracts. The underlying accounts operate as keyless contract accounts. Each account authorizes actions against its own on-chain control set, which may be updated in response to applicable registry lifecycle events.\n\nThis architecture allows lease transfers, marketplace transactions, wallet authorization, and recovery to occur **without the Registrar or Platform Operator taking custody of account keys or assets**. Authorization to act through an account is determined by its applicable on-chain authorization mechanisms.\n\nThe architecture described in this section reflects the TLA Platform implementation as of the date of this proposal. It does not establish a governance requirement for the Platform Operator to maintain any particular registry, lease, account-authorization, or control-set architecture. The Platform Operator may modify, replace, or discontinue these mechanisms without a House of Stake Tokenholder vote, provided such changes do not expand the Registrar’s authority or otherwise modify the governance boundaries established by this proposal and the Registrar Charter.\n\n#### 4.7 Revenues\nThe Registrar is not a commercial operator.\nRevenues may arise from platform activities such as allocation, leases, renewals, marketplace activity, or business namespace services and may be collected and retained by the Platform Operator.\n\n## 5. End-to-End Value Hypothesis\n**Objective:** \nPut ultimate governance of the TLA namespace root in the hands of NEAR tokenholders while preserving Platform Operators’s ability to operate nearaccounts.com efficiently.\n\n**Expected outcome:** \nNEAR can open meaningful bare Top-Level Accounts through a credibly neutral Registrar governed by House of Stake, while nearaccounts.com can be developed with flexibility to achieve product-market-fit.\n\n**Dependencies:** \nRequired NEAR Namespace Root Multisig Update executed; production-ready Registrar infrastructure; Security Council procedures; production-ready TLA platform and contracts; security review and smart contract audits; and applicable House of Stake legal implementation.\n\n## 6. Key Performance Indicators\nThe proposal is successfully implemented when:\n1. the TLA root is placed within the approved HoS governance structure;\n2. the Security Council can perform the Registrar functions in Appendix A;\n3. HoS and the Security Council cannot control users' virtual assets; and\n4. Registrar activities are verifiable onchain.\n\nCommercial product KPIs may be set and adjusted by the nearaccounts.com team independently.\n\n## 7. Technical Specification\nThe technical architecture described below reflects the current implementation of the TLA Platform and is provided for explanatory purposes. Except for the protocol Registrar and the governance boundaries applicable to it, these technical components do not form part of the governance framework approved by this proposal. The Platform Operator may modify or replace the Platform architecture without a House of Stake Tokenholder Vote.\n\nThe architecture contains distinct authority layers:\n- **Protocol Registrar:**\nThe account designated as registrar_account_id can create bare Top-Level Accounts and is operated by the House of Stake Security Council. (Note: The platform contract repository also contains a contract that creates subaccounts beneath a Top-Level Account. It is a platform component, unrelated to the protocol Registrar described here.)\n- **Top-Level Account:**\nEach created TLA is an independent NEAR account and structural namespace root.\n- **Registry:**\nA central registry contract records namespace registration, lease rights, and lifecycle information used by the TLA platform.\n- **Leased Accounts:**\nSubaccounts may operate as keyless contract accounts associated with NFTs recorded through the registry. Each account determines authorization against its applicable on-chain control set.\n- **Lease Authority:**\nA separate platform extension may enforce lease lifecycle rules. It is not the protocol Registrar.\n- **Recovery:**\nA separate MPC recovery system and watcher quorum may authorize recovery actions independently of the Registrar.\n\n**References**\n[https://github.com/houseofstake/tla](https://github.com/houseofstake/tla)\n[https://github.com/houseofstake/tla-contracts](https://github.com/houseofstake/tla-contracts)\n[https://github.com/near/nearcore](https://github.com/near/nearcore)\n\n## 8. Backwards Compatibility\nThis proposal does not transfer **existing NEAR accounts**, applications, or subaccounts to House of Stake and does not modify their existing authorization or access arrangements.\nExisting arrangements remain unaffected unless separately modified through an applicable process.\n\n## 9. Security Considerations\nThe protocol Registrar represents a high-impact authority because control of the Registrar account enables the creation of bare Top-Level Accounts.\n\nThe principal safeguards are:\n- **Constitutional authority.** Registrar Actions are recognized as a defined Security Council authority under the House of Stake constitutional framework.\n- **Bounded Registrar Actions.** The Registrar Charter defines which Registrar Actions are permitted and establishes their conditions, limitations, and safeguards.\n- **Threshold execution.** Registrar Actions are performed through the Security Council's applicable multisig or threshold-signing arrangements.\n- **Removal of standing key access.** The Registrar account currently holds FullAccess keys in addition to its multisig members. A FullAccess key can create a Top-Level Account without any confirmation, so removing them is part of implementation rather than a hardening step that can follow it. Until they are removed, the threshold arrangement described above is not the only path to Top-Level Account creation.\n- **Separation of responsibilities.** Allocation, platform operation, registry ownership, lease enforcement, account authorization, recovery, and Registrar execution remain separate authority domains.\n- **No account or asset custody.** Performing a Registrar Action to create a TLA does not grant the Registrar authorization to act through or administer the created TLA and does not provide access to assets held within it.\n- **Transparency.** Registrar Actions should be publicly auditable against their corresponding authorization and creation instructions.\n- **Detailed signing, access-control, and operational procedures** are defined through the Registrar Charter and applicable Security Council procedures.\n\n## 10. Stakeholders / RACI\n\n| Activity                                                                            | Responsible (R)                  | Accountable (A)                     | Consulted (C)                                       | Informed (I)                           |\n| ----------------------------------------------------------------------------------- | -------------------------------- | ----------------------------------- | --------------------------------------------------- | -------------------------------------- |\n| Operate TLA Platform, including e.g. recovery services                              | Platform Operator                | Platform Operator                   | Namespace Holders                                   | Tokenholders, HoS Foundation Directors |\n| Define roadmap, business model and pricing, business terms and customer policies    | Platform Operator                | Platform Operator                   | Namespace Holders                                   | Tokenholders, HoS Foundation           |\n| Manage customer support                                                             | Platform Operator                | Platform Operator                   | Namespace Holders                                   | Tokenholders, HoS Foundation           |\n| Operate the protocol Registrar account through the approved threshold configuration | HoS Security Council (Registrar) | House of Stake Foundation Directors | Platform Operator                                   | Tokenholders                           |\n| Approve creation of new Top-Level Accounts                                          | Platform Operator                | Platform Operator                   | HoS Security Council (Registrar)                    | Tokenholders                           |\n| Create Top-Level Accounts on-chain, perform authorized Registrar Actions            | HoS Security Council (Registrar) | House of Stake Foundation Directors | Platform Operator                       | Tokenholders                           |\n| Create and administer subaccounts                                                   | Namespace Holder                 | Namespace Holder                    | Platform Operator                                   | Tokenholders                           |\n| Govern the Registrar Charter, definition of permitted Registrar Actions             | Tokenholders                     | Tokenholders                        | HoS Security Council (Registrar), Platform Operator | House of Stake Foundation              |\n\n\n*RACI Legend: Responsible (R): Performs the activity. Accountable (A): Ultimately accountable for the outcome and decision. Consulted (C): Provides input before decisions or execution. Informed (I): Kept informed of the activity or outcome.*\n\n## 11. Implementation Plan\nImplementation consists of three workstreams.\n\n**House of Stake**\n- Adopt this proposal and the NEAR Namespace Registrar Charter.\n- Complete any required mandate, legal, Security Council, and operating-procedure changes.\n\n**NEAR Protocol**\n- Add the House of Stake Registrar multisig as a member of the Registrar multisig, and confirm it can execute a request before relying on it.\n- Remove the incumbent members and set the confirmation threshold adopted by House of Stake.\n- Delete the FullAccess keys currently held on the Registrar account.\n- Perform these steps in that order. The FullAccess keys are removed only after the new Registrar configuration has been successfully verified, reducing the risk of losing administrative access during the transition.\n\n**TLA Platform**\n- Complete production deployment and security audits of the platform and related contracts.\n- Connect the namespace allocation workflow to Registrar execution.\n- Launch the applicable namespace products and reporting.\n\n## 12. Milestones\n\n| Milestone                                    | Timeline                                                            | Success Criteria                                                                                                                                                                                                                                                                             |\n| -------------------------------------------- | ------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| Mandate Updated, Proposal Ratified           | Early September 2026                                                | House of Stake adopts the proposal and Registrar Charter                                                                                                                                                                                                                                     |\n| Registrar Charter Implementation Complete    | After proposal approved                                             | Registrar Charter Implementation Complete                                                                                                                                                                                                                                                    |\n| NEAR Namespace Root Multisig Update Executed | After Registrar Charter implementation                              | House of Stake Registrar multisig added as a member of the Registrar multisig and proven able to execute a request; incumbent members removed; confirmation threshold set to the adopted value; all pre-existing FullAccess keys deleted, leaving only the approved threshold configuration. |\n| Registrar Rehearsed                          | After namespace root multisig update executed                       | Security Council executes at least one end-to-end creation request against testnet (or an equivalent dry run) using the approved confirmation process before acting on mainnet                                                                                                               |\n| TLA Platform Security Audit Complete         | Independent of the Registrar workstream; before TLA Platform Launch | Independent security audit of tla-contracts completed and material findings resolved, covering the subaccount minting contract, tla-registry, hos-wallet, hos-extension, mpc-recovery, wallet-impl-deployer, etc.                                                                            |\n| TLA Platform Launch (Mainnet)                | After audit completion                                              | Namespace allocation and creation workflow deployed and operational on NEAR mainnet                                                                                                                                                                                                          |\n| Registrar Operational                        | After both Registrar Rehearsed and TLA Platform Launch              | Security Council execution infrastructure live and able to receive valid creation requests from the launched platform                                                                                                                                                                        |\n| First Bare TLA Created                       | After Registrar Operational                                         | First TLA created through the approved process on mainnet                                                                                                                                                                                                                                    |\n| Reporting Operational                        | Concurrent with first bare TLA creation                             | Registrar actions and applicable revenues publicly reviewable on-chain                                                                                                                                                                                                                       |\n\n## 13. Budget & Resources\nNot applicable.\n\nNo standalone budget is requested. Should any House of Stake operational expenditure be required to perform the Registrar function in the future, this remains subject to the applicable budgeting and proposal procedures.\n\n## 14. Governance Framework Lifetime\nThis Governance Framework takes effect upon ratification and remains in force indefinitely unless amended, superseded, or terminated through the applicable House of Stake governance process.\n\nThe Platform Operator may modify the technical architecture, product design, operational processes, commercial model, allocation mechanisms, registry, leasing model, account-authorization mechanisms, recovery mechanisms, or other Platform components without a House of Stake Tokenholder Vote. Such changes do not amend or terminate this Governance Framework, provided they do not expand the Registrar’s authority or otherwise modify the governance boundaries established by this proposal and the Registrar Charter.\n\n## 15. Conflict of Interest\nThe proposal authors confirm that they have read and agree with the House of Stake Conflict of Interest Policy. The proposal authors confirm to not gain benefits from a decision on this proposal that are not proportionally available to other NEAR Stakeholders. \nThe Registrar shall not use its role to influence TLA allocation, pricing, commercial terms, or other decisions reserved to the Platform Operator. \nAny additional actual or potential conflicts shall be disclosed under the applicable [House of Stake Conflict of Interest Policy](https://docs.houseofstake.org/docs/structure/legal-documents/conflict-of-interest-policy).\n\n## 16. Copyright\nThis proposal is licensed under CC0 1.0 Universal.\n\n## Appendices\nAppendix A — NEAR Top-Level Namespace Registrar Charter\nAppendix B — Governance and Implementation References\n\n## Appendix A — NEAR Top-Level Namespace Registrar Charter\n### A.1 Purpose\nThis **NEAR Top-Level Namespace Registrar Charter (“Registrar Charter”)** defines the authority, duties, and limitations of the **NEAR Top-Level Account Registrar (“Registrar”)** within the governance framework of NEAR House of Stake (“HoS”).\n\nThe **House of Stake Security Council (“Security Council”)** acts as Registrar and is authorized to perform **Registrar Actions** in accordance with this Registrar Charter and the House of Stake Constitutional Documents.\nThe Registrar is an execution function. It administers NEAR’s protocol-level authority to create Top-Level Accounts (“TLAs”) but does not operate the TLA platform or govern individual namespaces after their creation.\n\n### A.2 Governance and Accountability\nThe Registrar operates under the authority of NEAR Tokenholders through House of Stake.\n\nThe Security Council shall perform Registrar Actions in accordance with:\n- the approved House of Stake proposal establishing the Registrar;\n- this Registrar Charter;\n- the House of Stake Mandate;\n- the House of Stake Constitutional Documents;\n- applicable Foundation Legal Documents; and\n- valid governance decisions adopted under those documents.\n\nSecurity Council members obtain no independent authority over the NEAR top-level namespace by virtue of acting as Registrar or being signers of the Registrar account.\n\n### A.3 Registrar Actions\nA Registrar Action is an on-chain action performed or caused to be performed by the Registrar within the authority granted under this Registrar Charter.\n\nThe Registrar may perform only the following Registrar Actions:\n\n#### A.3.1 Create Top-Level Accounts\nCreate previously non-existent bare TLAs on the NEAR Protocol where creation has been properly authorized under the applicable TLA governance and operational processes.\n\nFor example, the Registrar may create:\n`universe`\nwhich can subsequently serve as the root for accounts such as:\n`alice.universe`\n`bob.universe`\n\nThe Registrar’s authority over a TLA ends once the TLA has been successfully created, except for Registrar Actions strictly necessary to complete or verify that creation.\n\nCreation of a TLA does not grant the Registrar, HoS, or the Security Council authorization to act through, administer, or access the created TLA or assets held within it.\n\n#### A.3.2 Administer the TLA Root\nPerform the root-level actions necessary to bring a newly created TLA into service and to maintain the Registrar account itself, limited to:\n\na) funding a newly created TLA with the storage balance required for it to operate;\nb) setting the access key configuration of a TLA at or immediately after creation, so the account is left in its intended state;\nc) any action strictly necessary to complete or verify a creation under A.3.1; and\nd) maintaining the Registrar account's own membership, balance and configuration.\n\nThis section confers no authority over a TLA once it has been brought into service, and no authority over accounts created beneath it.\n\n#### A.3.3 Execute Valid TLA Creation Instructions\nWhere an approved platform process results in a TLA creation instruction requiring a Registrar Action, the Registrar may execute or cause that Registrar Action to be executed.\n\nThe Registrar shall execute the instruction where:\n1. the requested action falls within the Registrar’s authority under this Registrar Charter;\n2. the applicable process and technical conditions have been satisfied; and\n3. execution would not violate this Registrar Charter, applicable HoS governance, or applicable law.\n\nThe Security Council applies these criteria in determining whether to execute the requested Registrar Action. This determination need not be automated or enforced by smart contracts.\n\nThe Registrar does not assess or reconsider the commercial merits of the underlying platform decision.\n\n#### A.3.4 Protective Registrar Actions\nThe Registrar may suspend, delay, or take other root-level Registrar Actions reasonably necessary to respond to:\n- compromise or suspected compromise of Registrar authority;\n- a critical protocol or contract vulnerability;\n- malformed, fraudulent, or unauthorized creation instructions;\n- an active exploit or material security incident; or\n- another circumstance in which execution would create an immediate and material risk to the NEAR Protocol or the Registrar.\n\nProtective Registrar Actions may be used only to protect the integrity of the Registrar, the TLA root, or the NEAR Protocol. They shall not be used to override ordinary allocation decisions, commercial disagreements, or valid rights and authorizations established under the applicable platform and account mechanisms.\n\n#### A.3.5 Registrar Infrastructure\nThe Registrar may maintain and upgrade technical infrastructure required to perform Registrar Actions, provided such changes do not materially expand the Registrar’s authority or alter the governance boundaries established by this Registrar Charter.\n\nThe Registrar may select, authorize, instruct, and monitor qualified technical experts or infrastructure to execute Registrar Actions on its behalf. Delegating technical execution does not transfer or reduce the Security Council’s responsibilities as Registrar.\n\nAny change that would materially expand the Registrar’s authority, change who acts as Registrar, or alter the separation between the Registrar and TLA platform operation requires authorization through the applicable House of Stake governance process.\n\n### A.4 Registrar Duties\nIn performing Registrar Actions, the Security Council shall:\n1. act only within the authority granted by this Registrar Charter, and the applicable House of Stake Constitutional Documents and Foundation Legal Documents\n2. verify that the conditions applicable to a requested Registrar Action have been satisfied;\n3. safeguard the integrity and security of the Registrar and TLA root;\n4. maintain appropriate operational and security procedures;\n5. ensure that Registrar Actions can be publicly reconciled with the corresponding valid instructions; and\n6. report material incidents, rejected instructions, unauthorized attempts, or material deviations from normal operation in accordance with applicable House of Stake procedures.\n\n### A.5 Separation from TLA Platform Operations\n**nearaccounts.com and the associated TLA platform are operated as a NEAR product by the nearaccounts.com team (“Platform Operator”).**\nThe Platform Operator is responsible for determining and implementing the platform’s product, technical, operational, and commercial policies, including, as applicable:\n- namespace allocation processes and classes;\n- eligibility and application requirements;\n- pricing and fees;\n- marketplace rules;\n- leasing and renewal terms;\n- business models and commercial terms;\n- customer relationships;\n- registry operations;\n- account recovery mechanisms; and\n- business namespace functionality.\n\nThe Platform Operator may determine and modify these policies, processes, and technical mechanisms without approval by the Registrar or a House of Stake Tokenholder Vote, provided such changes do not expand the Registrar’s authority or otherwise modify the governance boundaries established by this Registrar Charter.\n\nThe Registrar does not approve, supervise, or replace the Platform Operator in these functions.\n\nWhere an approved platform process results in a valid TLA creation instruction, the Registrar’s role is limited to determining whether the conditions for the corresponding Registrar Action have been satisfied and, if so, executing or causing the Registrar Action to be executed.\n\n### A.6 No Account Administration Authority\nThe Registrar has no authority over the ordinary operation of a TLA or accounts created beneath it.\n\nIn particular, the Registrar shall not:\n- create or administer ordinary subaccounts on behalf of namespace holders;\n- determine or modify the rights or authorizations associated with TLAs or subaccounts;\n- hold or manage NFT ownership records on behalf of users;\n- operate the TLA registry;\n- control leased accounts;\n- manage wallet authorization;\n- approve marketplace transfers;\n- administer account recovery;\n- custody user assets; or\n- interfere with the lawful operation of a namespace.\n\nThese functions are governed by the applicable nearaccounts.com smart contracts, platform rules, account holders, and the NEAR Protocol.\n\n### A.7 No Custody of Accounts or Assets\nPerformance of a Registrar Action does not grant the Registrar authorization to act through or administer individual TLAs, leased accounts, or subaccounts, and does not provide access to assets held within them.\n\nWhere nearaccounts.com uses keyless contract accounts, each account determines authorization against its applicable on-chain control set. Registry lifecycle events may cause that control set to be updated in accordance with the applicable platform contracts and authorization mechanisms.\n\nNeither HoS nor the Security Council takes custody of user account keys or acquires access to user accounts or assets by acting as Registrar.\n\n### A.8 Neutrality\nThe Registrar shall remain neutral in performing Registrar Actions.\n\nThe Security Council shall not use its Registrar authority to:\n- favor or disadvantage particular applicants;\n- influence pricing or commercial terms;\n- reserve names for its own benefit;\n- influence marketplace activity;\n- obtain preferential access to namespaces; or\n- advance interests inconsistent with its obligations under House of Stake governance.\n\nAny conflicts of interest shall be handled under the applicable House of Stake Conflict of Interest Policy.\n\n### A.9 Accountability and Transparency\nThe Security Council is accountable to House of Stake for its operation of the Registrar.\n\nRegistrar activity is subject to the transparency, conflicts, security, and accountability requirements applicable to the Security Council.\n\nMaterial or repeated failure to comply with this Registrar Charter may result in governance action under the applicable House of Stake Constitutional Documents and Foundation Legal Documents.\n\n### A.10 Charter Amendments\nThis Registrar Charter may be amended only through the governance process applicable to the proposal under which it was adopted or another process authorized by the House of Stake Constitutional Documents.\n\nNo operational procedure, platform policy, technical implementation, or Security Council decision may override or expand the authority boundaries established by this Registrar Charter.\n\n## Appendix B – Governance and Implementation References\n### B.1 Purpose\nThis appendix identifies the governance and implementation documents that support implementation of this proposal.\n\n### B.2 House of Stake Mandate Update\nIn accordance with the House of Stake constitutional framework, the NEAR Foundation has the authority to define and update House of Stake's mandate.\nThe NEAR Foundation must confirm an updated mandate reflecting House of Stake's expanded responsibilities as Registrar of the NEAR Namespace.\n\nThe Mandate Update serves as explanatory documentation and provides the strategic context and governance rationale for this proposal. It does not amend or supersede the governance framework established by this proposal.","proposalId":"28","proposalTitle":"Establish House of Stake as Registrar for the NEAR Top-Level Account Namespace","proposalUrl":"https://gov.near.org/t/hsp-xxx-establish-house-of-stake-as-registrar-for-the-near-top-level-account-namespace/42548","receiptId":"7C7fdpsMFSZ1qgeje3ZpEB14pijG2ZwBrqWE2f5PEHLz","rejectedAt":null,"rejecterId":null,"forVotingPower":"3545187300305122820102611602871","againstVotingPower":"0","abstainVotingPower":"0","votingDurationNs":"432000000000000","totalVotingPower":"4888976013600908073440587210804","quorumAmount":"7000000000000000000000000000000","status":"Unknown","votingStartTimeNs":null,"votingCreatedAtNs":"1787755561923000000"},{"id":"7pH2ZgXZ36qWfWNvXF6ukgAyjZKeTrcC5jbmvh3YupJd","proposalType":"SimpleMajority","approvalThreshold":"5000","approvedAt":"2026-06-20T16:53:51.476Z","approverId":"arrr_tems.near","createdAt":"2026-06-18T16:58:19.843Z","creatorId":"anton-near-one.near","hasVote":true,"isApproved":true,"isRejected":false,"proposalDescription":"# Frontmatter\n```yaml\nhsp: TBD\ntitle: Remove the NEAR Developer Gas Rebate\ndescription: Eliminate the 30% developer gas rebate and direct all execution fee burn to the protocol.\nauthor: Anton Astafiev (NEAR One) - @bendersgreat\ndiscussions-to: TBD\nstatus: Draft\ntrack: Decision\ntype: Simple Majority\ncategory: Economic Governance\nstakeholders: Tokenholders, Developers, Protocol Contributors, NEAR Ecosystem\ncreated: 2026-06-15\n```\n\n# Abstract\n**This proposal removes the developer gas rebate from the NEAR Protocol by reducing the rebate rate from 30% to 0%.**\n\nUnder the current mechanism, smart contracts [receive 30% of gas fees burned during contract execution](https://docs.near.org/protocol/transactions/gas#gas-as-a-developer-incentive). This proposal redirects the full amount to protocol-level burn. The objective is to **strengthen token value accrual, simplify protocol economics, and retire an ecosystem subsidy** introduced during an earlier growth stage. The expected outcome is increased alignment between network usage and token value accrual while preserving NEAR's low-fee user experience and existing application business models.\n# Payload\nThe [protocol parameter governing developer rebates](https://github.com/near/nearcore/blob/master/docs/architecture/how/gas.md#contract-reward) shall be modified such that:\n```yaml\nburnt_gas_reward = 0\n```\n# Context\nNEAR introduced a developer rebate mechanism whereby smart contracts receive 30% of gas fees burned during contract execution. The mechanism was designed to create a protocol-native incentive for application developers and public infrastructure providers.  \nAt the time of introduction, ecosystem growth and developer acquisition were strategic priorities. The rebate allowed contracts to receive protocol-generated revenue directly from network usage.  \nBased on historical network activity, developer rebates have distributed the following amounts:\n\n\n| Month | Contracts Receiving Rebates | Rebate Upper Bound (NEAR) | Avg. Reward per Contract (NEAR)\\* |\n|---------|--------------------------:|--------------------------:|----------------------------------:|\n| 2025-06 | 2,224 | 61,371.86 | 27.60 |\n| 2025-07 | 6,477 | 65,161.09 | 10.06 |\n| 2025-08 | 8,660 | 48,868.57 | 5.64 |\n| 2025-09 | 71,867 | 24,679.61 | 0.34 |\n| 2025-10 | 223,698 | 25,509.46 | 0.11 |\n| 2025-11 | 79,182 | 24,343.86 | 0.31 |\n| 2025-12 | 65,594 | 21,432.89 | 0.33 |\n| 2026-01 | 4,807 | 20,120.05 | 4.19 |\n| 2026-02 | 4,161 | 18,254.92 | 4.39 |\n| 2026-03 | 3,510 | 19,926.33 | 5.68 |\n| 2026-04 | 4,414 | 6,197.22 | 1.40 |\n| 2026-05 | 4,526 | 7,231.52 | 1.60 |\n\n\\* Average reward per contract = `rebate_upper_bound_near / contracts_receiving_rebates`. Upper Bound is the maximum possible rewards distributed.\n\n\nOver the past 12 months, the average reward per contract/month ranged from **27.6 NEAR in June 2025 to below 1 NEAR** later that year, highlighting how quickly the developer rebate becomes diluted as rewards are spread across a growing number of contract instances. Even at its peak, the average rebate per contract represented only a modest revenue stream, suggesting that the mechanism is not a meaningful source of funding for most development teams.  \nSince its introduction, the NEAR ecosystem has matured significantly. Today, applications rely on a variety of revenue sources, including protocol fees, treasury assets, staking economics, token ecosystems, service revenue, and other business models. The developer rebate remains one of the few protocol-level subsidies embedded in network economics.  \nThis proposal evaluates whether the original rationale for the subsidy remains sufficiently compelling to justify continued diversion of fee revenue away from protocol burn.\n\n# Problem\nThe current developer rebate creates three challenges.  \n* First, it **reduces token value accrual** by redirecting 30% of eligible execution fee burn away from the protocol.  \n* Second, **it rewards gas consumption rather than economic value creation**. Contract compensation is determined by gas burned rather than user adoption, revenue generation, assets secured, or other measures of ecosystem value.  \n* Third, **it adds complexity** to the protocol's economics while providing limited value.\nThis becomes even more apparent as NEAR moves toward **sharded applications and user-owned contract deployments**. The rebate rewards the account that executes the contract, not necessarily the developer who wrote it. In a sharded contract future, execution may happen across thousands of contract instances instead of a single application-owned contract. As a result, rebate rewards become fragmented across the accounts running the code, making the mechanism significantly less effective at rewarding application developers.   \n\nGiven these limitations, it is worth reassessing whether a permanent protocol subsidy remains the best use of fee revenue.  \n\n# Approach\nThis proposal removes the developer rebate entirely.\nRather than distributing 30% of execution fee burn to contract accounts, all eligible execution fees will be burned according to the protocol's existing burn mechanism.\nAlternative approaches considered include:\n* **Maintaining the 30% rebate →** Doesn’t resolve the issues identified (see section “Problems”)  \n* **Reducing the rebate without eliminating it →** Reduces the economic impact, but preserves the additional complexity and incentive misalignment.  \n* **Redirecting rebate funds to a treasury or governance-controlled pool. →** Removes the economic impact, but preserves extra complexity, and associated governance overhead.  \n\nThe proposed approach is preferred because it is simple, transparent, minimizes protocol complexity, and maximizes alignment between network usage and token value accrual.\nA tradeoff of this approach is that contracts currently receiving rebate income will no longer receive that revenue stream. \nHowever, the proposal assumes that the ecosystem has matured beyond the need for protocol-level developer subsidies and that applications should primarily rely on adoption-driven business models rather than protocol-funded incentives.\n# End-to-end Value Hypothesis\n## Objective\nRemove the protocol-level developer rebate and direct 100% of eligible execution fee burn toward protocol burn.\n## Outcome\nTokenholders benefit from stronger alignment between network activity and token value accrual.  \nProtocol economics become simpler and easier to understand.  \nDevelopers continue to compete based on product quality, adoption, and sustainable business models rather than protocol subsidies.  \nThe ecosystem transitions away from a bootstrapping incentive toward a mature fee model.\n## Dependencies\n* **NEAR Protocol Upgrade Process:** Implementation requires the protocol upgrade process established by the NEAR Protocol and applicable governance procedures to modify the developer rebate parameter.\n* **NEAR House of Stake Governance Process:** The proposal must successfully complete the governance process defined in the applicable Constitutional Documents, including review by the Screening Committee, Security Council, and House of Stake Directors, and approval by tokenholders through a governance vote.\n\n# Key Performance Indicators (KPIs)\n* **Developer rebate rate** reduced from 30% to 0%.\n* **Successful protocol upgrade deployment.**\n* **Increase in protocol-level fee burn** attributable to removal of the rebate.\n* **No critical protocol incidents** caused by implementation.\n# Technical Specification\nModify the protocol economic configuration governing developer rebates such that:\n* **Current** developer rebate rate = 30%\n* **New** Developer rebate rate = 0% \n\nAll execution gas fees currently eligible for developer rebate shall instead follow the protocol burn mechanism.\n\nNo changes are proposed to:\n* gas pricing,\n* gas accounting,\n* transaction execution,\n* validator rewards,\n* staking economics,\n* user fee calculations.\n# Backwards Compatibility\nThis proposal changes protocol economics but does not change application interfaces, APIs, contract execution behavior, or user transaction flows.  \nExisting contracts will continue to function without modification.  \nThe proposal is not backwards compatible with respect to developer rebate revenue expectations.  \n# Security Considerations\n### Economic Risk\nSome applications may experience reduced revenue.  \nMitigation:\n* The rebate is removed uniformly across the ecosystem.\n* Existing business models remain unaffected.\n### Ecosystem Participation Risk\nSome developers may perceive reduced incentives to build on NEAR.  \nMitigation:\n* NEAR maintains low fees, strong developer tooling, and ecosystem support mechanisms.\n* Sustainable applications should rely on user-driven business models rather than protocol subsidies.\n### Governance Risk\nStakeholders receiving rebate income may oppose the proposal.  \nMitigation:\n* Transparent public discussion and publication of economic impact analysis before voting.\n# Stakeholders\n\n\n| Activity / Decision | Responsible | Accountable | Consulted | Informed |\n|---------------------|-------------|-------------|------------|----------|\n| **Proposal drafting** | NEAR One | NEAR One | Community | Tokenholders |\n| **Economic review** | Protocol Working Group | NEAR One | Developers, Validators | Tokenholders |\n| **Governance vote** | Tokenholders | Screening Committee/Security Council/HoSF directors | Community | Ecosystem |\n| **Protocol implementation** | NEAR One | NEAR One | Developers | Tokenholders |\n| **Deployment communication** | Governance Team | Head of Governance | Ecosystem Participants | Public |\n\n# Implementation Plan\nDefinition of Done:\n* Proposal approved through House of Stake governance process.\n* Required protocol change implemented.\n* Upgrade deployed to mainnet.\n* Developer rebate rate set to 0%.\n* Documentation updated.\n* Public communication completed.\n# Milestones\n\n\n| Milestone name | Target date | Deliverable | Success criteria |\n|----------------|-------------|-------------|------------------|\n| Governance Approval | June–July 2026 | Approved HSP | Proposal passes HoS vote |\n| Protocol Implementation | July 2026 | Code merged | Developer rebate parameter updated |\n| Mainnet Deployment | Any release after v2.13 | Protocol upgrade | Developer rebate disabled on mainnet |\n| Post-Implementation Report | 7 days after mainnet upgrade | Upgrade report | Change in protocol burn quantified and proven |\n# Budget & Resources\nNot applicable.\n# Conflict of Interest\nThe author has read and agrees with the House of Stake Conflict of Interest Policy.\nThe author declares no conflicts of interest except those disclosed during proposal discussion.\n# Copyright\nCopyright and related rights waived via CC0 1.0.\n","proposalId":"27","proposalTitle":"Remove the NEAR Developer Gas Rebate","proposalUrl":null,"receiptId":"7pH2ZgXZ36qWfWNvXF6ukgAyjZKeTrcC5jbmvh3YupJd","rejectedAt":null,"rejecterId":null,"forVotingPower":"4667203303407807881929719421008","againstVotingPower":"1818648129444391748400000012","abstainVotingPower":"0","votingDurationNs":"432000000000000","totalVotingPower":"5097162483222986944397858247627","quorumAmount":"7000000000000000000000000000000","status":"Unknown","votingStartTimeNs":null,"votingCreatedAtNs":"1781801899843000000"},{"id":"35DDgeoYuu8dqk82ZDGz8gLUWHuY26YYDiyCLkcjyF1w","proposalType":"SimpleMajority","approvalThreshold":"5000","approvedAt":"2026-06-16T15:22:41.524Z","approverId":"constantinos.near","createdAt":"2026-06-12T22:15:41.770Z","creatorId":"ak-hog.near","hasVote":true,"isApproved":true,"isRejected":false,"proposalDescription":"## Frontmatter\n\n```yaml\nhsp: TBD\ntitle: Establish House of Stake Operational Budget for July 2026 – June 2027\ndescription: Defines the operational budget required for House of Stake to function as a Treasury Governance Engine, covering governance operations, legal compliance, treasury management, and execution capabilities.\nauthor: House of Stake Head of Governance (@AK_HoG)\ntrack: Decision\ntype: Simple Majority\ncategory: Operations\nstakeholders: NEAR tokenholders, House of Stake Foundation (HoSF), proposal authors and stakeholders, NEAR Foundation (NF), NEAR ecosystem\ncreated: 2026-06-04\nrequires: House of Stake 2.0 Mandate Update, House of Stake Constitutional Documents and House of Stake Foundation legal documents\n```\n\n## Abstract\n\nThis proposal establishes the operational budget for House of Stake (HoS) for the next 12-month operating period, enabling it to function as an independent governance institution and NEAR's Treasury Governance Engine.\n\nThe budget focuses on governance operations, legal compliance, treasury management, and execution capabilities, ensuring that House of Stake can operate securely, transparently, and effectively.\nIt does not include costs for personell, product development, or any other cost items not listed in this proposal.\nThese costs have not been subject of a tokenholder vote and will continue to be covered by NEAR Foundation (NF).\n\nHouse of Stake is proposing a lean operating model that scales with governance demand: we establish independence in areas that are core to House of Stake's mandate, while leveraging existing NEAR Foundation infrastructure and services where appropriate. \n\n#### Budget Overview\n\n**Operational Budget:** \n**196,000 USD + 60,000 NEAR**\n\nUpon approval, this proposal authorizes the Head of Governance and the House of Stake Foundation to deploy the Operational Budget as outlined in this proposal.\n\nAny unused funds will remain in House of Stake's treasury.\n\n## Context\n\nHouse of Stake is entering its next phase: becoming an independent institution responsible for governing NEAR's economic policy and treasury.\n\nTo fulfill this role, House of Stake must establish the operational capacity required to execute governance decisions, manage treasury operations, ensure compliance, and operate securely.\n\nThis lean operating model scales with governance demand: we establish independence in areas that are core to House of Stake's mandate, while leveraging existing NEAR Foundation infrastructure and services where appropriate. \n\n## Problem\n\nHouse of Stake currently lacks its own dedicated operational infrastructure and budget.\n\nWithout this:\n\n* Governance decisions cannot be reliably executed\n* Treasury operations remain dependent on NEAR Foundation\n* Legal and compliance risks increase\n* Transparency and accountability are limited\n\n## Approach\n\nThis proposal establishes a minimum viable operational budget.\n\nIt focuses on:\n\n* Infrastructure only where necessary\n* Efficiency over duplication\n* Execution capability over complexity\n\n### Lean Governance\n\nThis is the first proposal to fund House of Stake operations from its own treasury, and it is intentionally lean.\n\nOur product is legitimate, transparent, and well-informed decision-making in the best interest of NEAR. As long as governance activity remains limited, the operational structure supporting it should remain lean as well.\n\nTo preserve treasury resources, House of Stake will leverage existing NEAR Foundation capabilities where appropriate, including:\n\n* Software and operational licenses\n* KYC/KYB infrastructure\n* Payment rails\n* Data and analytics\n* Legal support\n\nAt the same time, House of Stake will maintain independence in areas core to its mandate:\n\n* Legal compliance and financial reporting for the House of Stake Foundation\n* Treasury management and transaction security\n* Governance, operations, and IT support where independent capacity is required, or where NF resources are limited\n\nThis approach balances operational independence with efficient use of treasury resources.\n\n### Updated Operating Budget\n\nThe revised annual operations budget is:\n\n**196,000 USD + 60,000 NEAR**\n\nThis represents approximately **23.16% of the original budget request in April**.\n\nUnlike previous versions, this proposal covers a full 12-month operating period rather than the remainder of 2026. \n\n### Our Principle: Governance Should Breathe\n\nThese changes reflect a simple principle:\n\n* We do not build infrastructure that is not needed\n* We create systems that can grow and shrink with demand\n* We introduce mechanisms because they serve the ecosystem, not because governance frameworks are expected to have them\n* We keep costs low while remaining ready to scale when activity returns\n\n\n## End-to-end Value Hypothesis\n\n#### Objective\n\n* Start establishing independent infrastructure in a lean, cost efficient way\n* Enable reliable execution\n* Ensure compliance and security\n\n#### Outcome\n\n* Lean governance institution\n* Spending discipline\n* Executable decisions\n* Functional independence\n* Transparent reporting\n\n#### Dependencies on pending/upcoming proposals\n\n* None\n\n## Key Performance Indicators (KPIs)\n\n### KPIs\n\n**Execution Reliability:** ≥95% of voting processes completed end-to-end on schedule; with financing and ops support in place.\n\n**Transparency:** 100% of required reports published in full and on time; 100% of delays communicated with clear updates within 48 hours.\n\n**Compliance Readiness:** 100% adherence to legal, regulatory, and reporting requirements (including Cayman Foundation obligations); zero compliance breaches at HoS Ops team.\n\n**Security Robustness:** 0 security breaches impacting treasury funds or governance/data infrastructure.\n\n### Reporting Cadence\n\n**Quarterly:** Comprehensive report covering KPIs, budget usage, treasury status, operational performance.\n\n**Yearly:** Full annual report, including audited financial report, on-chain records, vendor disclosures, and overall performance.\n\nMore details see section \"Milestones & Implementation Plan\"\n\n## Technical Specification, Budget & Resources\n\n#### Budget Breakdown\n\n(all figures in USD/NEAR '000)\n\n| Category                   | Description                                                          | Budget USD      | Budget NEAR  |\n| -------------------------- | -------------------------------------------------------------------- | ----------- | ----------- |\n| Team                       | HoS Ops Manager                                                      |  | 60.00     |\n| Security & Smart Contracts | Covered through proposal-specific budgets or NEAR Foundation support | $0.00       | |\n| Legal & Compliance         | House of Stake directors, accounting services and legal counsel      |  $142.00   | |\n| IT & Infrastructure        | IT Services                       | $54.00       |\n| Data & Insights            | Covered through NEAR Foundation infrastructure                       | $0.00       | |\n| Treasury & Custody         | Multisig wallet management and treasury infrastructure         | $0.00   | |\n| Compliance Tools           | Covered through NEAR Foundation infrastructure                       | $0.00       | |\n| Software                   | Covered through NEAR Foundation infrastructure                       | $0.00       | |\n| **Total Ops Budget NEAR**       |                                                                       | | **60.00** |\n| **Total Ops Budget USD**       |                                                                      | **$196.00** | |\n\n\n\nApplies to a full 12-month operating period.\nAll estimates are intentionally tight and include no contingency buffer.\nSome software, service, and license agreements may extend beyond July 2027 due to annual contract terms. Where such commitments can be covered within the approved budget, they are considered authorized under this proposal.\nShould additional funding be required, House of Stake will coordinate with NEAR Foundation where appropriate and return with a separate proposal for tokenholder approval.\n\n\n## Buffer & Risk Management\n\nThe operational buffer has been removed.\n\nNEAR Foundation has confirmed it can support genuine emergency situations if required.\n\nAny additional operational costs resulting from future funding proposals should be included, justified, and approved as part of those proposals directly.\n\n## HoS Skin-in-the-Game (Co-Funding Pool)\n\nThe Skin-in-the-Game mechanism has been removed from this proposal.\n\nThis is not because the mechanism itself lacks merit. Rather, at this stage it remains unclear whether, when, and to what extent protocol revenues will be distributed through House of Stake in the foreseeable future.\n\nRather than implementing a mechanism without a clear use case, House of Stake believes it is better to revisit the concept when ecosystem conditions justify it.\n\n## Backwards Compatibility\n\nNo protocol changes.\n\n## Security Considerations\n\nMitigations include:\n\n* Treasury management through dedicated custody infrastructure\n* Independent compliance and financial reporting\n* Legal oversight\n* Transparent reporting\n* Dedicated governance and operational support\n* Use of established NEAR Foundation infrastructure where appropriate\n\n## Stakeholders\n\n* NEAR tokenholders\n* House of Stake Head of Governance, team and Foundation directors\n* Proposal authors and stakeholders\n* NEAR Foundation\n* NEAR Ecosystem\n\n## Milestones & Implementation Plan\n\n* June 2026: Forum discussion\n* June 2026: Voting\n* Upon approval: Activation of lean operating model and treasury\n* Upon approval: Continued use of shared NEAR Foundation infrastructure and services where appropriate\n* Upon approval: Continued operation of independent treasury management, compliance, and governance functions\n* Quarterly: Reporting on KPIs, budget utilization, and governance activity\n* Q2 2027: Annual review and follow-up budget proposal\n\n## Team & Accountability\n\nRACI – Budget Responsibility & Decision Framework.\n\n| Category                   | Responsible                   | Accountable              | Consulted                                                | Informed     |\n| -------------------------- | ----------------------------- | ------------------------ | -------------------------------------------------------- | ------------ |\n| Core Infrastructure        | HoS IT                        | Head of Governance       | Ops Manager, BuilderOps, NEAR Dev                        | Tokenholders |\n| Security & Smart Contracts | HoS IT                        | Security Council         | NF Dev, auditors, relevant domain experts (case-by-case) | Tokenholders |\n| Legal & Compliance         | Ops Manager                   | HoS Foundation Directors | External legal counsel                                   | Tokenholders |\n| IT & Infrastructure        | NEAR Foundation / HoS IT      | Head of Governance       | NF IT, auditors                                          | Tokenholders |\n| Compliance Tools           | NEAR Foundation / Ops Manager | HoS Foundation Directors | Legal, compliance providers                              | Tokenholders |\n| Treasury & Custody         | HoS IT, Ops Manager           | HoS Foundation Directors | Security Council, legal advisors                         | Tokenholders |\n| Software & Subscriptions   | HoS IT                        | Head of Governance       | n/a                                                      | Tokenholders |\n\n### Implementation Notes\n\n* **Tokenholders** remain the ultimate authority through governance\n* **Directors** ensure legal and fiduciary accountability\n* **Head of Governance** ensures alignment with mandate and priorities\n* **Ops Manager** ensure execution and coordination, \n* **HoS IT:** Service provider with dedicated NEAR and security expertise, hiring completed\n* **Additional Oversight Layers:** Sensitive categories (treasury, legal, compliance) include additional oversight layers (Security Council, auditors, domain experts)\n\n**Functional Independence**\n\n*a) Shared Infrastructure:* Where software, licenses, or operational services already exist within the NEAR Foundation and provide a cost-efficient solution, House of Stake may continue using them.\n\n*b) Governance Independence:* House of Stake maintains independent authority over governance processes, compliance obligations, treasury oversight, and decision execution.\n\n*c) Treasury & Security:* Treasury management and transaction security remain under House of Stake control through dedicated treasury infrastructure and governance processes.\n\n*d) Scalable Operations:* Operational capacity should expand or contract based on governance demand, ensuring resources remain aligned with ecosystem needs.\n\nFor this proposal, the Head of Governance is authorized to select vendors based on best fit (quality, security, cost-efficiency). Vendor selections and key details will be disclosed in quarterly reports.\n\n## Governance of Continuation\n\nApplies to the 12-month operating period following approval of this proposal (July 2026–June 2027)\n\nFuture budget requirements should continue to reflect actual governance demand and operational needs.\n\n## Conflicts of Interest\n\nThe author of this proposal serves as Head of Governance at House of Stake and is contracted by the NEAR Foundation, including for activities related to the implementation of this proposal.\n\nThe proposal is aligned with [House of Stake's mandate](https://gov.near.org/t/house-of-stake-2-0-season-1-mandate-updates/42142). To mitigate any potential conflict of interest, the Head of Governance will abstain from voting on this proposal. All relevant disclosures and potential benefits associated with this proposal are subject to House of [Stake's Conflict of Interest Policy](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-012-coip.md) and [Code of Conduct](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-013-coc.md).\n\n## Changelog\n\nThis proposal is an update to the budget proposal published on May 4, 2026.\n\nThis revision includes:\n\n* Reduced operational budget to $196.00k plus 60.00 NEAR\n* Removed the operational buffer\n* Removed the Skin-in-the-Game co-funding mechanism\n* Updated the proposal from a Season #1 operating model to a full 12-month operating period\n* Clarified use of shared NEAR Foundation infrastructure and services\n* Updated budget allocations to reflect current governance demand\n* Simplified reporting requirements (no buffer, no co-funding allocation)\n* Updated implementation plan and accountability framework\n* Revised functional independence model to focus on governance, treasury, and compliance independence while leveraging shared infrastructure where appropriate\n\n## Copyright\n\nCopyright and related rights waived via CC0 1.0.\n","proposalId":"26","proposalTitle":"Establish House of Stake Operational Budget for July 2026 – June 2027","proposalUrl":null,"receiptId":"35DDgeoYuu8dqk82ZDGz8gLUWHuY26YYDiyCLkcjyF1w","rejectedAt":null,"rejecterId":null,"forVotingPower":"2122930494514592010983812422082","againstVotingPower":"12577862703264238700000002","abstainVotingPower":"0","votingDurationNs":"1209600000000000","totalVotingPower":"5614401736726675088255704329587","quorumAmount":"7000000000000000000000000000000","status":"Finished","votingStartTimeNs":"1781623361524000000","votingCreatedAtNs":"1781302541770000000"},{"id":"HnqcJmsSaLNMM32qexwfNPbXNTWxMF3p8BdksdX8wvBv","proposalType":"SimpleMajority","approvalThreshold":"5000","approvedAt":"2026-03-11T21:28:50.854Z","approverId":"gauntletgov.near","createdAt":"2026-03-11T21:25:53.751Z","creatorId":"hackhumanity.near","hasVote":true,"isApproved":true,"isRejected":false,"proposalDescription":"\u001e\u001e\u001e\u001e\u0001\u0001## Resolution to Ratify a Bundle of Six Constitutional Documents\nThis single vote ratifies a bundle of the six NEAR House of Stake Constitutional Document HSPs listed below.\n\n1. [HSP-008 Constitution](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-008-constitution.md)  \n1. [HSP-009 Proposals and Voting Procedures (PVP)](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-009-pvp.md)  \n1. [HSP-010 Screening Committee Charter (ScrCC)](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-010-scrcc.md)  \n1. [HSP-011 Mission Vision Values (MVV)](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-011-mvv.md)  \n1. [HSP-012 Conflict of Interest Policy (COIP)](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-012-coip.md)  \n1. [HSP-013 Code of Conduct (CoC)](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-013-coc.md)  \n\nIf ratified, these six NEAR House of Stake Constitutional Documents will take effect immediately upon confirmation of the result, superseding any interim versions currently in place.\n\n\n## The Constitutional Document Bundle\nTogether with the Foundation Legal Documents, these six documents establish a community-ratified governance framework for NEAR House of Stake.\n\nBy defining authority boundaries, roles, and procedural mechanics, they provide institutional clarity, reduced ambiguity, and predictable governance operations to facilitate decision-making in the best interest of the NEAR Ecosystem.\n\n\nOperating within the scope of the Mandate and the NEAR House of Stake Foundation Legal Documents, they set the rules of the governance system, not policy outcomes. Together they expand and clarify existing governance bodies, define the proposal lifecycle, and establish shared values, behavioural standards, and conflict of interest principles. \n\nThe Documents provide a lean structure that reflects NEAR House of Stake's current capacity, avoiding governance debt. They also provide for evolution through future Tokenholder vote.\n\n\n### Why Bundle the Six Documents\n\nPartial ratification could create inconsistencies, ambiguity in authority, or governance risk. Bundling ensures a complete framework can operate from the moment of ratification.\n\n## The Six NEAR House of Stake Constitutional Documents\n\n### Constitution\n\nIt establishes the foundational governance framework, defining authority boundaries and legal subordination to the Foundation Legal Documents, embedding transparency and Removal for Cause, providing dispute resolution through the Screening Committee, and clarifying proposal execution limits and amendment through the PVP.\n\nSee: [Proposal link](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-008-constitution.md), [Forum discussion](https://gov.near.org/t/hsp-008-near-house-of-stake-constitution/42018)  \n[`Git Blob Hash: c28fe3ea7d0fb40ed90578ceed2cd7b6d5bac21b`]\n\n### Proposals and Voting Procedures (PVP)\n\nIt establishes the governance mechanics for how proposals are authored, reviewed, screened, voted, vetoed, and executed within NEAR House of Stake. It defines the HSP structure and lifecycle, sets quorum and voting thresholds, and governs the establishment and amendment of Constitutional Documents.\n\nSee: [Proposal link](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-009-pvp.md), [Forum discussion](https://gov.near.org/t/hsp-009-near-house-of-stake-proposals-and-voting-procedures/42019)  \n[`Git Blob Hash: 4e900e97dffc32e91a997cb5b9715f3e586f7b7a`]\n\n### Screening Committee Charter (ScrCC)\n\nIt establishes the authority for the Screening Committee to screen and interpret proposals for constitutional and mandate alignment, and to oversee Endorsed Delegates. It requires transparent publication of rationales.\n\nSee: [Proposal link](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-010-scrcc.md), [Forum discussion](https://gov.near.org/t/hsp-010-near-house-of-stake-screening-committee-charter/42020)  \n[`Git Blob Hash: 28364b2299ad03bf93d65308b4ab45af46a8217d`]\n\n### Mission Vision Values (MVV)\n\nIt establishes the normative alignment framework guiding governance evaluation and decision-making. It serves as an evaluation reference for the Screening Committee, Delegates, and AI governance tools.\n\nSee: [Proposal link](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-011-mvv.md), [Forum discussion](https://gov.near.org/t/hsp-011-near-house-of-stake-mission-vision-values/42052)  \n[`Git Blob Hash: df110e54901fd1b2717e6512450d9904cbf7298f`]\n\n### Conflict of Interest Policy (COIP)\n\nIt establishes a principle-based framework for identifying, disclosing, and managing conflicts of interest in governance participation, using self-assessment and disclosure as the primary mechanisms, and provides guided participation standards rather than mandatory recusal.\n\nSee: [Proposal link](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-012-coip.md), [Forum discussion](https://gov.near.org/t/hsp-012-near-house-of-stake-conflict-of-interest-policy/42055)  \n[`Git Blob Hash: fe2684efcc9506b74a17ad0fb855bea7641aa386`]\n\n### Code of Conduct (CoC)\n\nIt defines expected and prohibited conduct, assigns Moderators as first-line enforcers with proportionate measures and a temporary Appeals Panel mechanism, embeds authority and liability limitations, and requires conflict disclosure consistent with the COI Policy.\n\nSee: [Proposal link](https://github.com/houseofstake/proposals/blob/207bc93b5d054e8ff3b6cc889e844126939d84f3/HSPs/hsp-013-coc.md), [Forum discussion](https://gov.near.org/t/hsp-013-near-house-of-stake-code-of-conduct/42050)   \n[`Git Blob Hash: 75ffe8ea8af92daa4a98a210ba260eb9b8c1109a`]|approval_threshold=5000,quorum=3500","proposalId":"25","proposalTitle":"NEAR House of Stake Constitutional Documents (HSP 008-013)","proposalUrl":"https://gov.near.org/t/ratifying-our-constitutional-documents-upcoming-proposals-dec-2025/41808/21","receiptId":"HnqcJmsSaLNMM32qexwfNPbXNTWxMF3p8BdksdX8wvBv","rejectedAt":null,"rejecterId":null,"forVotingPower":"3257998761887995964624844696452","againstVotingPower":"0","abstainVotingPower":"263365841593423541410696803514","votingDurationNs":"1209600000000000","totalVotingPower":"5954463998152520469277733226223","quorumAmount":"7000000000000000000000000000000","status":"Finished","votingStartTimeNs":"1773264531826000000","votingCreatedAtNs":"1773264353751000000"}],"count":12}