Pasting here verbatim the message I posted in the Node Operators Matrix channel, per @serinko 's proposal.
Toward clearer governance for exit-policy changes
I’d like to start a discussion about how changes to the exit policy should be governed. The below is mostly a summary of what has been discussed in the Matrix operator channel and in the forum, along with a few new ideas.
This is not an attempt to reopen NIP-14. However, it showed that the process for exit-policy changes has never been clearly defined.
Exit-policy NIPs are submitted as standards, but in practice they are also put to an operator vote. We do not appear to have agreed rules covering:
- what information must be disclosed before a vote;
- when services or port groups should be voted on separately;
- how exit operators should be represented;
- how an approved proposal is linked to the deployed policy;
- how ports can later be reviewed, suspended or removed.
I think this could be addressed through a process NIP.
Why this matters
The scope of these proposals has grown.
NIP-3 covered a few named ports and allowed separate voting choices. NIP-14 included broad ranges and many additional ports, but operators could only vote yes or no on the full package.
A bundled vote does not show which parts operators actually support. It also means that describing a large range by the name of one service may not fully describe what the policy permits.
Future proposals should therefore include:
- the requested ports and ranges;
- a before-and-after diff showing the effective net-new permissions;
- the requester or sponsoring organisation;
- the original request channel and intended use case;
- a risk section covering other common uses, known abuse patterns and possible hosting-provider concerns.
Independent services or ranges should be separate ballot items where practical.
Exit-operator participation
All bonded operators currently vote, but the direct legal and operational consequences fall mainly on exit gateway operators.
One possible model would require both:
- approval through the normal operator vote; and
- approval by participating eligible exit operators.
The second vote should probably be stake-neutral, although we would need to decide whether it is counted per gateway, per family or another model.
The aim should be a review mechanism, not a permanent veto. A rejected proposal should be able to return after the concerns have been addressed.
Auditability and review
Each deployed change should have a public record containing:
- the NIP #;
- the vote result;
- the exact policy diff;
- the implementation date;
- any later rollback or modification.
We should also define procedures for:
- normal removal of an obsolete or harmful permission;
- temporary/emergency suspension following credible abuse or security evidence;
- rollback where the deployed policy does not match what was approved.
Large ranges could receive a mandatory review after a defined period, based on usage, abuse reports, provider notices and operator feedback.
A related technical question
We should also examine whether every port needs to apply equally to fast mode and anonymous mode.
Many recent requests involve latency-sensitive applications for which the demand may mainly come from fast mode. Mode-specific policy entries could potentially reduce unnecessary exposure, although this may be better handled through a separate technical NIP.
Questions
I’d particularly value feedback on:
- Should exit-policy NIPs require a separate exit-operator threshold?
- Should that be counted per gateway, per family or through a capped model?
- What types of changes should trigger a more demanding process?
- Should broad ranges require periodic review?
- Should mode-specific policies be explored separately?
If there is support, the outcome of this discussion could be turned into a process NIP.
The objective is not to block useful policy changes. It is to make the process proportionate to their scope, clearly document what is being approved and give the operators carrying the direct consequences a meaningful role.