ERC-7618 创建于 2024 年 2 月 8 日，仓库记录状态为 Draft，同样扩展 ERC-6944 解析模式。它规定 request() 若返回 Content-Encoding 头，且该算法不在客户端 Accept-Encoding 支持列表内，协议必须先解压再转发；gzip 与 brotli 是必须支持的两种编码，解码时不得把该头透传给客户端。本文解释为什么不照搬 HTTP 协商、编码不认识时为何直接报错。

ERC-7617 创建于 2024 年 2 月 8 日，仓库记录状态为 Draft，扩展 ERC-6944 定义的 ERC-5219 解析模式。它给 request() 返回的头部引入可选的 web3-next-chunk，值为指向下一块数据的 web3:// URL，协议流式逐块取到没有该头为止，以此在服务端 Gas 限额之下送出任意大小的内容。本文拆解取块循环、URL 合法性与目标合约模式的校验，以及规范自述未发现安全考量的含义。

ERC-7087 创建于 2023 年 5 月 28 日，仓库记录状态为 Draft。它扩展 ERC-6860 的 web3:// 协议：对没有主动适配协议的合约（自动模式），返回数据的 MIME 类型原本要么隐式要么藏在 data URL 里，本标准要求用 mime.content、mime.type、mime.dataurl 三个查询参数补齐 Content-Type。本文拆解三个参数的取值规则、覆盖优先级和规范自己写明的跨站脚本风险。

同一个合约接入浏览器，走哪套解析规则？ERC-6944 的答案只有一行：resolveMode 返回字符串 5219 的哈希填充值。这份创建于 2023 年 4 月 27 日、状态为 Draft 的标准给 ERC-4804 增加一种解析模式，把网页交给 ERC-5219 的 request 接口生成。它连 ERC-165 都省了——互通性直接调 resolveMode 验证。本文拆解这份迷你标准的分工逻辑。