Private _activeThe currently active account. For all requests that are associated to a specific request (operation request, signing request), the active account is used to determine the network and destination wallet
Private _activeThe currently active peer. This is used to address a peer in case the active account is not set. (Eg. for permission requests)
Protected _beaconThe beaconId is a public key that is used to identify one specific application (dapp or wallet). This is used inside a message to specify the sender, for example.
Private _initProtected _keyThe local keypair that is used for the communication encryption
Protected _transportProtected Readonly accountPrivate Readonly activeProtected analyticsPrivate Readonly appOptional Readonly appThe URL of the dApp.
Readonly blockThe block explorer used by the SDK
Private blockchainsPrivate Readonly bugPrivate debouncePrivate debounceOptional Readonly descriptionThe description of the app
Private Optional Readonly disclaimerPrivate enableAutomatically switch between apps on Mobile Devices (Enabled by Default)
Private Optional enableEnable metrics tracking (Disabled by Default)
Private Readonly errorProtected Readonly eventsPrivate Readonly featuredProtected handleOptional Readonly iconThe URL of the dApp Icon. This can be used to display the icon of the dApp on in the wallet
Private isPrivate isProtected Readonly matrixReadonly nameThe name of the client
Private Readonly openA map of requests that are currently "open", meaning we have sent them to a wallet and are still awaiting a response.
Protected p2pProtected postProtected Readonly rateHow many requests can be sent after another
Protected Readonly rateThe time window in seconds in which the "rateLimit" is checked
Protected requestStores the times when requests have been made to determine if the rate limit has been reached
Protected storagePrivate Readonly storagePrivate Optional userProtected walletProtected Optional wcProtected Optional wcReturns the connection status of the Client
Protected keyReturns whether or not the transaport is ready
Protected transportProtected addPrivate addAdds a requests to the "openRequests" set so we know what messages have already been answered/handled.
The ID of the message
A promise that resolves once the response for that specific message is received
Add a new peer to the known peers
The new peer to add
Private addPrivate buildPrivate channelCheck if we have permissions to send the specific message type to the active account. If no active account is set, only permission requests are allowed.
The type of the message
Protected cleanupPrivate createReturn the account by ID
The ID of an account
Return all locally known accounts
Returns the active account
Use getOwnAppMetadata instead
Returns the metadata of this DApp
Private getOptional account: AccountInfoPrivate getOptional peer: PeerInfoOptional account: AccountInfoPrivate getPrivate handleThis message handles errors that we receive from the wallet.
The request we sent
The error we received
This method initializes the client. It will check if the connection should be established to a browser extension or if the P2P transport should be used.
Optional transport: Transport<any, any, any>A transport that can be provided by the user
Private initPrivate initPrivate isPrivate makeThis method handles sending of requests to the DApp. It makes sure that the DAppClient is initialized and connected to the transport. After that rate limits and permissions will be checked, an ID is attached and the request is sent to the DApp over the transport.
The BeaconMessage to be sent to the wallet
Optional skipResponse: falseIf true, the function return as soon as the message is sent
Private makeThis method handles sending of requests to the DApp. It makes sure that the DAppClient is initialized and connected to the transport. After that rate limits and permissions will be checked, an ID is attached and the request is sent to the DApp over the transport.
The BeaconMessage to be sent to the wallet
Private notifyThis message will send an event when we receive a successful response to one of the requests we sent.
The request we sent
The response we received
Private onPrivate removePrivate removeThis method will remove all accounts associated with a specific peer.
An array of peers for which accounts should be removed
Removes a peer and all the accounts that have been connected through that peer
Peer to be removed
Sends a "BroadcastRequest" to the wallet. This method can be used to inject an already signed transaction to the network.
The message details we need to prepare the BroadcastRequest message.
This method sends an OperationRequest to the wallet. This method should be used for all kinds of operations, eg. transaction or delegation. Not all properties have to be provided. Data like "counter" and fees will be fetched and calculated by the wallet (but they can still be provided if required).
The message details we need to prepare the OperationRequest message.
Send a permission request to the DApp. This should be done as the first step. The wallet will respond with an publicKey and permissions that were given. The account returned will be set as the "activeAccount" and will be used for the following requests.
Optional input: RequestPermissionInputThe message details we need to prepare the PermissionRequest message.
Send a proof of event request to the wallet. The wallet will either accept or decline the challenge. If it is accepted, the challenge will be stored, meaning that even if the user refresh the page, the DAppClient will keep checking if the challenge has been fulfilled. Once the challenge is stored, a challenge stored message will be sent to the wallet. It's highly recommended to run a proof of event challenge to check the identity of an abstracted account
The message details we need to prepare the ProofOfEventChallenge message.
This method will send a "SignPayloadRequest" to the wallet. This method is meant to be used to sign arbitrary data (eg. a string). It will return the signature in the format of "edsig..."
The message details we need to prepare the SignPayloadRequest message.
Send a simulated proof of event request to the wallet. The wallet will either accept or decline the challenge.
It's the same than requestProofOfEventChallenge but rather than executing operations on the blockchain to prove the identity,
The wallet will return a list of operations that you'll be able to run on your side to verify the identity of the abstracted account
It's highly recommended to run a proof of event challenge to check the identity of an abstracted account
The message details we need to prepare the SimulatedProofOfEventChallenge message.
Private resetProtected sendPrivate sendPrivate sendOptional options: RequestInitOptional thenHandler: ((res) => void)Optional catchHandler: ((err) => void)Private sendSets the active account
Optional account: AccountInfoThe account that will be set as the active account
Protected setOptional peer: PeerInfoTypeProtected setA "setter" for when the transport needs to be changed.
Optional transport: Transport<any, any, any>Allows the user to subscribe to specific events that are fired in the SDK
The event to subscribe to
The callback that will be called when the event occurs
Private tryPrivate updatePrivate wcGenerated using TypeDoc
Publicapi
The DAppClient has to be used in decentralized applications. It handles all the logic related to connecting to beacon-compatible wallets and sending requests.