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 projectId is publicly available and anyone can copy the projectid of dapp/wallet and (ab)use it. Both WalletConnect and users want to ensure that third parties cannot use their projectId. This is possible with Allowlists.
For web-based apps we can use the http origin, but for native apps we need to find an alternative approach. Developers will be able to define allowlist rules in the WalletConnect Cloud app under project settings.
The relay server needs to securely and reliably identify the origin app, such as "Trust Wallet", and allow/deny based on that.
Native allowlist
Find or send an appropriate allowlist value in relay requests. When this value is added to the allowlist, any API requests which originate from other apps will be rejected.
Some discussed ideas have mentioned user-agents or bundleid's, but these are easily spoofed. Another approach is app attestation.
Notes
This is related to, and may be covered in the domain binding solution.
The text was updated successfully, but these errors were encountered:
Problem
The projectId is publicly available and anyone can copy the projectid of dapp/wallet and (ab)use it. Both WalletConnect and users want to ensure that third parties cannot use their projectId. This is possible with Allowlists.
For web-based apps we can use the http origin, but for native apps we need to find an alternative approach. Developers will be able to define allowlist rules in the WalletConnect Cloud app under project settings.
The relay server needs to securely and reliably identify the origin app, such as "Trust Wallet", and allow/deny based on that.
Native allowlist
Find or send an appropriate allowlist value in relay requests. When this value is added to the allowlist, any API requests which originate from other apps will be rejected.
Some discussed ideas have mentioned user-agents or bundleid's, but these are easily spoofed. Another approach is app attestation.
Notes
This is related to, and may be covered in the domain binding solution.
The text was updated successfully, but these errors were encountered: