[adenarc]

Draft recipe for the Node DAO policy change that lets members propose and lowers the bond. It covers both decision A variants side by side (Everyone and a Members group): the roles that change, the AddProposal permissions for decision B's candidate kinds, the bond and when Sputnik returns it, and how to file the change from Trezu. Each Sputnik claim cites the contract source at 5434a59d.

It isn't validated yet. It waits on #407's mainnet run (the transaction link slot is still empty) and on decisions A and B.

Docs only. typecheck, lint and test pass locally.

Part of #412

[multi-review]

Inline findings for 2332e78; see the summary comment for the rest.

[multi-review]

Multi Review · 14eb638 (changes since 2332e78)

This docs-only change adds a "signer check" section so a DAO doesn't strip its signers' only AddProposal grant, links it from both variants and from the ChangePolicy steps, and gives an approval order for the multi-proposal path with the bond change last. That resolves both earlier findings. The only gap left is in the new step 3: it omits expired and failed proposals that still need finalizing.

1 issue(s) · 2 still open from earlier

What was checked (5 areas)

• New 'First, keep the signers able to propose' section and its links from Variant 1, Variant 2 and ChangePolicy step 2
• Earlier finding on signers losing AddProposal: now covered by lines 61-65, 80, 95, 126
• Earlier finding on bond ordering in the multi-proposal path: now covered by lines 200-206
• New ordering steps (lines 200-206) checked against the bond lifecycle table and the pending-proposal advice at line 113
• Anchors and link references used by the new text (#first-keep-the-signers-able-to-propose, default-policy, can-execute, return-bonds, act)

Findings

• 🟡 Low docs/node-dao-member-proposals.md:204 Bond-last step only says 'approved or rejected', so expired or failed proposals finalized after the drop refund 0
  Step 3 says to approve the bond change once every other pending proposal "has been approved or rejected". The bond table (lines 105-109) says an expired proposal, or one that failed, keeps its bond locked until someone with Finalize finalizes it. Line 113 also says to "Approve, reject or finalize pending proposals before lowering the bond". Sputnik refunds whatever proposal_bond is in force when it pays the refund (proposals.rs:339-349).

  Scenario: a member's poll filed with the 1 NEAR bond expires without a vote. It is still InProgress because nobody finalized it. Following step 3 as written, the council approves the proposal_bond: 0 change, since that proposal was neither approved nor rejected and the step's checklist doesn't name it. When the council finalizes the expired poll later, its proposer gets 0 back and the 1 NEAR stays in the DAO. A call proposal in the Failed state, finalized after the drop, hits the same problem.
  Suggested fix: Make step 3 match line 113: add finalizing expired and Failed proposals to the list of things to settle before the bond change is approved.

Still open from earlier reviews

• 🟠 Medium docs/node-dao-member-proposals.md:74 Removing/narrowing Everyone's *:AddProposal can leave signers unable to propose, with no check in the recipe
• 🟡 Low docs/node-dao-member-proposals.md:194 Multi-proposal path doesn't order the bond change last, so pending role proposals get 0 back

_{Comment @multi-review to re-review new commits, or @multi-review full for a full review.}

[adenarc]

@multi-review

[adenarc]

@elliotBraem this is ready for review. It's the docs half of #412 (the helper merged in #435).

What it is: a draft recipe for the one policy change each Node DAO's signers make in Trezu, so members can propose and the bond drops (ideally to 0). It covers both decision A variants (Everyone or a Members group), the AddProposal permissions for decision B's candidate kinds, when the bond is returned or kept, and how to file the change. Each Sputnik claim links to the contract source. Multi Review's two findings are fixed in 14eb638.

It's "Part of #412", not "Closes". To close #412 we still need:

1. The Activation spike: QR join to a passkey-signed proposal on mainnet #407 mainnet spike to run, so its transaction link goes in the doc
2. Decision A recorded (Everyone or a Members group)
3. Decision B recorded (polls, page changes, House of Stake votes, or all three)

Then a short follow-up PR drops the unused variant and closes #412.

For epic #408, the rest is mostly gated on the same items:

• Activation spike: QR join to a passkey-signed proposal on mainnet #407 is waiting on a confirmed real QR join on production
• Decision I (who sends and pays gas) blocks finishing Members sign with their Passkey Wallet #406
• Public Node DAO proposals and member submission #413 (public proposals and member submission) needs decision B, Members sign with their Passkey Wallet #406 and Read whether members can propose to a Node DAO, and document the policy change #412
• Show members the events they've attended #400 needs the Settings → Profile slot upstream (everything-dev#661)
• Redirect /build to nearbuilders.org with the member's referral code #395 needs referral codes on nearbuilders.org

Could you help get decisions A, B and I recorded, or tell me who should make them? Those decisions plus the #407 run unblock most of what's left.