forked from DecentralizedClimateFoundation/DCIPs
71 lines
2.7 KiB
Markdown
71 lines
2.7 KiB
Markdown
|
---
|
|||
|
|
eip: 2786
|
|||
|
|
title: Ethereum Provider Connect/Disconnect Events
|
|||
|
|
author: Micah Zoltu (@MicahZoltu), Erik Marks (@rekmarks)
|
|||
|
|
discussions-to: https://github.com/ethereum/EIPs/issues/2787
|
|||
|
|
status: Withdrawn
|
|||
|
|
type: Standards Track
|
|||
|
|
category: Interface
|
|||
|
|
created: 2020-07-15
|
|||
|
|
requires: 2700
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Simple Summary
|
|||
|
|
|
|||
|
|
When an Ethereum Provider becomes connected or disconnected, it will emit a `connect`/`disconnect` event.
|
|||
|
|
|
|||
|
|
## Abstract
|
|||
|
|
|
|||
|
|
The Provider is said to be “connected” when it can service RPC requests to at least one chain.
|
|||
|
|
The Provider is said to be “disconnected” when it cannot service RPC requests to any chain at all.
|
|||
|
|
When the Provider switches from a "connected" state to a "disconnected" state, it will emit a `connect` event.
|
|||
|
|
When the Provider switches from a "disconnected" state to a "connected" state, it will emit a `disconnect` event.
|
|||
|
|
|
|||
|
|
## Motivation
|
|||
|
|
|
|||
|
|
When an application is hooked up to an Ethereum provider, there is value in having the application be alerted of connect/disconnect events that may occur so the application can appropriately inform the user of the situation.
|
|||
|
|
It is left up to the application to decide whether to listen in on these events, and how to handle them.
|
|||
|
|
|
|||
|
|
## Specification
|
|||
|
|
|
|||
|
|
### Definitions
|
|||
|
|
|
|||
|
|
#### Connected
|
|||
|
|
|
|||
|
|
The Provider is considered `connected` when it is able to service RPC requests to at least one chain.
|
|||
|
|
|
|||
|
|
#### Disconnected
|
|||
|
|
|
|||
|
|
The Provider is considered `disconnected` when it is unable to service RPC requests to any chain.
|
|||
|
|
|
|||
|
|
### Events
|
|||
|
|
|
|||
|
|
#### `connect`
|
|||
|
|
|
|||
|
|
The Provider **MUST** emit a `connect` event to all attached [EIP-2700](./eip-2700.md) listeners if it transitions from a `disconnected` state to a `connected` state.
|
|||
|
|
All attached listeners **MUST** be called with the parameter `{ chainId }`.
|
|||
|
|
`chainId` **MUST** specify the integer ID of the connected chain encoded as a hexadecimal string.
|
|||
|
|
If the Provider supports the `eth_chainId` JSON-RPC method or a derivation of it, then the `chainId` **MUST** match the return value of `eth_chainId`.
|
|||
|
|
The Provider **MAY** call the attached listeners in any order.
|
|||
|
|
|
|||
|
|
## Rationale
|
|||
|
|
|
|||
|
|
This EIP is mostly a retrospective EIP meaning it codifies an already existing specification so there isn’t a lot of room for improving things such as by having a connect/disconnect event per chain.
|
|||
|
|
|
|||
|
|
## Security Considerations
|
|||
|
|
|
|||
|
|
The relationship between Ethereum Provider and client is a trusted one, where it is assumed that the user implicitly trusts the Ethereum Provider which is how it managed to get injected into the client, or the client expressly pulled in a connection to it.
|
|||
|
|
|
|||
|
|
## Copyright
|
|||
|
|
|
|||
|
|
Copyright and related rights waived via [CC0](../LICENSE.md).
|
|||
|
|
|
|||
|
|
## Appendix I: Examples
|
|||
|
|
|
|||
|
|
```javascript
|
|||
|
|
// connect
|
|||
|
|
provider.on('connect', ({ chainId }) => {
|
|||
|
|
console.log(`Provider connected to: ${chainId}`);
|
|||
|
|
});
|
|||
|
|
```
|