The 14 days unbounding is still much
Cool though
Excited to see something’s being done to solve this issue 
1 Like
Thanks for this great news
Interesting and insightfully
This is an insightful read
Transparency is and this is nice 2 weeks is definitely okay
If I understand correctly, this proposal would introduce a manual “claim” step with a fixed fee for each gNODE withdrawal after the 150-day maturation period.
To be honest, that gives me a bit of pause. After waiting that long, it seems fair and user-friendly for the tokens to be sent automatically — without any extra step or cost beyond gas. Adding a fixed fee feels like an unnecessary barrier, especially in a project that values accessibility and decentralization.
Personally, I plan to withdraw gradually over a period of up to 30 days, to spread things out smoothly.These rewards weren’t free — I’ve funded servers myself and supported the project from early on. I know many others are in a similar position, and this kind of system could end up penalizing those who’ve been consistently involved and invested.
I truly believe NodeOps should reward long-term commitment, not make it harder.
That’s why I’d prefer a solution where withdrawals are automated after maturation, without a fixed fee.
I’m not in favor of this proposal as it stands
Well said.
Adaptive design and sustainable fees ensure NodeOps evolves with the market while empowering true community-driven decentralization.
The reasons are solid enough, I love the fact that the revenue is considered and the participants is considered even at the present market conditions
I’m fully aligned with you. I understand that some operations come with costs, such as bridge transfers—which I completely get. However, when it comes to withdrawals, I disagree that it’s a market standard. If you look at projects hosted by Node Ops, like Rivalz, Lumoz, and XProtocol, there’s no withdrawal fee—only vesting periods, and not even in all cases. To me, Node Ops is a market standard in itself and has the freedom to define its own model. The key to a project’s sustainability lies in its revenue—not in a withdrawal fee that users can choose to trigger daily or once a year. Perhaps a withdrawal fee makes sense in a different context, one that doesn’t involve gNODE maturation.
Solid framework! balancing early stability with future adaptability. The 90-day review cycle shows smart foresight, ensuring parameters evolve with market and network growth.
It’s indeed a wonderful job NODE is gonna be unstoppable as it gain a community
I agree with the proposal on GitHub, but I do not agree with how it is described here in the discussion.
The discussion only mentions:
“Withdrawal fees: 10 NODE”
but it never explains what the fee is used for. That only becomes clear when you actually read the PIP on GitHub.
I think we should make sure the discussion description matches what is written in the PIP on GitHub. Otherwise, we are discussing something that is not even aligned with the actual proposal.
This already happened with PIP-001. The discussion said 67% quorum, but the PIP said 30% quorum, which caused confusion. Let’s try to avoid that.
Also, this kind of mismatch makes it confusing for me to decide how to vote. Sometimes I agree with the PIP on GitHub, but not with the version summarized in the discussion. In the end, I do not know which one my vote is actually supporting.
Instead of rewriting or summarizing the PIP every time, I suggest we keep the discussion post minimal and simply remind everyone to refer directly to the PIP on GitHub for full details. That way, there is no misunderstanding or wrong interpretation.
1 Like
I don’t think the current parameters are too high. The bonding fee per CU is already quite low and reasonable for anyone running proper compute infrastructure.
If we make it even lower, it could attract low-quality providers or bots that don’t add real value to the network.
It’s better to start with these values and adjust later if needed PIP-002 already includes a review cycle for that
We’re actually losing money by bonding a machine right now. The token price has dropped by half, from $0.10 to around $0.05, and that hurts.
If we put in $1,000, that bond is now worth only $500. Sure, we still generate about $500 worth of gNode rewards over the next 150 days, but let’s be honest, that only feels good if the token price holds or rises. If it drops even more, we’re the ones left taking the hit.
And on top of that, we still have to cover the real costs of running our instances: electricity, hosting, maintenance, all paid out of pocket. We’re not just watching numbers on a screen; we’re actually spending real money to keep things running.
I still believe in this project. I really do. The vision, the tech, the community, all of it. But the token price is a different beast, one that’s completely out of our control.
That’s why we need a better way forward. We should be able to bond our machines with something more stable, like ETH or even a stablecoin. The point of the bond is to ensure accountability, to weed out bad actors, not to punish the ones who believe and keep things running. Stability would give us the confidence to keep building without constantly worrying about market swings wiping out our efforts.
2 Likes
I can understand both perspectives here.
The parameters make sense for the early phase we all want the network to stay stable and avoid low-quality providers. At the same time, we have to be honest: with the current $NODE price, many of us are already operating at a loss.
Waiting 150 days for full unlock is fine if the price holds, but if it keeps dropping, it becomes very difficult to stay motivated, especially for those actually running infrastructure and paying real costs.
Maybe a good middle ground is to keep the current bond for now but have a clear mechanism to auto-adjust it if $NODE fluctuates too much that way we keep things fair for both the DAO and providers.
I’ve been part of the community for a while and still believe in the long-term vision just want to make sure we stay sustainable for everyone building here.
1 Like
Smart move. Fee module as a growth engine really shows NodeOps is thinking long-term. 
2 Likes
Love this! Clear fees and fair parameters exactly what the network needs to stay strong and balanced. Excited to see PIP-002 go live!
1 Like
Looks great this proposal is a solid foundation for a sustainable and transparent launch.
Locking in clear parameters like bond requirements and fees ensures long-term network stability and fairness for all compute providers.
Excited to see PIP-002 move forward and bring the NodeOps Protocol to life!
#NodeOps #DePIN #Governance #Web3
“The introduction of the fee module represents a major step in establishing recurring, protocol‑native revenue, reinforcing $NODE’s role at the core of the ecosystem”. This is totally fine .