Wallet Capabilities
Keythings Wallet uses a simplified two-tier capability system that makes dApp connections clear and secure.
Overview
Unlike complex permission systems that can confuse users, Keythings Wallet uses a streamlined approach with just two connection types:
- Read + Transact (Default): Full access for interactive dApps
- Read-Only: Limited access for viewing-only applications
Default Connection: Read + Transact
Most dApps need both read and transaction capabilities. This is the default connection type that provides:
- Read Access: View wallet data, account balances, transaction history, and network information
- Transact Access: Send transactions, sign operations, and interact with smart contracts
Connection Dialog
When a dApp requests default permissions, users see:
Allow localhost:3000 to send transactions and view your wallet data.
Use Cases
- DeFi applications (swaps, lending, staking)
- NFT marketplaces
- Gaming dApps
- Social platforms with transactions
- Any interactive dApp that needs to send transactions
Read-Only Connection
Some applications only need to view wallet information without the ability to send transactions. This provides:
- Read Access: View wallet data, account balances, transaction history, and network information
- No Transact Access: Cannot send transactions or sign operations
Connection Dialog
When a dApp requests read-only permissions, users see:
Allow localhost:3000 to view your wallet data.
Use Cases
- Portfolio trackers
- Analytics dashboards
- Block explorers
- Tax reporting tools
- Any application that only needs to view wallet data
Implementation for Developers
As a dApp developer, you can request the appropriate capabilities:
Security Benefits
The simplified capability system provides several security advantages:
- Clear Permissions: Users understand exactly what they're granting
- Reduced Confusion: No complex permission matrices to navigate
- Principle of Least Privilege: Read-only option for applications that don't need transaction access
- Transparent Dialogs: Connection approval clearly states what permissions are being granted
Best Practices
- Use Default Connection: Most dApps should use the default read+transact connection
- Request Read-Only When Appropriate: Use read-only for portfolio trackers and analytics tools
- Handle Capability Expiration: Implement proper error handling for expired capabilities
- Refresh Capabilities: Proactively refresh capabilities before they expire
- User Education: Explain to users what permissions your dApp needs and why
Migration from Complex Systems
If you're migrating from a more complex permission system, the transition is straightforward:
- Replace Complex Permissions: Map your existing permissions to either read+transact or read-only
- Update UI Text: Use the simplified permission descriptions in your dApp
- Test Both Modes: Ensure your dApp works with both connection types
- Update Documentation: Reflect the simplified system in your user guides