Summary

  • On 3 May 2026, ICANN's Board removed the Supplemental Fund for Implementation of Community Recommendations' restriction to Board-approved community recommendations, renamed it the Project Fund and directed the President and CEO or a designee to develop the rules for funding qualification.
  • The same Board record preserves two important controls: every use of the Project Fund still requires Board approval, and spending must appear in ICANN's financial reporting. The expansion is not a delegation of final spending authority to staff.
  • On 28 May, staff forecast a US$18–21 million FY26 operational surplus and identified the Project Fund as a possible destination for eligible work such as technology modernization. The BFC minutes also say a recommendation would follow fiscal-year close and audit. No allocation or project approval is proved by that discussion.
  • ICANN's public-comment report supplied expected characteristics—outside the annual operating plan, large in scope and cost, and multi-year—but the Board still ordered a later qualification rule. A durable public receipt should join that rule version to project facts, consultation, separate transfer and use resolutions, drawdown, results and closure.

The authorization card with one blank field

The old SFICR arrived with an inherited answer to the first eligibility question. It supported large, complex or multi-year implementation of community recommendations that the Board had approved but that did not fit inside an annual budget. A candidate project still needed money and a Board decision, but its origin supplied a recognizable first-stage mandate: a documented community recommendation followed by Board approval.

The Project Fund is deliberately broader. Under resolutions 2026.05.03.01–.03, it may support any qualifying project. ICANN's rationale names building improvements and upgrades to technology infrastructure, security and equipment as examples of work that the SFICR could not previously fund. Community recommendations remain eligible, but they are no longer the defining class.

That may be a sensible response to capital work that crosses fiscal years. A roof, security platform or infrastructure replacement does not become recurring operations merely because it lacks a policy-development pedigree. The governance change is real nevertheless. When the inherited community-recommendation predicate disappears, the institution must publish another way to distinguish an exceptional project from ordinary operations, a deferred maintenance item, a strategic initiative and a convenient second budget.

The Board recognized that need in the operative text. Resolution 2026.05.03.02 does not say the qualification rule is already complete. It directs ICANN's President and CEO, or a designee, to develop the rules for funding qualification. Scope and qualification therefore entered the record as separate decisions: the Board opened the class; management was instructed to write the predicates.

That sequence does not prove a defect or unauthorized use. It creates a monitoring boundary. Before the first new-category project is approved, an outside reader should be able to identify the rule version against which it qualified. Without that join, the public may see a project, an amount and a Board vote but still be unable to tell why the work entered the exceptional fund rather than the annual Operating Plan and Budget.

What the Board decided—and what it did not

The 3 May action changed two parts of ICANN's financial architecture. First, it converted the SFICR into a broader Project Fund. Second, it amended the Reserve Fund thresholds: the minimum remains twelve months of budgeted operating expenses, the target is sixteen months and the maximum is twenty-one months. Funds above the maximum can be redeployed through the hierarchy described in the Investment Policy.

Those numbers create an ordered set of controls, not a conveyor belt. ICANN's Operating Fund must first protect daily operations at its minimum level, which remains three months of budgeted operating expenses. The Reserve Fund protects continuity and unforeseen costs through its own minimum, target and maximum. The Project Fund can receive an allocation useful for project activity. An excess above one threshold does not identify the project, set the amount, transfer the money or authorize expenditure by itself.

The Board's rationale is explicit about the retained authority. Transfers into the SFICR historically required Board approval, as did each use. The Project Fund continues that pattern. Spending is to be included in ICANN's financial reporting. The broader scope therefore does not turn a staff eligibility finding into a payment instruction.

It is equally important not to overread the phrase any qualifying project. Any broadens the universe after qualification; it does not delete qualification. A building improvement, technology upgrade or security purchase is an example of a possible class, not a standing appropriation. Mission fit, exceptional scale, timing and relation to the ordinary budget still need to be established for the named proposal.

The Board described the 3 May policy action as having no immediate fiscal impact. That is consistent with the decision layers. Changing a fund's permitted scope and investment-policy label does not itself transfer or spend cash. Fiscal impact begins with later allocations, approved uses, contracts and disbursements.

US$18–21 million was a forecast, not a transfer

The later BFC minutes of 28 May make the qualification issue timely without completing any transaction. Staff said FY26 expenses were generally in line with budget while funding was projected to exceed budget, principally because domain-name market activity was stronger than expected. The resulting operational-surplus forecast was US$18–21 million.

The minutes place the balances in context. The Operating Fund and Reserve Fund were above their minimum levels, and the Reserve Fund was slightly above its target. Staff identified the Project Fund as a potential place to allocate expected surplus and mentioned technology modernization as an example of eligible work.

Every limiting word matters. Projected is not audited. A range is not a closed-year balance. Potential is not selected. Eligible is not approved. An example is not a project specification. The BFC recorded an action for staff to provide a formal recommendation after the fiscal year ended. It also said the recommendation would follow completion of the audit.

The correct state on 28 May was therefore allocation option under discussion. It was not US$18–21 million transferred to the Project Fund, and still less technology modernization funded. A faithful record should keep at least four quantities apart: forecast surplus, final audited surplus, Board-approved transfer and project-level approved drawdown.

This distinction matters because a rounded headline can compress all four. Readers hear that ICANN expects up to US$21 million, that its Project Fund now covers technology, and that technology modernization is eligible. The statements are individually sourced. Joined without their states, they falsely produce a completed capital programme.

The historical record shows the missing steps. On 30 October 2025, the Board approved a specific US$12 million transfer from FY25 Operating Fund excess to the then-described SFICR/Project Fund. That resolution names the closed year, the source fund, the amount and the decision authority. A future FY26 transfer should generate its own comparable record rather than inherit the 28 May forecast.

Consultation supplied conditions, not a blank endorsement

ICANN submitted the fund change to public comment as part of the FY27–31 operating and financial planning package. The 2 April summary report says four of six guided respondents found the reason for expansion clear and one answered somewhat. It also preserves questions from several groups and an individual about transparency, eligibility criteria and oversight.

ICANN's response provided a useful starting shape. Project Fund work was expected to resemble SFICR work in three respects: it might not be included in the annual operating plan, might be large in scope and cost, and might span multiple fiscal years. ICANN confirmed that the Board would approve use and said the community could express views through the annual Budget process and by liaising with the Board.

Those statements reduce ambiguity. They do not eliminate the need for the rule the Board later ordered. Words such as may, large and multi-year need operational edges. Is work ineligible if it could have been anticipated in the annual budget? How large is large relative to the recurring budget? Can a project last two fiscal years but mainly pay recurring staff costs? What evidence shows that splitting the work would be worse? What happens when scope grows after approval?

The ccNSO SOPC submission asked who decides what counts as a project, what oversight the community would have and whether the mechanism could bypass standard budget scrutiny. ALAC's submission stressed that Board approval should continue. Alfredo Calderon-Serrano called for visibility and a distinction between community-driven priorities and internally initiated projects.

These are attributed governance questions, not evidence that ICANN has already misused the fund. Their proper place in the record is as inputs with dispositions. Saying that the community supported the expansion is accurate at a high level; using that sentence to erase conditions, questions and requested safeguards would make consultation less informative than the source record.

Consultation also does not transfer ownership of the decision. Participants contribute knowledge, costs, alternatives and challenge. The Board remains responsible for the final use of ICANN's funds. A sound ledger therefore records both: what material issues were raised and how the authorized body addressed them.

A fund is not a budget with a different name

ICANN's planning process links a strategic plan, a five-year operating plan, an annual operating plan and budget, and achievement reporting. That ordinary chain exposes recurring commitments to an integrated view of priorities, headcount, funding and trade-offs.

An exceptional project fund serves a different purpose. It can protect multi-year work from an artificial fiscal-year cutoff and prevent one large capital item from distorting recurring operations. Its legitimacy depends on remaining exceptional. If predictable operating costs or standing programmes migrate into the Project Fund, the annual budget loses comparability even when every individual payment is properly approved.

That is why not included in the annual operating plan cannot be a self-justifying criterion. A proposal should explain why it is outside the plan: the need arose after adoption, the project is genuinely non-recurring, the size and duration would impair ordinary operations, or another stated reason applies. Merely omitting work from the annual plan cannot make it eligible for the fund created to handle work outside that plan.

The Project Fund must also remain distinct from the ICANN Grant Program. The Grant Program uses 2012 new gTLD auction proceeds and follows its own grant-making architecture. The Project Fund is replenished through Board-approved allocations from Operating Fund excess after higher-priority needs. Similar words—project, grant, initiative—do not merge the pools, authorities or reporting duties.

The same separation applies to the Reserve Fund. A Reserve balance above target or maximum affects the hierarchy of possible allocations. It does not turn the Reserve into project revenue or make a proposed drawdown self-executing. Threshold, transfer and use are three different acts.

The qualification-and-use receipt

A public rule should be short enough to use and complete enough to test. Its first record needs a stable identifier, version, effective date and approving authority. Each project then needs its own application against that rule rather than a prose assertion that the work is strategic or important.

The application should name the project, public owner and accountable executive. It should identify mission and public-interest fit; explain why the work is outside the ordinary annual plan; state scope, cost range, duration and deliverables; and show which eligibility predicates were satisfied by which evidence. It should identify whether the project arose from a community recommendation, an internal operational need or a mixed source.

The reasoning record should include alternatives: ordinary-budget treatment, a smaller scope, phased delivery, delay and rejection. It should preserve material comments and their dispositions without turning comment volume into a vote. Conflicts and recusals belong with the decision. The BFC recommendation and Board resolution should point back to the exact rule version and application.

Money then needs its own chain. The record should distinguish the source fund, transfer amount, permitted drawdown, actual expenditure, remaining balance and financial-statement reference. Changes in scope or cost should create new approvals, not silently overwrite the initial estimate. Completion should record outputs, variance from plan, unused funds and the authority that closed or cancelled the project.

Some details may properly remain protected. Security architecture, personal information, vendor negotiation and commercially sensitive unit prices do not need to be exposed. Redaction should remove those details without removing the predicates, approving authority, amount, reason, status and correction path. Confidentiality can narrow the public receipt; it should not dissolve it.

This joined record protects management as much as it informs the public. It shows that a useful capital project was not smuggled around ordinary scrutiny, that the Board saw the relevant trade-offs and that later cost changes were attributable. It also lets the institution correct a classification without pretending the earlier version never existed.

What the checked record establishes

The checked official record through 27 August establishes a completed scope decision, a renamed fund, a Board-protected approval boundary, expected eligibility characteristics, a delegated rule-writing instruction and a later surplus forecast. It does not establish a final audited FY26 surplus, a transfer of that surplus, an approved technology-modernization project or actual Project Fund spending from the forecast.

The official searches used for this report did not locate a separately published final qualification-rule document. That is a bounded search result. ICANN may have internal work in progress or may publish a rule after the cutoff. The appropriate monitoring response is to look for the instrument ordered by resolution 2026.05.03.02, not to convert a search gap into an allegation of hidden conduct.

Heng Lu's analysis of the agency problem in Internet governance provides an interpretive discipline: control, incentives, responsibility and remedy should remain joined. It does not establish the facts of an ICANN allocation. Here the practical application is modest. Management may develop the rule; the Board approves use; commenters supply evidence and challenge; financial reports show execution. A trustworthy record keeps those roles separate and connected.

The decision now facing observers is not whether ICANN should reject every internally initiated project. It is whether the Project Fund will obtain its public operating grammar before the first broader use asks readers to reconstruct eligibility from a name and a vote. The Board has already preserved the endpoints. The missing work is to make the path between them inspectable.

Sources