> For the complete documentation index, see [llms.txt](https://docs.infrastructure.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.infrastructure.finance/usd.infra-vault/allocation-rule.md).

# Allocation Rule

**TLDR:**

* The Vault does not choose projects at anyone's discretion. Capital is allocated by a published rule with parameters set by governance.
* A project must pass fixed eligibility criteria. Eligible projects are scored and funded in score order, subject to concentration caps and the liquidity sleeve.
* The queue, the scores, and the inputs are published in the Deal Explorer, so anyone can recompute the ordering.
* The rule governs allocation. Servicing, workouts and recoveries follow the Vault's servicing and impairment playbook.

## **Why the Vault allocates by rule**

The Vault is designed so that no person or entity exercises investment discretion over depositor capital. Deployment is determined by a rule published in advance, with parameters set by governance and changed only with notice. The operating roles verify inputs; they do not select projects. This ensures the Vault's position as a passive pool of contracted receivables rather than a managed fund, and gives governance a substantive role.

### **Step 1: Eligibility (binary)**

A project enters the queue only if it meets every criterion. Eligibility is absolute; nothing elsewhere in the rule can make an ineligible project eligible. Governance may modify, supplement, or replace the eligibility criteria and thresholds below only through the notice-and-delay process described in Step 4; once a project is admitted to the queue, later changes do not affect its eligibility.

* Contracted revenue as the source of repayment, verifiable and assignable to the project SPV
* Minimum modeled unlevered project return \[12%]
* Minimum debt service coverage ratio 1.15x
* A servicer and an independent backup servicer in place for the life of the contract
* Obligor and geographic concentration within limits
* Asset class within the Vault's mandate
* Equipment with a documented redeployment value if the contract fails

### **Step 2: Score**

Each eligible project receives a score:

score = risk-adjusted yield + λ × (target share − current share)

Risk-adjusted yield is the project's expected yield net of expected loss (probability of default multiplied by loss given default) and a charge for duration. The balance term keeps the book diversified: governance sets a target range for each asset class and a weight, λ. A class above its range needs a higher score to be funded; a class below it receives a bounded boost. The balance term reorders eligible projects. It never creates eligibility.

### **Step 3: Queue**

Capital above the liquidity sleeve is deployed in descending score order, subject to hard caps on any single asset class and any single obligor. The queue, the scores and the inputs are published in the Deal Explorer.

A project is capital-eligible once it has an executed contract, drawable funds, and completed onboarding. Capital is deployed in descending score order among capital-eligible projects; a project that is not yet capital-eligible keeps its place in score order but does not receive capital until it becomes capital-eligible, so a lower-scored, capital-eligible project may be funded ahead of it.

### **Step 4: Parameters**

Governance sets the eligibility criteria, target ranges, λ, concentration caps and the liquidity sleeve. Changes take effect after a delay 30 days, so the rule cannot be tuned around a project already in the queue. A project already in the queue when a parameter change is adopted remains eligible under the eligibility criteria in effect when it entered the queue until it is funded or withdrawn; the new parameters otherwise apply to the project, including for purposes of calculating its score. Initial values are published before deposits open.

### **Roles and scope**

The curator verifies each project's inputs against the checklist and publishes the queue. The curator has a verification role. The attestation provider validates off-chain inputs used in the exchange rate. Governance sets parameters. The rule governs allocation only; servicing, workouts and recoveries follow the servicing and impairment playbook.