You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The wallet-api allows wallets that implement it (like Ledger Live) to interact with arbitrary applications (called LiveApps today for lack of a better name), interacting with cryptocurrencies (accounts, transactions) in any way, through a unified API.
The goal is to separate wallet functionalities (or “core features”, like managing cryptocurrencies accounts, signing transactions, etc…) that are wallet specific from business / applications functionalities (buying / selling crypto, swapping, integrating a DApp, staking, etc…), that are not wallet specific and can be used by one or more wallets
Examples:
Ledger Live Desktop and Ledger Live Mobile (technically 2 wallets) users want to access onramp and offramp services, DApps, etc…
Ledger Live and Vault might want to allow their users to interact with the Paraswap DApp
Ledger Live and Ledger Connect might want their users to swap crypto
On Ledger Live side, the Wallet API integration is split in 3 main parts:
adapter: converts Wallet API transactions to Ledger Live tx and vice versa
logic: handles the logic of each capabilities handled by the wallet
libs/ledger-live-common/src/wallet-api/logic.ts
UI component (today a WebView): handles the UI rendering of the “web3app” and each wallet-api methods, using the appropriate logic handler defined above
Extend the adapters, logic and webview capability to generalise transactions and capabilities handling.
At a fondamental level, all writing operations are a transaction (sending coins from A to B, interacting with a smart contract, sending an NFT, etc…).
From Ledger Live point of view:
The adapter layer could handle more than a “simple transaction” (sending crypto from A to B) as it does today and handle other flows handled natively by LL, such as sending NFT or staking.
The logic layer would trigger to correct logic according to the tx returned by the adapter layer
The UI component layer would handle the corresponding UI flow depending on the JSON RPC message received or the LL tx converted by the adapter.
We already have similar capabilities on the eth-dapp-browser side for interaction with EVM smart contract (cf. here and here).
The idea would be to have similar conversion functionalities in the wallet side (LL) to craft the corresponding wallet transaction and UX flow depending on the actual action (an NFT transfer is different from an ERC20 send or an unkown smart contract interaction).
⚠️ This would mean providing a low level interface to Wallet API clients (directly interacting with smart contract / crafting a raw transaction).
This might also imply reworking wallet-api transaction types to have more native blockchain transaction types, rather than custom higher level types (inspired from LL types) as is the case today in wallet-api (cf. here)
Is it the goal / scope of the wallet-api product? ❓
Also, can this be generalised to all blockchains? 🤔
This might be a bit of a moonshot, before committing to anything and rushing to implementation, let's discuss the implications, potential blockers and contingencies.
Also, don't hesitate to research and play around with the current implementations and provide links to draft PRs of working example / POC 📚
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Context
The wallet-api allows wallets that implement it (like Ledger Live) to interact with arbitrary applications (called LiveApps today for lack of a better name), interacting with cryptocurrencies (accounts, transactions) in any way, through a unified API.
The goal is to separate wallet functionalities (or “core features”, like managing cryptocurrencies accounts, signing transactions, etc…) that are wallet specific from business / applications functionalities (buying / selling crypto, swapping, integrating a DApp, staking, etc…), that are not wallet specific and can be used by one or more wallets
Examples:
On Ledger Live side, the Wallet API integration is split in 3 main parts:
libs/ledger-live-common/src/families/[FAMILY]/walletApiAdapter.tslibs/ledger-live-common/src/generated/walletApiAdapter.tslibs/ledger-live-common/src/wallet-api/converters.tslibs/ledger-live-common/src/wallet-api/logic.tsapps/ledger-live-desktop/src/renderer/components/WebPlatformPlayer/WebViewV2.tsxapps/ledger-live-mobile/src/components/WebPlatformPlayer/WebViewV2.tsxExploration
Extend the adapters, logic and webview capability to generalise transactions and capabilities handling.
At a fondamental level, all writing operations are a transaction (sending coins from A to B, interacting with a smart contract, sending an NFT, etc…).
From Ledger Live point of view:
The adapter layer could handle more than a “simple transaction” (sending crypto from A to B) as it does today and handle other flows handled natively by LL, such as sending NFT or staking.
The logic layer would trigger to correct logic according to the tx returned by the adapter layer
The UI component layer would handle the corresponding UI flow depending on the JSON RPC message received or the LL tx converted by the adapter.
We already have similar capabilities on the eth-dapp-browser side for interaction with EVM smart contract (cf. here and here).
The idea would be to have similar conversion functionalities in the wallet side (LL) to craft the corresponding wallet transaction and UX flow depending on the actual action (an NFT transfer is different from an ERC20 send or an unkown smart contract interaction).
This might also imply reworking wallet-api transaction types to have more native blockchain transaction types, rather than custom higher level types (inspired from LL types) as is the case today in wallet-api (cf. here)
Is it the goal / scope of the wallet-api product? ❓
Also, can this be generalised to all blockchains? 🤔
This might be a bit of a moonshot, before committing to anything and rushing to implementation, let's discuss the implications, potential blockers and contingencies.
Also, don't hesitate to research and play around with the current implementations and provide links to draft PRs of working example / POC 📚
Beta Was this translation helpful? Give feedback.
All reactions