Idea: Mandatory Impact Analysis for XLS Proposals

[EnchStyle]

Mandatory Economic Rationale for XLS Amendments

Author: Dr. Artur Kirjakulov ([email protected])
Affiliation: XPMarket
Type: Governance Process Improvement
Status: Discussion

Abstract

This proposal establishes mandatory economic impact assessment requirements for XRP Ledger Standard (XLS) amendments. Current XLS specifications prioritise technical implementation while omitting critical information validators require for informed governance decisions: demand validation, cost-benefit analysis, risk assessment, and adoption projections. This information asymmetry results in validators approving protocol changes without adequate data to evaluate their economic viability or network value. We propose amending the XLS template to require substantive economic analysis before proposals advance to voting status, with validators advised to reject proposals lacking this analysis by default.

---

1. Problem Statement

1.1 The Information Gap

XRPL validators are asked to approve irreversible protocol changes based solely on technical specifications. Current XLS proposals answer "how does this work?" but systematically omit "why should this exist?" This creates an information asymmetry where validators cannot assess:

• Demand validity: Is there genuine market need, or is this speculative?
• Adoption probability: What evidence suggests users will actually use this?
• Cost justification: Do benefits outweigh validator burden and implementation costs?
• Risk profile: What attack vectors, unintended consequences, or failure modes exist?
• Opportunity cost: Are validator resources better allocated elsewhere?

Starting technical development before validating economic demand is methodologically backwards. You cannot evaluate trade-offs without understanding impact.

1.2 Defining Validator Burden

"Validator burden" refers to the concrete, ongoing costs validators incur to support new protocol features. This affects both standalone UNL validators and, more critically, validators running XRPL businesses (wallets, exchanges, explorers) who must understand and implement each amendment.

Time. UNL validators operate without direct incentivisation, volunteering time to read specifications, test amendments, monitor behaviour, and coordinate upgrades. This competes with their primary work. For validators running XRPL businesses, the trade-off is explicit: hours spent testing proposals cannot be spent on commercial development.

Storage. Every new ledger object type increases disk requirements permanently. Full history nodes cannot delete old data. Example: one wallet has issued ~11 million NFTs serving no purpose (estimated 2.5 GB), yet consuming storage validators must provision indefinitely. NVMe SSD costs accumulate.

Operational risk. Each amendment activation introduces potential bugs or consensus disruption. Debugging unfamiliar features under production pressure, especially when running commercial infrastructure, creates stress and downtime risk.

Protocol complexity. As complexity grows, validators must invest more to maintain understanding. More transaction types = more interaction effects, larger attack surface, higher error probability. This is the "burden of knowledge" problem: as total knowledge increases, each individual understands proportionally less of the system.

Opportunity cost. Resources spent supporting rarely-used features represent foregone investment in performance optimisation, security hardening, or features with proven demand.

The asymmetry: If an amendment has low adoption, validators pay these costs permanently while receiving minimal network value. Without market research, validators cannot assess whether benefits justify costs. They vote on speculation rather than evidence.

Side benefits of market research: Beyond demand validation, thorough market research improves technical development standards by identifying real-world implementation requirements early. It facilitates better code examples, clearer documentation, and improved awareness across all stakeholders. The abundance of supporting information (user requirements, integration patterns, edge cases from actual use) results in higher-quality implementations and smoother ecosystem adoption.

1.3 Empirical Evidence

We examine three recent XLS proposals to demonstrate this systematic gap:

Case 1: PermissionedDomains (Amendment: Open for Voting)

Technical specification provides:

• New PermissionedDomain ledger entry type
• PermissionedDomainSet and PermissionedDomainDelete transactions
• Abstract description: "controlled environments within the broader ecosystem"

Source: https://xrpl.org/resources/known-amendments#permissioneddomains

Economic analysis absent:

• Which regulated institutions requested this feature? (Names, jurisdictions, specific requirements)
• What regulatory compliance gap does this address that cannot be solved off-chain?
• Expected number of permissioned domains on mainnet? (10? 100? 1,000?)
• Transaction volume projections within permissioned domains?
• If only 2-3 entities deploy this, does validator overhead justify the feature?
• Comparative analysis: How do competing solutions (Stellar, Ethereum permissioned chains) perform?

Validator decision problem: Without this data, how can validators determine if this feature justifies permanent protocol complexity?

Case 2: Credentials (XLS-70, Amendment)

Technical specification provides:

• Complete implementation of on-chain credentials for KYC/identity management
• Example workflow with hypothetical actors (Verity, Isabel, Alice)
• Integration with DepositPreauth

Source: https://xls.xrpl.org/xls/XLS-0070-credentials.html

Economic analysis absent:

• Quantified KYC cost problem: How many institutions currently perform redundant KYC on XRPL?
• Cost-benefit: What is the estimated cost saving per institution?
• Commitment evidence: Which credential issuers (identity verification services) have committed to issuing credentials?
• Adoption projections: What percentage of XRPL users would hold credentials within 1 year?
• Alternative analysis: Why on-chain credentials vs. OAuth/SAML/existing identity systems?
• Computational burden: What is the validator overhead for credential verification on every affected transaction?
• Systemic risk: What happens when credential issuers delete accounts?

Validator decision problem: Without demand validation, this could be a sophisticated solution to a non-existent problem.

Case 3: Multi-Purpose Tokens (XLS-33, Amendment: Enabled)

Technical specification provides:

• Strong storage efficiency argument (234 bytes per trustline vs. 52 bytes per MPT)
• Clear technical advantages: fixed-point arithmetic, simpler conceptual model
• Disadvantages: adds third asset type, increases payment engine complexity

Source: https://xls.xrpl.org/xls/XLS-0033-multi-purpose-tokens.html

Economic analysis absent:

• Issuer commitment: Which stablecoin issuers have committed to MPTs vs. continuing trustlines?
• Migration timeline: When would issuers realistically transition?
• Adoption baseline: How many existing trustlines are candidates for MPT conversion?
• Network-level savings: If X% of issuers adopt MPTs, what is the total storage reduction on mainnet?
• Liquidity fragmentation risk: Quantified impact of introducing a third asset type on DEX efficiency
• Validator cost reduction: claims 78% space savings per token holder, but never quantifies: (a) what percentage of existing trustlines are candidates for MPT conversion, (b) the total storage reduction on mainnet if X% of issuers adopt, or (c) the monthly cost savings in USD for validators running different hardware configurations.
• Failure scenario: If adoption is <10% of projections, is this permanent technical debt?

Validator decision problem: Strong technical merit, but unclear if the market needs this or will adopt it.

1.4 Systemic Pattern

These are not isolated cases. The pattern is systemic: XLS proposals consistently omit economic rationale. This is not a criticism of individual authors, it reflects an institutional gap in the XLS process itself.

The current template does not require economic analysis, so authors rationally optimise for what is required: technical correctness. The result is validators making governance decisions under information scarcity.

---

2. Proposed Framework

2.1 Mandatory Assessment Criteria

All XLS proposals introducing new transaction types, ledger objects, or protocol modifications must include substantive analysis across five domains:

Domain 1: Market Validation

• Identity of demand sources (entities, user segments, market size)
• Evidence of demand (commitments, surveys, letters of intent, community requests)
• Competitive analysis (how others solve this; lessons from their adoption data)

Domain 2: Economic Impact

• Network value proposition (utility increase, transaction volume growth, liquidity improvement)
• Validator cost-benefit analysis (storage, compute, bandwidth costs vs. fee revenue increase)
• Revenue opportunities for ecosystem participants (exchanges, wallets, validators)

Domain 3: Risk Analysis

• Attack vectors (economic exploits, Sybil, spam/DoS)
• Unintended consequences (storage bloat, fee distortion, liquidity fragmentation)
• Failure modes (low adoption scenarios, deprecation difficulty, infrastructure gaps)

Domain 4: Ecosystem Readiness

• Stakeholder consultation evidence (exchanges, wallets, developers, validators)
• Integration requirements and timeline estimates
• Infrastructure dependencies and availability

Domain 5: Success Metrics

• Measurable adoption targets (accounts, transaction volume, timelines)
• Performance benchmarks (resource usage, network impact)
• Post-activation review commitment

2.2 Evidence Standards

Acceptable evidence:

• Named entities with letters of commitment or partnership agreements
• Survey data from target user segments
• Testnet adoption data showing actual usage
• Competitive market analysis with adoption metrics
• Quantitative cost-benefit modeling (even if approximate)
• Stakeholder consultation records

Insufficient evidence:

• Hypothetical user personas without real-world validation
• "This could be useful for..." speculation without demand signals
• Technical elegance arguments without market evidence
• Assertion that competitors have similar features (without adoption data)

2.3 Validator Decision Framework

Threshold for advancement: Proposals should not progress from Discussion to Draft status without substantive analysis in all five domains.

Voting guidance: Validators evaluating proposals should apply:

IF (market validation is absent OR demand evidence is weak) THEN abstain/reject
IF (cost-benefit analysis shows net negative) THEN reject  
IF (major unmitigated risks identified) THEN reject
IF (ecosystem stakeholders not consulted) THEN defer for consultation
IF (all criteria met with credible evidence) THEN evaluate technical merit

Default position: In absence of economic justification, validators should abstain or vote against. The burden of proof lies with the proposer.

---

3. Implementation

3.1 Template Modification

Amend xls-template.md to include mandatory sections:

1. Market Analysis (2-4 pages minimum)
2. Economic Impact Assessment (2-3 pages minimum)
3. Risk & Failure Analysis (1-2 pages minimum)
4. Ecosystem Readiness (1-2 pages minimum)
5. Success Metrics & Review Plan (1 page minimum)

Proposals lacking substantive content in these sections will not be assigned XLS numbers or advance to Draft status.

3.2 Adoption Pathway

Phase 1: Community discussion and refinement of requirements

Phase 2:

• XRPLF adopts updated template
• Publish "Validator Economic Assessment Guide"
• Notify authors of pending proposals (PermissionedDomains, Credentials, etc.)

Phase 3:

• Pending proposals must supplement with economic analysis to advance
• New proposals must comply from inception

Phase 4:

• Post-activation reviews for recently enabled amendments
• Refinement of assessment criteria based on experience

3.3 Scope

Applies to: New transaction types, new ledger objects, protocol modifications affecting consensus, fee structures, or network economics

Does not apply to: Bug fixes, optimisations, technical debt reduction, security patches

---

4. Comparative Context

This proposal aligns XRPL governance with best practices from other blockchain ecosystems:

• Ethereum EIP-1559: Included economic modeling, fee burn analysis, miner impact assessment, and game-theoretic security analysis before approval
• Cosmos Hub: Governance proposals require cost estimates, stakeholder impact analysis, and risk assessment
• Polkadot RFC: Mandatory motivation sections require real-world use cases and demand evidence

XRPL should not have lower standards for governance rigor than its competitors.

---

5. Anticipated Objections

"This creates bureaucratic overhead."
Counter: Market validation accelerates good ideas by filtering out low-impact proposals early. Time spent on economic analysis is time saved on developing features nobody uses.

"Not everything can be quantified."
Counter: Qualitative analysis is acceptable where quantitative data is unavailable. But "qualitative" does not mean "speculative", it means structured interviews, stakeholder consultations, and reasoned analysis.

"This will slow down innovation."
Counter: Shipping features nobody uses is not innovation, it is waste. Validators' time and XRPL's protocol complexity are scarce resources. Efficient allocation requires data.

"Who validates the economic analysis?"
Counter: The validator community, through the same discussion process used for technical review. If economic analysis is unconvincing, validators request strengthening or reject the proposal.

---

6. Conclusion

XRPL validators govern a production financial network. Governance decisions require economic data, not just technical specifications.

Current XLS process systematically omits:

• Demand validation
• Cost-benefit analysis
• Risk assessment
• Adoption projections

This information asymmetry forces validators to approve amendments "blind" to their economic viability.

The solution is procedural: Require economic analysis as a precondition for advancement through the XLS process. Validators should reject proposals lacking this analysis by default.

This is not anti-innovation, it is pro-rigor. If a feature cannot survive economic scrutiny, it should not consume validator resources and protocol complexity.

I propose XRPLF adopt mandatory economic assessment requirements for all protocol amendments, effective immediately.

---

Appendix A: Detailed Assessment Checklist

For XLS authors, here is a detailed checklist of required content for each mandatory section:

Section 1: Market Validation (2-4 pages)

Required Questions:

1. Who needs this feature?

   • Specific user segments with size estimates
   • Evidence: surveys, community requests, issuer commitments, letters of intent

2. What is the addressable market size?

   • Number of potential accounts/entities
   • Expected transaction volume (daily/monthly projections)

3. Why can't this be solved off-chain or with existing XRPL features?

   • Why on-chain solution is necessary
   • Current workarounds and their limitations

4. Which entities have committed to using this?

   • Named companies/projects (if public)
   • Partnership agreements or letters of support
   • Testnet usage data

5. How do competing ledgers handle this?

   • Examples from Ethereum, Stellar, Solana, etc.
   • Their adoption metrics
   • Lessons learned

Section 2: Economic Impact Assessment (2-3 pages)

Required Analysis:

1. Network Value Creation

   • How this increases XRPL utility
   • Transaction volume increase projections (% or absolute)
   • Active account growth projections
   • Liquidity impact (if applicable)

2. Validator Cost-Benefit

   • Storage requirements per new object type
   • Computational overhead per transaction
   • Network bandwidth impact
   • Monthly cost increase per validator (USD estimate)

3. Monetisation Opportunities

   • Exchange revenue opportunities
   • Wallet revenue opportunities
   • dApp revenue opportunities
   • Validator benefits

4. Status Quo Comparison

   • Side-by-side with existing functionality
   • Migration cost estimates
   • Adoption timeline projections

Section 3: Risk & Failure Analysis (1-2 pages)

Required Identification:

1. Attack Vectors

   • Economic exploits
   • Sybil vulnerabilities
   • Spam/DoS vectors

2. Unintended Consequences

   • Storage bloat scenarios
   • Liquidity fragmentation risks
   • UX degradation risks
   • Regulatory risks

3. Failure Modes

   • Low adoption scenarios (<10% of projections)
   • 1-year post-activation negligible usage
   • Deprecation difficulty assessment
   • Infrastructure support gaps

4. Mitigation Strategies

   • Safeguards for each identified risk
   • Monitoring metrics post-activation

Section 4: Ecosystem Readiness (1-2 pages)

Required Documentation:

1. Exchange Impact

   • Integration work required
   • Engineering cost estimates
   • Consultation evidence (major exchanges)
   • Support timeline commitments

2. Wallet Provider Impact

   • UX changes needed
   • SDK update requirements
   • Provider consultation evidence
   • Support commitments

3. Developer Impact

   • Library changes (xrpl.js, xrpl-py, etc.)
   • New APIs/tooling needed
   • Reference implementation status

4. Validator Impact

   • Upgrade complexity assessment
   • Operational risks during activation
   • Consultation evidence

Section 5: Success Metrics (1 page)

Required Definitions:

1. Adoption Targets

   • 6-month, 1-year, 2-year targets
   • Account/transaction volume thresholds
   • Example: "50 MPT issuances with >10,000 holders within 1 year"

2. Performance Benchmarks

   • Validator resource usage limits
   • Network throughput impact
   • Storage growth rate caps

3. Review Schedule

   • Post-activation review commitment (6 months, 1 year)
   • Action plan if metrics not met

---

Discussion Questions

1. Should economic assessment requirements apply to all XLS, or only those introducing new transaction/ledger types?
2. What minimum evidence standards should apply for "demand validation"?
3. Should there be a formal economic review committee, or should validators self-assess?
4. How should pending proposals (already in Draft/Proposed status) be handled?
5. Should testnet adoption data be mandatory before mainnet proposals?

---

I welcome community feedback on this proposal. The goal is not to obstruct innovation but to ensure XRPL governance decisions are data-driven and economically sound.

---

Updates

2025-10-17: Added Section 1.2 "Defining Validator Burden" in response to @Tapanito's feedback. This explicitly defines what validator burden entails (time, storage, operational risk, protocol complexity, opportunity cost) with concrete examples. Subsequent sections renumbered accordingly.

[Tapanito]

@EnchStyle I'm still reading through your proposal, it's quite interesting, and I agree with the general sentiment.
One thing you mention multiple times is validator burden, can you update your proposal to explicitly describe what this burden entails?

[EnchStyle]

By "validator burden" I mean the real costs validators incur to support new features. This is relevant when validators act ONLY as UNL validators (do not run any project/company on XRPL), and this get significantly amplified when a validator is an active XRPL project that has to understand the amendment AND later to implement it (i.e. wallets, DEX UIs, explorers).

1. Time is probably the biggest one. Since UNL validators aren't directly incentivised, they're volunteering their time to read specs, test amendments, monitor post-activation behaviour, and coordinate upgrades. This competes with their actual jobs. Specific example: my team has to either spend time on testing XLS, or developing XPMarket. Priority will likely be with commercial part, rather than unpaid one.
2. Storage costs are ongoing and permanent. Every new ledger object type increases disk requirements forever. Full history nodes can't delete old data. NVMe SSDs aren't cheap, and storage needs only grow. Recent example: we have NFTs (obviously), but we also have a wallet that has issued almost 11M NFTs that server no purpose and take space, which costs memory.
3. Operational risk matters. Each amendment activation could introduce bugs (which is normal! but undesirable). Debugging unfamiliar features under production pressure is stressful.
4. Protocol complexity. More transaction types = more to understand, more interaction effects to track, larger attack surface to worry about. Plus more space of error (here we do speak from experience). Something I call "burden of knowledge".
5. Opportunity cost. Resources spent supporting a feature only 3 entities use could have gone towards performance optimisation, security hardening, or features with proven demand.

The core problem: If an amendment has low adoption, validators pay these costs permanently for minimal network value. Without market research, they can't assess whether benefits justify costs, they're betting blind on speculative utility.

That's why I'm arguing economic rationale should precede technical development. It shows validators the demand evidence, adoption projections, and cost-benefit analysis before asking them to commit resources forever.

A side effect to that is media coverage. Once an XLS is released and has some market data, this is also good for PR and extra speculation, and hence attention.

Ops, started typing and got carried away. Sorry. :)

[Tapanito]

All good, could you include above in your proposal, so that it does not get lost in the weeds of the discussion :)

[Platonenkov]

Great idea @EnchStyle — adding mandatory economic impact analysis for each XLS proposal can make the process more transparent and responsible.
But there are a few key nuances to consider:

1️⃣ Different XLS types need different scopes.
Consensus changes ≠ transaction tweaks. It makes sense to define templates by category (core, tx, governance).

2️⃣ Minimum metrics.
Without some quantitative indicators, analysis risks becoming just words. At least include basics: fee impact, transaction volume, liquidity, risks.

3️⃣ Progressive adoption.
Full analysis shouldn’t be required at the “Discussion” stage.
Start with brief reasoning early on, and request detailed studies only at “Draft” or “Proposal” level.

4️⃣ Who reviews it?
Validators shouldn’t be forced to evaluate economic models. Better to have community or XRPLF expert review before validator voting.

5️⃣ Exceptions.
Bug fixes or purely technical improvements shouldn’t require analysis.

6️⃣ Retrospective reviews.
After activation, publish short “what actually happened” summaries. This builds accountability and a record of outcomes.

The idea is excellent, but it still needs to be implemented in stages, with templates, metrics, and expert validation. Then the amendment will truly improve the quality of standards without hindering the development of the XRPL.

[EnchStyle]

I am happy to take any suggestions here. I have had this idea in my head for quite some time, but today there were a few triggers to release it and see how people will react it. I honestly believe having this vital addition will serve a great deal. It will not only help the validators, but it will also help the shape the actual proposal during technical composition.

[Platonenkov]

Even the best analysis can be wrong.
To improve accountability, the standard could include a post-implementation review (e.g. 3–6 months after amendment activation).

Suggestion:
Each XLS with economic analysis must include:
Metrics to monitor after activation
Expected vs. actual results
Optional update post summarizing learnings
This builds institutional memory and transparency.