Exhibit A — Vaulta Network RFP Framework

Version: 5.5
Status: Draft
Date: 2026-10-18

---

Purpose

This Framework sets the Steering Committee’s responsibilities and funding authority and the rules for running the Network RFP program, as required by MSIG #4.

It has two parts:

• Part 1 — The Steering Committee and the Mandate. Who decides, how they are chosen, how they vote, and how money moves.
• Part 2 — Running an RFP. How a single RFP goes from an idea to a paid deliverable.

Block producers may amend Part 2 by MSIG Resolution without reopening Part 1. Part 1 governs any conflict, and Part 2 may vary a Part 1 rule only where Part 1 expressly permits it.

Definitions

These definitions form part of Part 1.

---

PART 1 — THE STEERING COMMITTEE AND THE MANDATE

1. Steering Committee

1.1 The Committee has two roles, governed by separate rules: Trust oversight and Network RFP funding.

1.2 Appointments follow section 3, with the Community seat also following section 4; block producers decide when seats are filled.

Until all five seats are filled, the Committee must not exercise the RFP mandate, publish RFPs, or make awards.

Program Account funding and Committee permission activation must wait until all five seats are filled and every member has signed their contract, filed their declaration, and registered a signing key.

1.3 The RFP program is not a Trust activity, its funds are not Trust Property, and the Trustee has no role in it.

1.4 Every decision and record must identify whether it concerns Trust oversight or the Network RFP program.

1.5 The Committee must not use either role to pressure decisions in the other; communications involving both roles must be written and recorded in the minutes.

2. Seats

2.1 The Committee has five seats, each with a portfolio listed below; all members share Trust oversight duties equally.

2.2 Each member leads work in their portfolio but cannot make funding decisions on their own.

2.3 Members guide the program and evaluate proposals, but may perform funded work only as Technical Reviewers under section 12.6; their Reviewer fees count as Program Costs, not awards.

2.4 Each person may hold only one seat; no two members may be connected to the same block producer, company, or corporate group; and members must serve personally, without substitutes.

2.4a Treasury exclusion. Anyone affiliated with the Vaulta Treasury may not serve as a Steering Committee member, RFP Program Manager, or Technical Reviewer.

Affiliation means being a Treasury employee, officer, or director; providing services under contract; controlling Treasury funds; or acting under its direction on treasury functions.

Block producers may waive the exclusion by MSIG Resolution at the Threshold, with published reasons.

Anyone in these roles who becomes Treasury-affiliated must disclose it within 10 business days; their signing weight, if any, is suspended immediately, and the matter goes to block producers, who may waive the exclusion or remove them.

2.5 Each member must sign a contract with VS LLC and is not a Trust employee.

2.6 Each member has one unit of signing weight on the Program Account (section 7) and must keep their signing key secure. A person unable to hold a signing key securely cannot serve.

3. Member appointments and terms

3.1 Members must be appointed by an MSIG Resolution approved at the Threshold that follows Exhibit E to MSIG #5. Each proposal may cover one or more seats; the Community seat also follows section 4.

Competing proposals may be approved, but the first appointment executed by block time fills the seat; later executions have no effect for that seat.

The resolution mode selected in an MSIG that follows Exhibit E determines the outcome:

• Seat by seat (default): Appointments stand independently; one failing does not affect the others.
• All or nothing: No appointment takes effect unless all can.

An appointment has no effect if, at execution:

1. The seat is filled.
2. The candidate holds another seat, including one filled by the same Resolution.
3. It breaches the affiliation rule in 2.4.
4. The candidate is Treasury-affiliated without an express waiver at the Threshold.
5. The candidate is on the ban register under 6.6.

Where candidates in the same proposal conflict under the one-seat or affiliation rules, Candidates table order sets priority: the first appointment takes effect and conflicting later appointments do not, subject to the resolution mode.

3.1a Network vision statements. Each candidate must provide their own network vision statement meeting Exhibit E’s requirements, included with the appointment proposal.

Missing statements. A proposal missing a statement is incomplete and should not be submitted or approved. If it executes anyway, the appointment remains valid, but VS LLC must record the omission in the seat register. Pay and signing weight must wait until the statement, contract, questionnaire, and signing-key requirements in 3.1b are complete.

Publication and reappointment. Record statements in the publications register (7.6a), display them with the proposal on the Portal, and keep them linked from the seat register throughout the term. Statements are non-binding but inform reappointment; members seeking another term should explain how their year compared with their statement.

Seat register. VS LLC must maintain the official record of executed appointments in the publications table (7.6a) and display it on the Portal, recording:

• Each member’s name and on-chain account, matching 6.3a.
• The proposal name, execution transaction, and resolution mode.
• Each member’s vision-statement link.
• Any proposed seat left unfilled and why.
• Any appointment conditions identified by VS LLC.

Block producers decide eligibility. If VS LLC records a seat as unfilled for any reason other than an earlier execution, it must publish its reasons and refer the matter to block producers. The seat remains vacant until block producers decide.

3.1b Onboarding. An incomplete appointment proposal that executes is not void. Each appointee must file their candidate-written vision statement under 3.1a, sign their contract, file the standard on-chain disclosure questionnaire under 6.3a–6.3b, and register their signing key within 30 days of appointment execution or VS LLC announcing that the register is open, whichever is later. Pay and signing weight begin only after all required items are filed and the contract and key requirements are complete.

3.2 Members serve one-year terms, except for the initial terms in 3.4 and vacancy appointments in 3.7, and may be reappointed without limit.

3.3 Continuation. Members continue month to month after their term ends and keep their signing key until a successor is seated or block producers replace them.

3.4 Initial terms.

All later terms are 12 months.

3.5 Removal. An MSIG Resolution may remove a member at any time, with or without cause; their signing weight ends immediately on removal. The Committee may refer members to block producers for removal but cannot remove them itself.

3.6 Resignation. A member may resign by written notice to the Chair and block producers. The signing weight ends immediately on delivery of the notice. The seat becomes vacant on the stated resignation date, or on delivery if no date is stated.

3.7 Vacancies. A vacant seat is filled for the rest of the term using the process for that seat.

3.8 Signing requirements. Payments follow the Committee permission in 7.2.

With fewer than four members, no payment can execute; the Committee may still meet, decide, publish, and escalate, but block producers must fill a seat or change the permission.

An award goes to block producers if fewer than four members can sign (section 9).

4. Community seat

4.1 The EOS Community Foundation (ECF) runs the Community seat vote and sets candidate and voter eligibility, the voting method, and how results are published.

4.1a ECF is independent of the program. Any funding to ECF itself, including for administering the Community seat vote, requires ECF’s own MSIG, decided by block producers at the Threshold; it cannot be a Committee award. This does not bar ECF from bidding under 4.1b, or its members from otherwise eligible program roles or awards, subject to the conflict rules.

4.1b ECF may bid. Any resulting funding still requires ECF’s own MSIG under 4.1a. ECF is a connected organization under 6.2 whenever the Community member is engaged by, receives a stipend from, or holds a position in ECF. The member must declare the connection in writing before the RFP is published, recuse from scoping, drafting, evaluation, scoring, discussion, and voting, and must not help set its budget or criteria. The connection and recusal must be minuted and published.

Any ECF stipend or engagement must also be disclosed on-chain under Part 2 of the questionnaire (6.3a).

4.2 The ECF vote nominates a candidate, who must then be appointed by block producers through MSIG Resolution like every other Committee member.

4.3 Block producers should refuse to appoint an ECF winner only for disqualifying cause: a proven conflict of interest, a legal bar, a serious failure in the vote, or conduct that would be Cause under the Trust Agreement. Anyone refusing for another reason should publish it; this commitment is not enforceable under this Framework.

4.4 If block producers refuse to appoint the winner, ECF nominates the runner-up if its process provides one; otherwise ECF runs the vote again.

4.5 Initial appointment. MSIG #5 appoints no interim Community seat holder; the seat must be filled by a future MSIG Resolution at the Threshold using Exhibit E, following the selection process in this section.

4.6 Initial selection deadline. The initial ECF winner must be seated within nine months of MSIG #5’s execution. On ECF’s request, block producers may extend that deadline once by MSIG Resolution at the Threshold, stating the new deadline. If no winner is seated by the applicable deadline, block producers must fill the Community seat by a future MSIG Resolution at the Threshold following Exhibit E, without an ECF nomination, subject to the normal eligibility rules. A later ECF nomination does not displace a seated member; the normal term, continuation, and vacancy rules apply.

4.7 If ECF stops running the process or ceases to exist, block producers may, by MSIG Resolution, name another administrator or fill the Community seat at the Threshold using the normal appointment rules, indefinitely if needed. Block producers may restore community selection if a process emerges, but are not required to.

However filled, the seat retains its Community portfolio, categories under 2.1, vote, signing weight, pay, and status.

4.8 Community appointments must follow 3.1 and Exhibit E; the one-year term starts when the appointment Resolution executes (3.4).

The vision statement requirement in 3.1a applies. An ECF statement satisfies it if it meets those requirements and is filed with the proposal.

5. Meetings and voting

5.1 Meetings. The Committee must meet at least monthly, at least twice monthly while an RFP is open for submissions or under evaluation, and whenever the Chair or any two members call a meeting.

5.2 Quorum. Decisions require at least three filled seats and three non-recused members present; payment signatures follow 7.2.

5.3 Thresholds. Counted on filled seats, minus recusals.

5.5 The Manager of record approves milestones, not the Committee, except for the rate-check referrals below (section 11).

Rate-check referrals. If the collar check in 13.4 triggers, or the rate is stale and the fallback is unavailable, the Committee may approve payment at simple majority, minimum 3; it does not reopen the Manager’s determination.

5.6 Recusal. A conflicted member must recuse and is excluded from materials, quorum, and the vote count.

A recused member must not sign the payment. Signing and objecting afterwards does not satisfy recusal. Awards with fewer than four available signers go to block producers under section 9.

5.7 No substitutes. Members vote personally. Written or cryptographically signed consent counts as a vote.

5.8 Chair. The At-Large member chairs unless the Committee elects otherwise. The Chair sets agendas and is the contact point for the Trustee, VS LLC, and block producers. The Chair has no extra or casting vote.

5.9 Minutes. Every meeting is minuted with attendance, decisions, vote counts, and recusals. Minutes are published within 10 business days. Only three things may be removed: confidential proposal content before award, legal advice, and personal data. Vote counts and recusals are never removed.

Personal-data redaction must not remove the name, role, seat, or on-chain account of any member, Manager, Reviewer, or other person exercising a program decision right, when acting in that capacity.

6. Conflicts of interest

6.1 A member may not, during their term and for 6 months afterwards:

• submit a proposal, alone or through a company they hold a material interest in;
• be named on any proposal as a participant, subcontractor, or paid adviser;
• accept any payment, fee, equity, token allocation, or referral from a proposer or awardee connected to a Vaulta RFP.

6.2 Connected companies. A company connected to a member may bid only if the member:

• Declares the connection in writing before the RFP is published;
• Recuses from scoping, drafting, evaluation, scoring, discussion, and voting; and
• Has the connection and recusal minuted and published.

This covers the member’s employer, companies they work for, companies under common control, and companies in which they hold a material interest. The member must not help set the budget or criteria for an RFP their connected company later bids on.

6.3 Declarations. Every member, Manager, and Technical Reviewer must declare connections, employment, Vaulta-ecosystem positions other than A, and any Vaulta Treasury connection.

6.3a The disclosure questionnaire. Use the standard questionnaire, with its questions in their stated order; free-form declarations do not qualify.

VS LLC must publish the complete questionnaire, with no unresolved items, and open the disclosure register for filing.

Who files: every Steering Committee member, every RFP Program Manager, and every Technical Reviewer. Any other person given a decision or approval right in the program files the same questionnaire before that right takes effect.

The required disclosures are set out in the standard Disclosure Questionnaire published with Exhibit D under MSIG #5. All nine parts are mandatory, and changes to the required disclosures require an MSIG amendment.

Parts 2 to 8 each require an explicit "None" where there is nothing to declare. A blank is treated as an unfiled questionnaire.

6.3b Publication on-chain. Questionnaires are published on-chain in full, and the Portal displays the register without keeping a separate copy.

Where it is written. Disclosures go to disc.vst, a separate account with an append-only disclosure contract operated by VS LLC under the writing authority in Exhibit D 1.4. Block producers retain owner and contract-upgrade authority at the Threshold. VS LLC must configure and publish it under the Exhibit D process and MSIG #5 Part E. Its key has no authority over the Program Account.

What is written. Use the disclosure-record fields in Exhibit D 4.3. Exclude legal identification collected privately by VS LLC. The filer signs their own submission; VS LLC writes the record and cannot alter its content.

The full public filing is stored on-chain.

Records are append-only: updates must reference the previous record; nothing may be edited or removed.

Filing privacy. Positions must be stated by band, not exact figure. Filings must name organizations but must not name other individuals, including family members, colleagues, or counterparties; records cannot be withdrawn.

Pre-write screening. VS LLC must return filings that name other individuals or give figures where bands are required. This is a mechanical screen, not a review of substance.

6.3c Filing gates. The questionnaire satisfies the conflict-of-interest declaration required by appointment and engagement documents.

Member filing deadline. The 30 days run from appointment execution or VS LLC announcing that the register is open, whichever is later; members cannot be replaced for missing a deadline before filing was possible.

Annual refiling more than 30 days overdue: suspend a member’s pay until filed; Managers and Reviewers may take no new assignments or be recorded as Manager of record until filed. Existing assignments continue; this is a procedural breach under 6.6.

6.4 Managers and Reviewers. Managers and Reviewers must not bid on an RFP they work on during their engagement or for 6 months afterwards, or approve or assess milestones for an awardee with whom they have a conflict.

Manager and Reviewer conflicts. Sections 6.1 and 6.2 apply as if references to a member referred to the Manager or Reviewer. They are also conflicted on an awardee that is, or is connected to, anyone or any organization declared in questionnaire Parts 3, 5, or 7. The normal remedy is reassignment under 12.3; the Treasury exclusion in 2.4a also applies.

6.5 Confidentiality. Proposal contents, prices, and evaluation discussions remain confidential until the award is announced. Members must not share them with competitors or use the information to benefit themselves or a connected company.

6.6 Consequences.

Breach descriptions:

• Minor or procedural breach — a disclosure filed late, an update missed.
• Material breach — self-dealing, an undisclosed interest in a proposer or awardee, taking any payment from a proposer or awardee, using proposal information for private advantage, breaching confidentiality, or signing on a matter the person was recused from.

Contractual pay suspension. Exhibit F’s automatic pay suspension on a removal referral or three consecutive unexcused absences is separate from a suspension of role or signing weight. A material-breach referral alone does not suspend the role or signing weight: the Committee vote above is required, without limiting the immediate Treasury-affiliation suspension under 2.4a.

The permanent ban. On confirmation by not fewer than 15 of the 21 active block producers, the person is permanently barred from:

• holding any Steering Committee seat;
• serving as an RFP Program Manager or Technical Reviewer;
• submitting or being named on any proposal to the Vaulta RFP program, or receiving any payment from it — directly, or through any entity in which they hold a material interest.

Only block producers may lift a ban, by MSIG Resolution at the Threshold; no Committee vote, passage of time, or membership change reduces or expires it.

Before block producers vote, the person must receive the allegation in writing and 10 business days to respond; their response is published with the referral.

The ban register. VS LLC must maintain the ban register in the publications table (7.6a) and display it on the Portal, recording the person, date, confirming MSIG transaction, and any named entity. A lifting at the Threshold is added alongside the ban, not substituted for it. The register must be checked at proposal submission and before any role is assigned.

6.7 A Committee member may hold a paid Technical Reviewer engagement only under section 12.6, including its preconditions and recusals.

7. Program Account and signing

7.1 All program funds must be held only in rfp.vst, the Program Account; only block producers may name that account. The VST has no authority over its funds; the permissions in 7.2 govern.

7.2 The Program Account must enforce the following authorization requirements; Exhibit D must identify and verify the separate payment and administrative authority routes. A three-signature cancellation route must not authorize a fund transfer.

7.3 Block producers retain the owner permission and may replace a removed member's key, rebuild the Committee permission, or recover the account.

7.4 Personal keys. Members must not share or delegate their key, let an employer hold it, or sign for another member, including a recused member.

Keys must be registered on appointment and surrendered on removal or replacement. Members retain them during authorized month-to-month continuation under 3.3.

7.5 Lost or compromised keys. A member must immediately notify the Chair and block producers and stop signing until the key is replaced. The Committee must not propose payments until then.

7.6 The platform must not hold any key with Program Account authority or any member’s signing key; members sign with their own wallets. VS LLC’s disc.vst writing key has no Program Account authority and cannot move funds (6.3b).

7.6a On-chain records. The disc.vst append-only register holds the program’s disclosures, decisions, and publications in three tables (6.3b).

The Portal reads and displays the register without keeping a separate copy.

The decisions table

The publications table

Records must be written in full and are append-only. Corrections must reference the old record; nothing may be edited or removed.

Off-chain records.

Redaction must finish before writing a record. The awardee’s response to a post-award review is subject to the same redaction process and three grounds as the review (25.2).

The 6.3b pre-write screen applies to every table. VS LLC must screen decision records for names of individuals outside the program and figures that should be bands. Program decision-makers remain identifiable under 5.9. Remove names of awardee staff, quoted internal material, and legal advice from Technical Reviewer assessments before writing them; record the screened assessment and the Manager’s determination and reasons.

Additional screening requirements:

Screening is mechanical, not substantive; VS LLC must not judge whether a determination is correct.

Write each record within 2 business days of its decision, using the disc.vst key in 7.6. Publication means writing to this register; the delay in 10.4 starts from that publication.

8. Committee mandate

8.1 Block producers grant the Committee a standing mandate to allocate Program Account funds on behalf of the Network by MSIG Resolution; block producers do not vote on individual RFPs or awards, and a Committee decision within the limits below is the Network's decision.

8.3 The Committee decides:

• Which needs become RFPs and their scope, deliverables, criteria, budgets, and timelines;
• Awardees and award terms;
• Managers of record and Technical Reviewers; and
• Whether to withhold payment or terminate an engagement.

Funding instruments. The Committee may use only three funding instruments: a directed RFP (sections 18–25), an open call for unsolicited proposals (section 26), or a bounty (section 26a); "grants" means the open call, not a fourth instrument.

8.4 What the Committee may not do:

1. reserve or commit more in a cycle than the Cycle Ceiling;
2. make a single award above the Per-Award Limit;
3. make an award the conflict rules forbid;
4. change the funding source, extend the cycle, or widen the program's scope;
5. split, stage, combine, or later top up awards to get around points 1 to 4;
6. act after the mandate is suspended or revoked;
7. form, register, incorporate, or join any company, foundation, association, trust, or other entity, or become its member or director, on behalf of the Network. The VST and VS LLC are subject to this same restriction. Any such action requires a separate MSIG Resolution at the Threshold.

An action outside these limits is void; VS LLC must not contract on it, and block producers should cancel any related payment during its delay window.

8.5 Safeguards. The following controls are required:

9. Matters requiring block producer approval

9.1 Reserved matters. The following require block producer approval by MSIG Resolution at the Threshold, rather than a Committee decision:

9.2 Timing.

The existing-awardee exception does not cover Program Costs referred for exceeding their ceiling or internal caps; the ordinary-referral rule applies to those costs.

Payments the Committee cannot sign. At the Threshold, block producers may direct payment through the block producers’ owner permission or temporarily rebuild the Committee permission for named payments; confirmation alone does not execute a payment.

Automatic escalation. A matter falling under 9.1 without a vote to escalate needs no Committee vote for submission; the Chair, or any member if there is no Chair, must submit it.

10. Award approval and payment

10.1 Award and payment sequence. Each step must finish before the next begins.

Later milestones: Repeat steps 4–6, with a separate proposal for each payment. The normal delay applies, but there is no objection process (11.6); block producers retain their cancellation right under 10.8.

10.3 Publication. Within 2 business days, publish:

• Awardee, scope, award shape, licence, amount, and milestone schedule;
• Each member’s vote — for, against, or recused — by name and on-chain account; and
• Any reason for departing from Reviewer scores.

Add the on-chain transaction reference when payment is proposed.

10.4 The delay window starts when publication is complete and cannot be waived.

• Incomplete or corrected publication requires cancellation and a new proposal, restarting the delay.
• The urgent delay requires a Committee urgency vote of two-thirds of filled non-recused seats, minimum 3, with the urgency reason recorded and publication complete before payment is proposed.

10.5 Objections. Block producers may object during the delay and withdraw their objections. Record each objection as received in the publications register (7.6a) and the public Portal register, attributed to the block producer who made it.

Withdrawals reducing the count below seven before it closes move the award into the applicable lower band.

10.6 Counting. The Manager of record keeps the register. The count is fixed when the delay window closes. Withdrawals must be recorded before that moment. Objections arriving later do not change the result.

10.6a Signed objections. Objections and withdrawals must be signed by the block producer’s on-chain account. Count only signatures from the active producer set at signing; record ineligible signatures without counting them and identify the producer schedule used.

10.7 Cancellation is a 3-of-5 on-chain administrative action and is mandatory in the 4-to-6 and 7-or-more objection bands; the Committee must cancel within 2 business days of the count closing, and failure to do so is an express ground for referral to block producers for removal.

Execution guard. An initial award payment must remain blocked until the full delay has ended, the Manager has published the final objection count, and the outcome permits execution. A count of 4 or more blocks execution, even during the two-business-day cancellation period. A 4-to-6 outcome requires cancellation and the confirmation and re-proposal process in 10.9; a 7-or-more outcome ends the award. These execution restrictions apply to both mechanisms in Exhibit D. Withholding approvals under the held-multisignature fallback is a procedural control, not an automatic timelock. It may be used only with a tested execution guard satisfying Exhibit D 6.1; if that cannot be demonstrated, funding and activation must wait for a compliant mechanism or an MSIG amendment. Later milestone and Program Cost payments have no objection banding.

Block producers may also cancel through the owner permission.

10.8 Block producers may cancel any payment at the Threshold during its delay, regardless of the objection count.

10.9 After a 4-to-6-band cancellation, the Committee must submit the record and a draft confirming Resolution to block producers within 10 business days. If block producers do not confirm within 30 days of submission, the award ends and its reservation is released.

MSIG confirmation restores the award decision, not the terminated agreement. Before proposing disbursement again, VS LLC must sign a fresh agreement on identical terms, within the 60 days from confirmation in 10.10.

Effect of cancellation on contracts:

10.10 Unused award decisions. Sign the agreement within 60 days of the award decision, or MSIG confirmation following a 4-to-6-band cancellation, and before the cycle closes. Otherwise the decision expires and the Committee must vote again.

11. Milestone approval and payment

11.1 The Manager of record approves each milestone for payment, deciding whether it has been met; awards are paid in milestones under the schedule proposed, settled, and contracted under 11.1a.

11.1a Milestone schedules. Every RFP award must have at least two milestones and follow this process:

When reviewing changes, require inspectable deliverables, achievable dates, proportionate amounts rather than front-loading, and no excessive subdivision; mobilization advances remain capped.

After award, changes to milestone scope or dates follow 11.8: Committee approval at majority, minimum 3, a contract amendment, and publication. The two-milestone minimum remains. Bounties instead follow 26a.

Determination and payment approval. “Approval” normally includes both the Manager’s determination and approval for payment. During a suspension under 13.4a, the determination must still be made and published; payment approval follows on resumption.

11.2 Technical Reviewer. The published Reviewer setting (20.2) governs every milestone:

• Reviewer engaged: obtain a written assessment — accept, accept with conditions, or reject with stated fixes — and include it in the Manager’s determination.
• No Reviewer engaged: the Manager uses their own assessment; no Reviewer assessment is required.
• Payment approval deferred under 13.4a: use the assessment as it stood when the determination was made; a Reviewer whose engagement has ended need not re-file.

11.3 The approval record must publish:

• The milestone, criteria applied, decision, and reasons;
• The Manager of record’s name and on-chain account;
• Any required Technical Reviewer’s name, account, and assessment;
• The amount payable and the awardee’s verified receiving account.

During a suspension under 13.4a, publish the determination, its date, and the required details when made, excluding the amount payable; add the rate data and amount, then republish, on resumption.

11.3a Named decision-makers. Record each decision-maker’s name and on-chain account as required by 7.6a.

Name and account must match questionnaire Part 1 (6.3a) and the seat register. The name must be a legal name or registered handle, unchanged during the term; neither name nor account may be redacted under 5.9.

11.4 Administrative signatures. Members must sign under 7.2 after checking only the relevant row below:

11.4a Initial disbursement. Apply the initial-disbursement checks above before proposing payment. Execution, rather than proposal, requires the completed delay and objection clearance under 10.7.

11.5 Refusing to sign. Members must sign even if they voted against the award.

They may refuse only if a required administrative check fails or there is credible evidence of misrepresentation or a conflict-rule breach. Written reasons must be recorded in the minutes.

Rejudging the work, disagreeing with the Manager’s judgment, or reopening the published Reviewer setting are not grounds for refusal.

11.6 Milestone payments carry the normal delay but no objection process.

11.7 Advance payments before delivery are capped at 15% of the award total, and only where the awardee genuinely cannot fund the first milestone. An advance is approved by the Committee at the award threshold and published with the award decision — it is not a milestone, so the Manager of record does not approve it.

11.8 Changes.

11.9 Late delivery. A missed milestone requires a written recovery plan within 10 business days, managed by the Manager, and a second consecutive miss triggers a Committee review.

11.10 Termination for cause requires a two-thirds vote, minimum 3, and publication of the reasons; accepted milestones are paid, unearned amounts are not proposed, delivered work product stays with the VST, and any pending payment proposal is cancelled.

What termination leaves behind, by shape (20.2a): for a Service award, the operational handover set and the data export fall due on termination; for an Embedded award, the licence back over embedded pre-existing IP survives termination.

11.10a Recommending termination. The Manager of record or an engaged Technical Reviewer may recommend termination where milestone work or services fall materially below the RFP’s required standard, particularly when:

1. Deliverables substantively fail acceptance criteria;
2. Required remediation is missing or inadequate;
3. Quality gives no reasonable prospect of meeting remaining milestones;
4. Work is not as represented; or
5. A Service award persistently misses published service levels.

File a written recommendation stating the grounds and attaching the milestone determination in the decisions register (7.6a). A Reviewer files directly with the Committee; the Manager must not withhold it. Publish both positions if they disagree. Retention and correction follow 7.6a, including decline, deemed decline, or a strike recorded alongside the recommendation.

Who may not file. A Manager or Reviewer conflicted on the award (6.4) must notify the Committee instead of filing. Only the current Manager of record or a currently engaged Reviewer on that RFP may file.

Effect of filing:

The three outcomes and their thresholds:

Exceptions and resumption:

A recommendation is not a termination. Only the Committee terminates. Neither the Manager nor the Reviewer may stop work, withhold delivered work product, suspend the service, refuse a data export, or tell the awardee the engagement is over.

Good-faith protection. A recommendation is not grounds to end or decline to renew a Manager’s or Reviewer’s engagement; a declined recommendation must not count against them. Their fixed fee is unaffected by the outcome.

12. Program Managers and Technical Reviewers

12.1 Managers and Technical Reviewers are outside contractors, except Committee members engaged as Reviewers under 12.6; the Committee selects them, and VS LLC contracts them under the standard Independent Contractor Agreement using the Schedule A at Exhibit F to MSIG #5, with a published rate card.

12.2 Managers are engaged as a pool, with exactly one Manager of record named and published for each RFP; a Manager may run several RFPs at once.

The initial pool must include at least three Managers, or at least two who are unconflicted on every open RFP. Committee members cannot fill gaps (12.2a).

12.2a No Committee member may serve as Manager of record. There is no MSIG waiver; changing this rule requires an amendment to Part 1 under 16.2.

A Manager appointed to a Committee seat ceases to be Manager of record on appointment execution; the appointment remains valid. Within 5 business days, the Committee must reassign their RFPs under 12.3 and terminate their Manager engagement for those RFPs.

12.3 Reassignment. The Committee assigns a Manager when approving an RFP for publication and may reassign it by majority at any time.

On reassignment:

• Publish the change.
• The outgoing Manager must hand over the approval history, correspondence, and open items in writing.
• The incoming Manager must have no conflict on that RFP.

No unconflicted Manager. Record and publish the shortage and escalate under 9.1. Block producers may direct engagement of a named Manager or another basis of approval; the bar in 12.2a still applies.

12.4 Workload. The Committee must track and report each Manager’s RFP workload.

12.5 Manager and Reviewer pay must not depend on milestone approval or the size, number, or outcome of an award.

12.6 Committee members as Technical Reviewers. Members may serve as paid Technical Reviewers only on the following terms.

12.6.1 Preconditions. A member may serve as Technical Reviewer only if all four requirements are met:

Suspension, substitution, and resumption:

12.6.2 Recusal. The member must recuse from both the availability finding and the vote engaging them. Both require a simple majority of non-recused seats, minimum 3 (5.3).

12.6.3 Member-Reviewer restrictions on that RFP.

12.6.4 A member-Reviewer keeps their award vote and may sign milestone payments on the award, subject to the checks in 11.4.

12.6.5 Pay and disclosure.

12.6.6 Reviewer pay. Reviewer fees are additional to the Committee retainer, subject to 12.6.1 and 12.6.5.

13. Budget limits and reporting

13.1 Limits and funding periods.

Limits. Block producers set the Cycle Ceiling, Per-Award Limit, Program Cost Ceiling, cycle length, and program scope by MSIG Resolution. Ceilings are maxima, not targets; unspent allocations do not carry over.

The Cycle Ceiling caps commitments to awardees. The Program Cost Ceiling caps program operations, with separate internal caps for Committee pay and Manager and Reviewer fees, Portal, and administration. Underspend in one must not raise the other; exceeding either is reserved to block producers under 9.1. Amounts are set in MSIG #5 Part D (Appendix B).

Quarterly funding. Funding is authorized four cycles at a time, covering one year — the authorized funding period. Funds are transferred quarterly under that single authorization, topping the Program Account up to 125% of the coming cycle’s Total Program Spend. Forward commitments count within that cycle’s Cycle Ceiling and do not increase the top-up.

Block-producer control. Block producers may change any amount, cycle length, or limit at any time by MSIG Resolution, and may stop, reduce, or re-time an instalment. A year’s authorization does not oblige them to fund the whole year.

Start dates. The first cycle starts when the Program Account receives funds, not when MSIG #5 passes. That date also starts the four staggered seats’ initial terms under 3.4. Committee pay accrues from the funding date or completion of all onboarding requirements in 3.1a–3.1b, whichever is later. The Committee must publish the funding date on the Portal.

13.2 Reservation. Reserve an award’s full USD value against the Cycle Ceiling from the decision through publication, contracting, the delay, and any MSIG confirmation; reserved amounts are unavailable for other awards. For a multi-cycle award, reserve only the amount payable in the current cycle against its Cycle Ceiling; allocate the rest to future cycles as forward commitments. No payment may move before an agreement exists and the delay ends.

Multi-cycle awards. The Per-Award Limit applies to total contract value over the full term, not each cycle’s payments.

Each forward commitment:

• automatically reduces the available ceiling in each future cycle it falls into;
• is listed in every cycle report, by award, showing the amount landing in each future cycle;
• counts towards the coverage test in section 13.4 for amounts falling due before the next expected transfer.

An award extending beyond the end of the authorized funding period is a reserved matter (section 9) and needs an MSIG Resolution. An award may span cycles inside that period under the mandate, with its value recorded as a forward commitment against the cycles it falls into.

Recurring infrastructure services must use Service awards under 20.2a, with a fixed term followed by re-competition and a contracted operational handover set.

A service renewal is a new award, requiring a fresh RFP, award-threshold decision, and reservation; it is not an extension of the old agreement. The incumbent may bid. Any increase to the old award remains subject to 11.8 and the limits in 13.2; it cannot replace the required fresh RFP for a renewal.

13.3 Release. Release a reservation when:

• The award ends, expires, or is cancelled by block producers;
• Unearned amounts are terminated, including under the Exhibit F clause 6 suspension long-stop;
• The contract is signed for less than reserved;
• A bounty lapses unclaimed under 26a rule 5; or
• The Committee records abandonment: a second consecutive missed milestone with no recovery plan, or no awardee response for 30 days. The Committee must record either event.

Do not release while MSIG confirmation is pending or merely because a termination recommendation is filed under 11.10a; termination itself is required. Released amounts return to the ceiling of the cycle of release, not the original reservation cycle.

13.3a Paying Program Costs. Committee pay, Manager and Reviewer fees, Portal and administration costs are paid from the Program Account under these shared rules:

Rules by payment type:

13.4 Denomination and price movement.

All amounts are denominated in USD and paid in A: the Cycle Ceiling, Per-Award Limit, Program Cost Ceiling and internal caps, awards, reservations, and Committee pay; the Program Account holds A.

Awardees receive the contracted USD value at each milestone, converted to A under this section. State RFP budgets, award decisions, and approval records in USD; record the A amount and rate at each payment.

Conversion timing. Use the block-producer-operated Delphi Oracle (delphioracle), subject to the fallback and suspension rules in 13.4–13.4a.

The Reference Rate is the median field of delphioracle’s datapoints table for eosusd, based on the last 21 qualified submissions; neither the Committee, VS LLC, nor the awardee supplies it.

Conversion. Use the formulas, precision, and arithmetic rules in Exhibit D 3.1–3.2 for oracle and fallback conversions.

Oracle precision. The Committee should note any material effect of the oracle’s fixed USD 0.0001 price increments in the cycle report.

Rate evidence. Record and publish the applicable oracle or fallback evidence required by Exhibit D 3.5 with every approval, whether or not a rate check is triggered.

Rate checks. Use the fallback for a stale rate. A collar breach, or staleness when the fallback is unavailable, requires a Committee decision at the ordinary milestone threshold: approve with the issue recorded, or defer. Neither check automatically blocks payment.

The fallback rate. If the newest eosusd datapoint is more than 24 hours old, or the pair or delphioracle is unavailable, renamed, or deprecated, use (daily high + daily low) ÷ 2 from CoinMarketCap’s published Vaulta (A), ID 36462, USD prices for the UTC day before the read.

The Exhibit D configuration published by VS LLC under MSIG #5 confirms the pair, precision, and worked examples for the oracle and the fallback rate.

Coverage requirements:

A change in the A payment amount is not a top-up: it maintains the USD peg; an award's USD amount must not exceed the Per-Award Limit, and any increase requires the award threshold, a contract amendment, publication, and a fresh proposal and delay (11.8).

13.4a Rate-source failure.

For source failures covered by 13.4, use its fallback; suspend payments only if neither source is available.

The Chair must record and publish the failure within 2 business days of any member or VS LLC becoming aware; the affected award’s Manager is the alternate. Escalate to block producers within 5 business days of that record under 9.2, requesting a replacement source. The Committee cannot choose a substitute.

How payments resume. Suspended payments resume when the fallback returns, the original oracle satisfies the 7-consecutive-day recovery requirement in 13.4, or block producers designate a replacement source. Apply the restored source to payment approvals made after resumption; completed payments are not reopened. The designation amends the Reference Rate definition under 16.2 and is not subject to deemed decline under 9.2.

What stops and what continues

Timing and replacement-source requirements

If an awardee cannot reasonably continue unpaid, use variation or termination by agreement under 11.8; do not substitute a rate or increase the award during suspension.

13.5 Cycle report. The Program Account must remain publicly auditable on-chain. Each cycle, publish a report explaining and reconciling its activity in the publications register (7.6a), display it on the Portal, and send it to block producers. Include:

14. Expiry, suspension, revocation

14.1 The mandate continues until block producers suspend or revoke it, with no fixed expiry date.

Funding remains subject to four-cycle authorization; block producers may decline the next period or stop or reduce an instalment at the Threshold.

14.2 Block producers may suspend or revoke the mandate at any time, without cause, and rebuild the Committee permission through the owner permission.

14.3 Annual review. The Committee must publish an annual review in the publications register (7.6a), covering awards, outcomes, conflict incidents, coverage history, and whether the limits remain appropriate.

14.4 When the mandate ends, by suspension or revocation:

14.5 Existing obligations must remain payable. A Resolution ending the mandate must retain the Committee permission for surviving agreements only or instruct block producers to build a replacement permission.

14.6 After a funding period ends and all contracted obligations are met, return or sweep the remaining balance through the owner permission as block producers direct. Do not carry it into the next funding period; within a period, balances reduce quarterly top-ups rather than being swept each cycle.

15. Trustee and VS LLC roles

15.1 The Trustee acts only as executor and has no RFP-program role; no program funds pass through the Trust (1.3).

15.2 VS LLC administers the program and runs the Portal, contracting with awardees, Managers, Reviewers, and Committee members under the standard Independent Contractor Agreement.

Program funds are Network funds in rfp.vst, not Trust Property. Work product vests in the VST under section 9 of the agreement.

Work product follows the award shape (20.2a): Deliverable awards vest what was built; Embedded awards vest the named deliverable with identified pre-existing IP carved out; Service awards vest the operational handover set. Every shape remains subject to the vesting clause.

VS LLC neither chooses awardees, votes, nor controls the Program Account, and the Committee does not manage VS LLC.

15.2a Platform ownership. The Portal and RFP system code are VST-owned work product under 20.2a; VS LLC operates them but does not own them. For code written before this Framework, complete the transfer with a written copyright assignment from every author to the VST, or failing that a perpetual, irrevocable, sublicensable licence, and transfer to a VST-controlled repository.

15.2b RFP-system awards. The Committee may fund work on the RFP system through the ordinary RFP, award, contract, delay, and signature process; categorize it as Core Development and charge it to the Cycle Ceiling.

VS LLC and connected entities must not bid on RFP-system work. Apply 6.2 as if references to a member referred to VS LLC, including common control and material interests in either direction. Block producers may waive the bar by MSIG Resolution at the Threshold with published reasons. If the Committee finds no other capable provider, escalate the award under section 9.

Where the line falls. Building, extending, or materially reworking the system is an award. Keeping the existing system running unchanged — hosting, domains, certificates, monitoring, backups, administration — is an operating cost under 13.3a.

Classify by whether the engagement changes what the system does, not whether it produces work product.

The Committee, not VS LLC, must classify the work by recorded majority vote, minimum 3.

Flag every RFP-system award as self-referential in the cycle report.

15.3 VS LLC must refuse to contract on a Committee decision that:

• Is plainly outside the mandate;
• Exceeds the Cycle Ceiling or Per-Award Limit; or
• Lacks a complete record.

This checks authority rather than quality. VS LLC must explain its refusal in writing to the Committee and block producers.

15.4 Block producers set limits, appoint and remove members, decide escalations, hold the owner permission, and may cancel payments at the Threshold during the delay. They do not vote on individual awards within the mandate.

16. Reviews and amendments

16.1 The Committee publishes a written self-review 9 months after the funding date, covering RFP throughput, results, conflict incidents, and whether five seats is working.

16.2 Block producers may amend the Framework by MSIG Resolution; the Committee may propose amendments by two-thirds, minimum 3; and Part 2 may be amended without reopening Part 1.

---

PART 2 — RUNNING AN RFP

17. Program overview

The Committee identifies Network needs, publishes RFPs, invites competing proposals, awards against published criteria, and pays against delivered milestones. Open calls and bounties follow sections 26 and 26a.

18. Stage 1 — Collecting needs

18.1 Who can submit. Block producers, Committee members, the Trustee and LLC Manager, ecosystem teams, and the community.

18.2 What a need looks like. The problem, who it affects, what happens if nothing is done, what has been tried, and a rough sense of size.

Needs must describe the problem, not request funding for a named team or solution; return submissions that do.

18.3 Public backlog. Every submission is published with a status: new, under review, prioritized, drafting, published, deferred, or declined. A declined item must carry a reason. Nothing disappears without explanation.

18.4 The Committee reviews new submissions at least monthly. The portfolio holder leads in their category.

19. Stage 2 — Choosing what to fund

19.1 Criteria.

1. Impact — how much does this improve security, usability, adoption, or resilience?
2. Urgency — is there a deadline or a closing window?
3. Feasibility — can an outside team deliver this against a written specification?
4. Duplication — is someone already doing it?
5. Value for money — likely cost against likely benefit.
6. Balance across categories — so that one category does not absorb everything.

19.2 Category shares. Each cycle sets indicative shares by category, covering both the directed program and any open call. They are guidance, not limits. The Committee may depart from them with a recorded reason.

19.3 Output. A published shortlist of what becomes an RFP this cycle and what is deferred.

20. Stage 3 — Writing and publishing an RFP

20.1 Preparing an RFP.

20.2 Every published RFP must contain:

• title and category;
• background and the problem;
• scope — what is included and what is excluded;
• deliverables, specific enough to inspect;
• acceptance criteria for each deliverable;
• milestone expectations — what must be staged, any checkpoint the Committee requires, and a statement of the two-milestone minimum under 11.1a. The RFP does not fix the schedule; proposers submit one and the Committee may modify it before award;
• budget ceiling — published, not hidden;
• timeline: submission deadline, question period, evaluation period, target award date, delivery deadline;
• evaluation criteria and weights, published before submissions open;
• eligibility and conflict rules;
• award shape — Deliverable, Service, or Embedded (section 20.2a);
• IP and delivery terms (section 20.2a): what vests in the VST, and — on any shape — what is expected to be carved out as pre-existing IP; for Deliverable and Embedded awards, the licence mode — Required (with the licence named), Proposer's choice (with the permitted set), or Default — under 20.2a; for Service awards, the service levels, term, and handover and transition requirements under 20.2a;
• decision timeline: award date, contracting step, delay window, expected first payment;
• submission format and channel;
• named Manager of record and contact, and whether a Technical Reviewer is engaged.

The RFP is written to the publications register as published (7.6a), and each numbered amendment under 21.3 is written alongside it rather than replacing it.

20.2a Award shape, work product, and licence. Every RFP must declare its award shape at publication; unsolicited proposals do so at categorization under 26.1. The declaration is fixed and governs the agreement (23.3a) and closing (25.1).

Every agreement must vest the work product defined for its shape in the VST under section 9; Schedule A cannot disapply that clause.

Default licences. Release code under Apache-2.0 and other deliverables under CC-BY-4.0.

Licence mode. Every Deliverable and Embedded RFP declares one of three, at publication:

Service awards have no licence mode: the agreed handover materials vest in the VST, and the Network may modify them and give them to a successor. Default licences do not apply.

Service handover and transition:

1. Each Service RFP must state the handover and transition requirements—including data exports, deadlines, and payment terms—and any material limits on switching providers; the contract must include those requirements.
2. Providers retain ownership of their pre-existing software and IP; any licences must be expressly agreed in the contract.

Licence decisions and locks:

• At the publication threshold, the Committee sets the mode and Required licence, or the Proposer’s-choice permitted set, in the RFP.
• Each RFP sets its own permitted set at scoping; there is no standing list. If Proposer’s choice omits it, the fallback set is Apache-2.0, MIT, or BSD-3-Clause for code; CC-BY-4.0 or CC0-1.0 for non-code.
• Mode, permitted set, and Required licence lock at publication; the proposer’s chosen licence locks at award and must appear in the agreement.
• Score a Proposer’s-choice licence only under a separate criterion and weight published before submissions open (22.1); the standing openness criterion alone does not allow it.
• Explain any departure from default licences in the RFP: name and justify the licence in Required mode, or publish and justify the permitted alternatives in Proposer’s choice mode. The proposer’s actual choice is recorded at award under 23.2.

Closed-source deliverables. At publication, state that usable open-source release is impossible and specify the Network’s alternative: a licence, service commitment, source escrow, or combination. Use Required mode and name the alternative licence; Default and Proposer’s choice are unavailable. Silence means open-source release.

Publication locks. The award shape and Reviewer setting cannot change at contracting, signing, or under 11.8; correct an unsuitable setting in the next RFP. The Reviewer setting governs every assessment throughout the award under 11.2 and 11.4.

20.4 Approval to publish. Majority, minimum 3. Before publishing, the Committee confirms the expected award fits within the Per-Award Limit and the remaining Cycle Ceiling. If an escalation to block producers will be needed, get it before publishing, not after proposals arrive.

20.5 Minimum open period. 21 days normally. 10 days for small or urgent RFPs with a recorded reason.

21. Stage 4 — Questions and submissions

21.1 The RFP is published on the Portal, which is the canonical venue. Anything published elsewhere mirrors the Portal. The Marketing portfolio holder is responsible for reach.

21.2 Questions. All questions must go through the published channel to the Manager of record. Publish every question and answer, without identifying the questioner, in the publications register within 2 business days of the answer (7.6a). No private guidance is permitted.

21.3 Changes. Publish material changes to scope, budget, or deadline as numbered amendments, and extend the deadline by at least 7 days.

21.4 Late submissions. Reject late submissions unless a failure of the submission channel itself is documented.

22. Stage 5 — Evaluation

22.1 Criteria and weights are fixed before submissions open and cannot change afterwards. On an unsolicited proposal they are fixed at categorization under 26.1. Default weights:

Weights may differ by category, but the version used must be published with the RFP.

22.2 Compliance check. The Manager checks completeness, eligibility, conflicts, licence compliance under 20.2a, and the 11.1a schedule: at least two milestones, each with a deliverable, acceptance criteria, amount, and date. Reject non-compliant submissions with written reasons; score schedule quality under 22.1, rather than at the compliance screen.

22.3 Scoring. For unsolicited proposals, use the Reviewer setting and evaluation criteria fixed at categorization (26.1).

In every case a written assessment against published criteria must exist before any award.

22.4 Committee discussion. The Committee receives and discusses the scores and reasoning, and records recusals. It may interview shortlisted proposers only if all receive the same opportunity and questions.

22.5 Departing from the scores. The Committee may award to a proposal that did not score highest, but must publish a written reason.

22.6 Too many recusals. If fewer than three non-recused members remain, or fewer than four can sign, the award goes to block producers with the written scores and a statement of the recusals.

22.7 No good proposals. The Committee may decline to award, change the scope, and republish.

22.8 Negotiation. Limited clarification with the preferred proposer is allowed before the award decision and must be recorded. In Proposer’s choice mode, the offered licence cannot change and becomes an award term; later changes follow 11.8.

23. Stage 6 — Award and contracting

23.1 The award decision, publication, contracting, on-chain proposal, delay window, and payment follow Part 1, sections 10 and 11.

23.2 The decision record must include:

• Awardee, scope, award shape (20.2a), and total amount.
• For Deliverable and Embedded awards, state the Required licence, the proposer’s offered licence in Proposer’s choice mode, or the applicable Default licence. For Service awards, record no licence mode, the handover and transition requirements, any material limits on switching providers, and any expressly agreed pre-existing-IP licences under 23.3a.
• The awarded schedule of at least two milestones and their amounts, any changes from the submitted schedule, and the proposer’s agreement under 11.1a.
• Every member’s vote — for, against, or recused — by name and on-chain account.
• Reasons for departing from the scores.
• The rate evidence at the decision under 13.4: oracle median, block number, transaction ID, and newest-datapoint timestamp, or the fallback’s replacement evidence where it applies.

An incomplete record cannot go to contracting.

23.3 Every awardee agreement must:

• be the standard VS LLC Independent Contractor Agreement with an award-specific Schedule A, under which work product — as defined for the award's shape under 20.2a — vests in the VST (section 9);
• enumerate the milestone schedule — each milestone numbered, with its deliverable, acceptance criteria, amount, and date, at least two of them (11.1a) — matching the published decision exactly. Nothing is paid against a milestone the agreement does not enumerate;
• make the initial award disbursement conditional on clearing the delay and objection process, with the cancellation consequences and exceptions in 10.9, including no liability on either side where the agreement terminates under that section;
• allow termination for non-delivery and for cause, with a period to fix problems;
• include a recovery clause for money paid against milestones later found undelivered or misrepresented, enforced by VS LLC;
• require disclosure of any other Network funding for the same work;
• state the award value in USD and the verified receiving account for payment in A;
• require milestone payments in A at the Reference Rate on the approval-for-payment date, normally the Manager’s determination date, with exceptions for suspension under 13.4a and Committee referral under 13.4;
• confirm the awardee is an independent contractor, not an agent of the Network, the Trust, or VS LLC.

23.3a Contract requirements by award shape (20.2a).

Pre-existing-IP rules apply to every award shape.

Pre-existing IP is material the awardee owned or was licensed to use before the award, or developed independently of the award; it must be identified in Schedule A at contracting. For Deliverable and Embedded awards, unlisted items do not qualify for the carve-out. For Service awards, omission from the list does not transfer ownership of the provider’s pre-existing software or IP.

For Deliverable and Embedded awards, where pre-existing IP is embedded in the work product, the awardee grants the VST an irrevocable licence back, surviving termination, sufficient for the Network to use, modify, and have third parties operate the work product. Service-award licences follow the express contract terms under 20.2a.

Blocking — counsel confirmation. Before using a Schedule A pre-existing-IP carve-out and licence back, record counsel’s confirmation that section 9 of the standard Independent Contractor Agreement permits them. Until then:

• Do not publish Service or Embedded RFPs.
• Do not contract any award with a populated pre-existing-IP schedule.
• A Deliverable award with an empty schedule may proceed.

If section 9 does not permit the carve-out, amend the agreement first; neither Schedule A nor defining work product by shape may narrow its vesting clause.

23.4 Unsuccessful proposals. Unsuccessful proposers may request their own scores and a short written explanation; award publication follows 10.3.

24. Stage 7 — Delivery

24.1 The Manager of record is the awardee’s contact and must:

• Hold check-ins at least every two weeks during active work.
• Report status to the Committee.
• Flag delays early.
• Handle change requests.

24.2 Milestone approval and payment follow Part 1, section 11.

25. Stage 8 — Closing and reporting

25.1 Closing an award. Require final acceptance, final payment, a short public completion note, the shape-specific handover below, and the published review under 25.2, where required. Confirm actual completion.

Terminated awards require their shape’s handover and any review due under 25.2. Final acceptance and final payment are not required after termination under 11.10. For Deliverable and Embedded awards, hand over only work accepted before termination; if none was accepted, close on the published termination record alone.

25.2 Review after large awards. For awards at or above the MSIG #5 Part D threshold (Appendix B), measured on total contract value (13.2), review whether the need was met, the budget was appropriate, and the Network would fund the work again.

Review publication deadlines:

Review requirements:

25.3 Cycle report and annual review follow Part 1, sections 13.5, 14.3 and 16.1.

26. Optional — open call for unsolicited proposals

Unsolicited awards follow the same mandate, thresholds, limits, contract-first rule, publication, delay, and objection bands as directed RFPs. There is no open-call sub-limit; awards share the Cycle Ceiling.

Categorize each proposal on arrival under 2.1 and assign its portfolio holder to lead assessment; cross-category proposals and those fitting no category go to the At-Large seat. Assign a Manager of record in the same way as directed RFPs. Include proposals in the public backlog (18.3) and the cycle report’s category breakdown; indicative category shares under 19.2 cover both channels.

26.1 Terms fixed at categorization. Before assessment starts, the portfolio holder must settle and publish:

Publish these terms on the Portal and in the publications register (7.6a) before assessment begins; they lock at publication on the same basis as directed-RFP terms.

Material changes from the proposal. Notify the proposer and give them 10 business days to accept or withdraw if the settled terms materially differ from their proposal.

The Committee must not re-scope the work; it settles only the terms needed to evaluate and contract.

26a. Bounties

A bounty is a published fixed-price task, open to anyone, paid for the first acceptable delivery. No evaluation or scoring round applies.

The two-milestone minimum in 11.1a does not apply. For 23.2 and 23.3, substitute the fixed price and published acceptance criteria for the milestone schedule, and the publication vote for the proposer’s agreement. Take the award-decision oracle read at the publication vote, providing the 13.4 collar baseline.

Publication and funding

Assessment

Evaluation rules. Sections 21.2, 22.1, 22.4, and 22.5 do not apply. Before acceptance assessment, the Manager checks each delivery’s completeness, eligibility, conflicts, and ban status in receipt order under 22.2; omit milestone-schedule and licence-mode checks. A written acceptance determination against published criteria satisfies 22.3; no scoring, weights, or reconciliation apply.

Acceptance and payment

Cancellation

Safeguards

Use a directed RFP where competitive evaluation would add value, such as comparing capable teams, approaches, or prices; the Committee records that judgment under rule 14. This is not a bounty size limit.

27. General rules

1. Published criteria, weights, budgets, and results. Every judgment is written down and attributable.
2. All questions and answers are public; no private guidance is permitted, including for bounties. The RFP question process follows 21.2.
3. Recusal is required, automatic, and published. Thresholds recalculate on non-recused seats.
4. Nobody scores, approves, or is paid on an RFP they could bid on. The one exception is a Committee member engaged as Technical Reviewer under 12.6 — they are paid on an RFP they are barred from bidding on, and 12.6's guards apply in place of this rule. Material breaches follow 6.6.
5. No splitting or staging to stay under the Per-Award Limit, and no topping up past it later.
6. Departures from scores follow 22.5.
7. Pay after delivery, except for advances under 11.7.
8. Publication, contracting, and payment follow 10.1–10.4.
9. Personal-key restrictions follow 7.4.
10. Every proposal is categorized, directed or unsolicited, so it reaches the right portfolio holder.
11. Everything the community submits gets a status, and a reason if declined.

---

Appendix A — Roles and responsibilities

This is a role guide; the cited sections contain the full rules and exceptions.

Appendix B — Program settings

The table identifies where each setting is defined. Settings in MSIG #5 can change without amending this Framework.