V1 to V2 Migration Guide

This guide helps you migrate from Self Protocol V1 to V2. V2 introduces multi-document support, dynamic configuration, and improved data structures.

Overview of Changes

What's New in V2

  • Multi-document support: E-Passports and EU ID Cards

  • Dynamic configuration: Switch configurations without redeployment

  • Enhanced data formats: Pre-extracted, human-readable outputs

  • User context data: Pass custom data through verification flow

  • Improved error handling: Detailed configuration mismatch reporting

Breaking Changes

  • Backend SDK constructor requires new parameters

  • Configuration methods replaced with interface

  • Verification method signature changed

  • Frontend requires disclosures object

  • Smart contract interfaces updated

Backend Migration

1. Update Dependencies

2. Update Constructor

V1 (Old):

V2 (New):

3. Update Configuration

V1 (Old):

V2 (New):

4. Update Verification Method

V1 (Old):

V2 (New):

5. Handle New Response Format

V1 Response:

V2 Response:

Frontend Migration

1. Update Dependencies

2. Update QR Code Configuration

V1 (Old):

V2 (New):

3. Important: Disclosures Object

The disclosures object in V2 contains both verification rules and data fields:

Smart Contract Migration

1. Update Contract Inheritance

V1 (Old):

V2 (New):

2. Update Hub Addresses

V2 Hub Addresses:

3. Handle New Data Structure

V1 Structure:

V2 Structure:

Common Migration Issues

1. Configuration Mismatch

Problem: Frontend disclosures don't match backend configuration

Solution: Ensure frontend and backend have identical settings:

2. Missing Attestation ID

Problem: Verification fails with missing attestation ID

Solution: Frontend must send attestation ID:

3. Invalid User Context Data

Problem: User context data validation fails

Solution: Ensure proper hex encoding:

4. Document Type Not Allowed

Problem: "Attestation ID is not allowed" error

Solution: Add document type to allowedIds:

Testing Your Migration

1. Test with Mock Passports

2. Test Both Document Types

3. Verify Configuration Switching

Best Practices

1. Configuration Management

  • Store configurations in a database for easy updates

  • Version your configurations for rollback capability

  • Use meaningful config IDs (not just hashes)

  • Document configuration requirements

2. Error Handling

3. Security Considerations

  • Always validate attestation IDs

  • Store and check nullifiers to prevent replay

  • Use appropriate scopes for different use cases

  • Never expose configuration details to frontend

4. Performance Optimization

  • Cache configuration objects

  • Reuse verifier instances

  • Batch verification requests when possible

  • Use connection pooling for RPC calls

Resources

Need Help?

If you encounter issues during migration:

  1. Review example implementations

  2. Report issues at GitHub Issues

Last updated