Add BlockExplorer-routes CAIP #200
Conversation
CAIPs/caip-X.md
Outdated
|
|
||
| ## Backwards Compatibility | ||
|
|
||
| This EIP was designed with existing API routes in mind to reduce disruption. Incompatible block explorers should include either 301 redirects to their existing API routes to match this EIP. |
There was a problem hiding this comment.
| This EIP was designed with existing API routes in mind to reduce disruption. Incompatible block explorers should include either 301 redirects to their existing API routes to match this EIP. | |
| Incompatible block explorers should include either 301 redirects to their existing API routes to match this EIP. |
Is there an "or XXX" missing here?
There was a problem hiding this comment.
yea - there is something missing actually - but same in the EIP - cc https://github.com/pedrouid
There was a problem hiding this comment.
but I think we can keep the sentence "This EIP was designed with existing API routes in mind to reduce disruption. " - just change EIP to CAIP
|
Forgive my ignorance here, but neither this CAIP nor the original EIP really explain how human-readable (i.e. web display) and machine-readable (API interactions properly speaking) interact here-- the motivation section of the EIP refers to both wallets linking end-users to block explorer website AND API routes. It seems that the dapp<>wallet [RPC-based and CAIP-25-discovered] interaction of switching chains is supported by this, but how does the wallet know that the it's being asked to switch to will support these conformant routes? I feel like wallets asked to switch to a previously un-registered chain would want to check a reputation registry/allowlist first, and this registry should also include up-to-date info about block explorer conformance/swappability, should this be spelled out maybe in a "Security Considerations" section? (If I've gotten it close enough, happy to straw man such a section myself haha) |
Co-authored-by: Bumblefudge <jcaballero@centre.io>
CAIPs/caip-X.md
Outdated
|
|
||
| ### Addresses | ||
|
|
||
| `<BLOCK_EXPORER_URL>/address/<ACCOUNT_ADDRESS>` |
There was a problem hiding this comment.
What's ACCOUNT_ADDRESS here? Would it make sense to rely on CAIP-10?
There was a problem hiding this comment.
would be nice - but then no explorer would be compatible and guess this CAIP would not get traction
But would really be nice for multi-chain explorers (are there any yet btw - did not yet stumble upon them)
CAIPs/caip-200.md
Outdated
| really meaningfully used; tokens and blocks have not been as effectively | ||
| harmonized, and divergent syntax for those routes caused some block explorers to | ||
| fail verifications. Also, the evolution of L2s has seen many drift away from the |
There was a problem hiding this comment.
| really meaningfully used; tokens and blocks have not been as effectively | |
| harmonized, and divergent syntax for those routes caused some block explorers to | |
| fail verifications. Also, the evolution of L2s has seen many drift away from the | |
| really meaningfully used. Also, the evolution of L2s has seen many drift away from the |
Co-authored-by: ligi <ligi@ligi.de>
|
Hey @ligi - pinging here for any additional review before getting this all wrapped up. |
|
I think this is good to merge |
see discussion here: #199