<h2 id="background">Background</h2>
<p>The KILT Protocol maintains a deposit system for several key operations:</p>
<ul>
<li>Decentralized Identifiers (DIDs): 2 KILT</li>
<li>Attestations: [Current deposit amount needed]</li>
<li>AssetDIDs: [Current deposit amount needed]</li>
</ul>
<p>This deposit structure serves as an anti-spam mechanism across the ecosystem but requires evaluation given current market conditions and ecosystem developments.</p>
<h2 id="currentecosystemcontext">Current Ecosystem Context</h2>
<h3 id="baseparameters">Base Parameters</h3>
<ul>
<li>Current DID deposit: 2 KILT</li>
<li>Historical value (ATH): ~$30</li>
<li>Current value: &lt;$0.3</li>
<li>Purpose: Anti-spam and network commitment mechanism</li>
</ul>
<h3 id="ecosystempartnerships">Ecosystem Partnerships</h3>
<ul>
<li>Strategic partnerships (PayPal, Deloitte) provide FIAT onramps</li>
<li>Partners absorb initial token requirements for users</li>
<li>Reduces effective barrier to entry while maintaining security</li>
</ul>
<h2 id="marketanalysis">Market Analysis</h2>
<h3 id="currentsystemstrengths">Current System Strengths</h3>
<ol>
<li>Multi-layered spam protection:</li>
</ol>
<ul>
<li>Deposit requirements</li>
<li>Transaction costs</li>
<li>Partner-assisted onboarding</li>
</ul>
<ol>
<li>Token distribution effect:</li>
</ol>
<ul>
<li>Spreads tokens across more holders</li>
<li>Encourages long-term ecosystem participation</li>
</ul>
<ol>
<li>Flexible entry points through partner networks</li>
</ol>
<h3 id="systemchallenges">System Challenges</h3>
<ol>
<li>Value volatility in FIAT terms</li>
<li>Manual adjustment overhead</li>
</ol>
<p><strong>Comparative Analysis Other Identity Solutions</strong></p>
<ul>
<li>Some projects require no deposit</li>
<li>Others implement dynamic deposit systems</li>
<li>Few use fixed deposit amounts</li>
</ul>
<h2 id="proposaloptions">Proposal Options</h2>
<h3 id="option1dynamicmanualadjustmentsystemrecommended">Option 1: 'Dynamic' Manual Adjustment System (Recommended)</h3>
<p><strong>Target value pegged with a margin of 20% to e.g.:</strong></p>
<ul>
<li>0.3 DOT equivalent +&mdash; 0.6 DOT</li>
<li>$1 USD equivalent +&mdash; $0.2</li>
</ul>
<p><strong>Characteristics:</strong></p>
<ul>
<li>Keeps spread tokens across holders</li>
<li>Requires skin in the game</li>
<li>Maintains protects against spam DeID creation</li>
<li>Regular governance reviews</li>
<li>Manual adjustments through voting</li>
<li>Slow changes as it requires a voting and proposal enactment period</li>
<li>No code changes</li>
<li>Based on current conditions it will increase the deposit ~10 fold of the current deposit</li>
</ul>
<p><strong>Implementation:</strong></p>
<ul>
<li>Regular governance check-points</li>
<li>Quarterly create a proposal for adjustments</li>
</ul>
<h3 id="option3depositremoval">Option 2: Deposit Removal</h3>
<ul>
<li>Complete removal of deposit requirement</li>
</ul>
<p><strong>Benefits:</strong></p>
<ul>
<li>Lowest possible barrier</li>
<li>Easier onboarding</li>
<li>No code changes</li>
<li>Attesters will need to pay for the transaction costs</li>
</ul>
<p><strong>Risks:</strong></p>
<ul>
<li>Reduced spam protection</li>
<li>Loss of token distribution mechanism</li>
<li>Potential system abuse</li>
</ul>
<h2 id="holisticdepositstructure">Holistic Deposit Structure</h2>
<p>Consider unified approach across all deposit types:</p>
<ol>
<li>DIDs</li>
<li>Attestations</li>
<li>AssetDIDs</li>
</ol>
<p>Recommendation: Apply consistent scaling logic across all deposit types while maintaining relative ratios between them.</p>
<h2 id="implementationpath">Implementation Path</h2>
<h3 id="phase1initialadjustment">Phase 1: Initial Adjustment</h3>
<ol>
<li>Discussion Period (1-2 months):</li>
</ol>
<ul>
<li>Community feedback</li>
<li>Partner consultation</li>
<li>Technical assessment</li>
</ul>
<ol>
<li>Technical Review (2 week)</li>
<li>Referendum (1 week)</li>
<li>Deployment (1 week post-approval)</li>
</ol>
<h3 id="phase2monitoringandadjustment">Phase 2: Monitoring and Adjustment</h3>
<ul>
<li>Regular review periods (quarterly suggested)</li>
<li>Predefined triggers for governance proposals</li>
<li>Impact assessment on ecosystem metrics</li>
</ul>
<h2 id="technicalconsiderations">Considerations</h2>
<ol>
<li>Migration path for existing DIDs.
<ol>
<li>deposit recovery mechanisms</li>
<li>locked tokens when increased/decreased deposit requirement</li>
</ol>
</li>
<li>No immediate code changes required for manual adjustment system</li>
<li>Communication strategy to stakeholders</li>
<li>Clear migration documentation for users and partners</li>
</ol>
<h2 id="recommendationdetails">Recommendation Details</h2>
<p>I recommend Option 1 ('Dynamic' Manual Adjustment) because:</p>
<ol>
<li>Maintains system security without code changes</li>
<li>Keeps spread of tokens across holders and will distribute even better as we grow</li>
<li>Allows community governance participation</li>
<li>Can adapt to market conditions through regular reviews</li>
<li>Preserves existing partner integration models</li>
<li>Provides stability through measured adjustment periods</li>
</ol>
<h2 id="futureconsiderations">Future Considerations</h2>
<ol>
<li>Potential automation of adjustment mechanism</li>
<li>Integration with additional FIAT onramps</li>
<li>Partner-specific deposit structures</li>
<li>Cross-chain value pegging mechanisms</li>
</ol>

- **Problem Statement:** Evaluating the deposit system of the KILT Protocol for DIDs, attestations, and AssetDIDs due to market conditions and ecosystem developments.
- **Significance:** Ensuring anti-spam measures and network commitment while considering value volatility and manual adjustments.
- **Proposed Solution:** Implement a 'Dynamic' Manual Adjustment System to adjust deposit values based on market conditions.
- **Expected Outcomes:** Increased security, token distribution, community governance participation, and adaptability to market changes.

#237 KILT Protocol Deposit Adjustment Proposal