Exhibit D — Program Account, Permission, and Register Configuration

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

Published by Vaulta Stewardship LLC under MSIG #5 Part E.

---

Purpose

This Exhibit defines the setup for the Vaulta Network RFP program’s accounts, signing permissions, payment controls, exchange-rate sources, on-chain registers, and resources. It also provides the deployment and member-key records in section 6, which must be completed before funding under MSIG #5 Part E.

Deployment note

Deployment details and member keys may be added after MSIG #5 is approved. VS LLC must complete both records as required by 6.1, 6.3, and Framework 1.2, and retain dated published versions.

---

• 1. Accounts and authorities
• 2. Payments and cancellation
• 3. Exchange-rate configuration
• 4. Register configuration
• 5. Resources
• 6. Deployment checklist and record
• Appendix A — Worked rate examples
• Appendix B — RAM planning estimates

---

1. Accounts and authorities

1.1 Accounts

1.2 Committee permission

Use separate authorities for fund transfers and administration; each named permission has one threshold. Record the actual permission hierarchy, action links, contract checks if used, and any code authority in 6.1. The three-signature administrative route must not satisfy fund-transfer authority, directly or through a parent or delegated authority. Owner recovery and cancellation remain with block producers at the Threshold. Record both cancellation routes under 2.6.

1.3 Block producer authority

Configure eosio.prods as owner for account and key recovery under Framework 7.3, and payment cancellation under Framework 10.8.

1.4 Register writing and upgrades

Requirements for register-contract upgrades

Any MSIG proposal to change the disc.vst contract must meet these requirements.

---

2. Payments and cancellation

2.1 Selected mechanism

Use the eosio.msig execution delay if available; otherwise use the held-multisignature fallback in 2.3. VS LLC records the selected option and configuration in 6.1 before publication and funding.

Payment proposer. Every payment proposal must be created under rfp.vst, not a member’s or VS LLC’s account. Request rfp.vst@active (4 of 5) approval for the transfer transaction. Assemble the required member-wallet signatures without giving the platform custody of any key.

2.2 Payment delays

With the eosio.msig delay, the timer starts when sufficient approvals are collected. Execution must wait until both that timer and the publication-based delay window have ended.

Under either option, neither VS LLC nor the Committee may waive the wait. Initial award payments also require a published final objection count and clearance under Framework 10.7; four or more objections prohibit execution throughout cancellation and any MSIG-confirmation process.

Later milestone and Program Cost payments still require the delay and allow cancellation, but the objection thresholds do not apply.

2.3 Held-multisignature fallback

If the eosio.msig delay is unavailable, publish the proposal ID with the award. Committee members must withhold approvals until the full delay window ends and, for initial award payments, the published final objection count permits execution under Framework 10.7.

Withholding approvals is a procedural control, not an automatic timelock. Before using the fallback, VS LLC must republish Exhibit D, recording the procedure, cancellation authorities, and a tested guard that rejects premature or objection-blocked execution under Framework 10.7 and 6.1 below. Held approvals alone do not prove that guard. If the guard cannot be demonstrated, do not fund or activate the program; a changed safeguard requires an MSIG amendment, not a configuration waiver.

2.4 Urgent payments

Use the 3-day urgent delay only after publishing the Committee’s urgency vote and reasons, as required by Framework 10.4.

2.5 Contract before payment

VS LLC must sign the awardee’s agreement before any payment is proposed on-chain. The platform must check this before submission, and cycle reports must reconcile payment proposals with signed agreements.

2.6 Cancellation

Pending payment MSIGs may be cancelled through the following authorities. Committee cancellation is mandatory when required by the Framework’s objection rules.

For both routes call eosio.msig::cancel with proposer: rfp.vst, the payment’s proposal_name, and canceler: rfp.vst. Authorize with the permission in the table above. The proposer and canceler remain the same account even when block producers supply its owner authority, allowing cancellation before expiry. Verify both routes against the deployed contract and ABI and record the transactions in 6.1.

Record any configuration limitations in 6.2.

---

3. Exchange-rate configuration

3.1 Oracle settings and conversion

Before publication, confirm the pair, precision, and both worked examples in Appendix A (MSIG #5 Part E and Framework 13.4).

A-units = ⌊ USD-cents × 10^6 ÷ median ⌋, where one A-unit is 0.0001 A.

Use integer arithmetic with truncation, never floating point; the published amount must match the on-chain transfer exactly.

3.2 Fallback settings and conversion

Use the following fallback settings; Framework 13.4 governs when the fallback starts and the oracle resumes.

fallback = ⌊ (high + low) ÷ 2 × 10^6 ⌋, using the published figures and exact decimal arithmetic.

A-units = ⌊ USD-cents × 10^8 ÷ fallback ⌋, using integer division with truncation.

3.3 Staleness and collar checks

Apply Framework 13.4 to triggered checks, including fallback use and Committee approval when required.

A readable oracle can return an old median; record and publish the newest-datapoint timestamp with every approval, even when neither check is triggered.

3.4 Source monitoring and alerts

Apply Framework 13.4–13.4a to source failure, payment suspension, exceptions, escalation, and source replacement. Configure the following monitoring independently of payment approvals:

Raise an alert when a check is inconclusive. Treat an unreadable table as a failure until a later check clears it. Retain cleared alerts.

3.5 Rate evidence

Record the following evidence at every read:

For fallback reads, use the fallback evidence instead of the oracle value, block number, and transaction ID.

---

4. Register configuration

4.1 Account and contract

4.2 Shared record requirements

The contract must have no modify action, erase action, or administrative editing path; platform-only protection is insufficient. A correction must append a new row referencing the prior row’s transaction ID and stating a reason, without changing the prior row.

Store the full record on-chain; the Portal reads and renders it. Keep no hash field.

Screen and redact records before writing, under Framework 5.9, 6.3b, 7.6a, and 25.2; minutes stay off-chain and program decision-makers must remain identifiable.

All three tables must be publicly readable through standard chain APIs, without permission or dependence on the Portal.

4.3 Disclosures table

Use questionnaire version VQ2, defined in Disclosure Questionnaire, document version 1.5, published alongside this Exhibit; store its pipe-delimited answer string unchanged in answers.

Preserve N (None declared) and X (not answered) as distinct codes. Apply the filing, signing, and screening requirements in Framework 6.3a–6.3c.

4.4 Decisions table

Payload by kind

4.5 Publications table

Store program publications other than minutes, proposals, and the backlog here (Framework 7.6a).

---

5. Resources

• Provisioning: The VST and VS LLC must provision and top up both accounts from Program Costs without waiting for a request. Purchase disc.vst RAM before its first write.
• Monitoring: VS LLC monitors resources monthly and reports them in the cycle report.
• Operating costs: Pay VS LLC’s operating work from Program Costs within the USD 40,000 cap in MSIG #5 Part D. The Committee records this classification in the first cycle’s Program Cost schedule and revisits it only if the work changes.

The initial platform build, including all register contracts on disc.vst, is an award under Framework 15.2b.

---

6. Deployment checklist and record

6.1 Checklist and evidence

VS LLC must complete every deployment-confirmation field in this Exhibit and the record below after deployment and before publication, then publish the completed Exhibit before funding (MSIG #5 Part E).

Testnet deployment and rehearsals are required before mainnet deployment. Using the deployed ABI and schemas, verify fund-transfer and administrative thresholds, both cancellation routes, the full ordinary and urgent delays, and the initial-payment final-objection-count guard under Framework 7.2 and 10.7. Record the testnet deployment, test actions, transaction IDs, and results below; configuration descriptions alone do not satisfy this requirement. Verify the deployed eosio.msig code and ABI and the fixed proposer and cancellation parameters in 2.6. Identify and test the guard enforcing the publication-based wait and final count; an approval-holding procedure alone is insufficient. No funding or activation is permitted until these tests pass.

6.2 Departures from the specification

If anything cannot be built as specified, VS LLC must publish the limitation and propose the nearest workable alternative here. Recording a departure does not authorize it: any change to the Framework’s rules or protections requires an MSIG amendment, and funding and activation must wait until the approved requirements are met.

An empty table confirms that the deployment matches this specification.

6.3 Member-key register

Exhibit D may be published before member keys arrive, but this register must be complete before funding or permission activation, along with the other Framework 1.2 requirements.

After each appointment MSIG executes, the member provides their public key to VS LLC, which records their name, public key, and delivery date in this table in the published Exhibit D. Update it when keys are replaced or surrendered, retaining superseded keys in dated rows.

Configure rfp.vst’s on-chain signing permissions with the delivered keys; this table records the configuration and does not grant signing authority. Follow Framework 7.4–7.5 for key handling; replacements use the owner permission.

---

Appendix A — Worked rate examples

A.1 Oracle calculation

A.2 Fallback calculation

---

Appendix B — RAM planning estimates

Planning note. Size RAM for permanent rows, including corrections; do not subtract superseded rows. The launch allocation, monitoring, and top-up requirements are in section 5.

Estimate an Antelope multi_index row as its serialized payload plus 112 bytes of table overhead and 144 bytes per secondary index; assume two secondary indexes for disclosures (filer and date) and decisions (kind and reference).

Estimated annual rows:

Update these estimates using actual row sizes and cadence, including filing and decision text.