9e393a79d9
* Include LICENCE in the Jekyll build * Replace old licence link with new and improved licence link * Add note to EIP-1 mandating the new link * Maybe this fixes it? * Rename LICENCE so that jekyll picks it up * Add original LICENCE file back * Delete the markdown file * Add Jekyll header Hopefully the tooling still detects it as CC0 * Remove Jekyll header * Maybe this will trick Jekyll and satisfy github? * Remove config changes * Enable incremental build * Will it work if I rename it? * I'll just paste the content of the licence into the file... * Perhaps this will work * Replace the licence file * Fix false positive Co-authored-by: Micah Zoltu <micah@zoltu.net> * Resolve feedback * Perhaps this might work * It didn't work This reverts commit 55116e15168fb20ae57dea97388bb260c0941465. * Will licencee still detect this correctly? * Jekyll Preamble in licence file * Include it? * Licence -> License, get rid of CC0.md * Force wording of copyright waiver * Formatting consistent with the rest of the list * Spelling * Escape * Task failed successfully * Fix two more links * Will this render it? * Perhaps this will work too * .md essential * Fix the issues Micah noted Co-authored-by: Micah Zoltu <micah@zoltu.net>
2.7 KiB
| eip | title | author | discussions-to | status | type | category | created | requires |
|---|---|---|---|---|---|---|---|---|
| 2786 | Ethereum Provider Connect/Disconnect Events | Micah Zoltu (@MicahZoltu), Erik Marks (@rekmarks) | https://github.com/ethereum/EIPs/issues/2787 | Withdrawn | Standards Track | Interface | 2020-07-15 | 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 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.
Appendix I: Examples
// connect
provider.on('connect', ({ chainId }) => {
console.log(`Provider connected to: ${chainId}`);
});