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:

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:

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:

Implementation Examples
const provider = getKeetaProvider() const accounts = await provider.requestAccounts() // Automatically grants read + transact 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