Cutting slot time from 12s to 10s changes no API, which is exactly what makes it dangerous. Every poll interval, confirmation rule, oracle heartbeat and deadline in an application encodes 12 seconds somewhere, and almost none of them say so.
Not yet scoped — and the first step is a grep, not a design. Pull every time-valued constant out of the codebase (poll intervals, confirmation counts, signature deadlines, cache TTLs, cron periods) and mark each one: derived from slot time, coincidentally equal to a multiple of it, or genuinely independent. Only the middle bucket is a bug. Source: EIP-8198 Quick Slots, listed S-tier in the 2026-08-26 protocol roundup — confirm the proposal's actual status and target fork at eips.ethereum.org before building anything on it.
Why
A timing change is the worst kind of change, because it does not break a build — it shifts a distribution. Nothing fails to compile, no test goes red on the day the fork lands, and the symptoms arrive later as flakiness: an update that occasionally arrives a beat late, a quote that occasionally misses its window, a confirmation rule that quietly guarantees less than it did last week.
The part that actually tightens is anything with a deadline signed into it. A filler quoting against a fill deadline, an oracle heartbeat, a batch-auction window, a bundle aimed at the next slot — each loses about a sixth of its wall-clock budget while the code keeps the same number in it. That is the same seam erc-7683-settlement-security runs along and the same one the-settlement-instant depends on: a deadline is only meaningful in the unit of the thing it protects, and nobody checks which unit was used until it moves.
Why the card is cheap and keeps its value either way. The output is an inventory of places where the application makes an unstated assumption about time. If EIP-8198 never ships, the inventory is still the list of latent assumptions — and this is a codebase that will eventually run against more than one chain, where slot time is not 12 seconds and never was.
How it works
Where twelve seconds hides
Constant
What a 10-second slot does to it
Failure shape
Poll interval set to one block
Each poll now spans 1.2 blocks
Occasional missed update, read as flaky UI rather than a bug
N-confirmation rule
Same N, about 17% less wall clock
Weaker guarantee at byte-identical code
Deadline in seconds
Same seconds, more blocks inside them
Nothing breaks — this is the safe bucket
Deadline in blocks
About 17% less time to act
Fillers and oracles miss near the edge of the window
Oracle heartbeat / staleness bound
Threshold now spans more blocks
Stale price accepted longer than intended
Cron or batch window sized in blocks
Window shrinks in wall clock
Jobs overlap under load
The rule the table produces
Express every deadline in the unit of the thing it protects. A human or market deadline is wall-clock: a user has thirty seconds, a quote is good for two minutes. A chain-state deadline is blocks: this many confirmations, this many slots of challenge window. The defect is never the number — it is a deadline written in the other unit, and slot time changing does not create that defect, it only makes it visible.
Why it sits next to the other protocol cards
The roundup's three S-tier items change three different parts of the substrate under an application that does not change at all: 8198 changes time, 8131 and 8279 change what resources cost (l1-data-pricing-dimensions), and 8141 changes the shape of a transaction (erc-8141). None of them require an application to be rewritten, and all three change what it is quietly assuming.
슬롯 시간이 12초에서 10초로 줄어도 API는 하나도 바뀌지 않습니다 — 바로 그 점이 위험합니다. 앱의 폴링 주기·확정 규칙·오라클 하트비트·마감은 어딘가에서 12초를 전제하고 있는데, 그렇다고 적어 둔 자리는 거의 없습니다.
아직 범위 미정 — 첫 단계는 설계가 아니라 grep 입니다. 코드베이스에서 시간 값을 가진 상수를 전부 뽑아(폴링 주기, 확정 블록 수, 서명 마감, 캐시 TTL, 크론 주기) 각각을 표시합니다 — 슬롯 시간에서 유도된 것, 우연히 그 배수와 같은 것, 정말로 무관한 것. 버그는 가운데 칸뿐입니다. 출처: 2026-08-26 프로토콜 라운드업의 S티어 항목 EIP-8198 Quick Slots — 실제 상태와 목표 포크는 eips.ethereum.org 에서 먼저 확인할 것.
왜
타이밍 변경은 가장 나쁜 종류의 변경입니다. 빌드를 깨지 않고 분포를 옮기기 때문입니다. 컴파일이 실패하지 않고, 포크가 들어온 날 빨간 테스트도 없습니다. 증상은 나중에 불안정성으로 옵니다 — 가끔 한 박자 늦게 도착하는 갱신, 가끔 창을 놓치는 호가, 지난주보다 조용히 덜 보장하게 된 확정 규칙.
실제로 조여드는 것은 마감이 서명에 박혀 있는 모든 것입니다. 체결 마감을 걸고 호가를 내는 필러, 오라클 하트비트, 배치 경매 창, 다음 슬롯을 겨냥한 번들 — 코드에 적힌 숫자는 그대로인데 실제 벽시계 예산이 6분의 1쯤 줄어듭니다. erc-7683-settlement-security 가 훑고 지나가는 이음매이자 the-settlement-instant 가 기대고 있는 그 이음매입니다: 마감은 자기가 보호하는 대상의 단위로 적혀야 의미가 있고, 어떤 단위로 적혔는지는 그 단위가 움직이기 전까지 아무도 확인하지 않습니다.
왜 싸고, 어느 쪽으로 가든 값이 남는가. 산출물은 앱이 시간에 대해 말하지 않은 채 전제하고 있는 자리들의 목록입니다. EIP-8198 이 끝내 들어오지 않아도 그 목록은 그대로 잠재 전제 목록이고 — 이 코드베이스는 언젠가 슬롯 시간이 12초가 아닌, 애초에 12초였던 적도 없는 체인 위에서도 돌 것이기 때문입니다.
동작 방식
12초가 숨어 있는 자리
상수
10초 슬롯이 하는 일
고장 나는 모양
한 블록에 맞춘 폴링 주기
한 번 폴링이 1.2블록을 걸침
가끔 갱신을 놓침 — 버그가 아니라 UI 불안정으로 읽힘
N확정 규칙
N은 그대로, 벽시계로는 약 17% 감소
코드는 바이트 단위로 같은데 보장은 약해짐
초 단위 마감
초는 그대로, 그 안의 블록만 늘어남
아무것도 안 깨짐 — 안전한 칸
블록 단위 마감
행동할 시간이 약 17% 감소
필러·오라클이 창 가장자리에서 놓침
오라클 하트비트 · 신선도 한계
같은 임계값이 더 많은 블록을 덮음
의도보다 오래 낡은 가격을 받아들임
블록 수로 잡은 크론·배치 창
벽시계 기준 창이 줄어듦
부하 시 작업이 겹침
표가 만들어내는 규칙
모든 마감은 자기가 보호하는 대상의 단위로 적는다. 사람이나 시장의 마감은 벽시계입니다 — 사용자에게 30초, 호가는 2분간 유효. 체인 상태의 마감은 블록입니다 — 확정 몇 개, 챌린지 창 몇 슬롯. 결함은 숫자가 아니라 다른 단위로 적힌 마감이고, 슬롯 시간 변경은 그 결함을 만드는 게 아니라 보이게 할 뿐입니다.
왜 다른 프로토콜 카드 옆에 두는가
라운드업의 S티어 세 항목은 전혀 바뀌지 않은 애플리케이션 아래에서 기반의 서로 다른 세 부분을 바꿉니다.8198은 시간을, 8131·8279는 자원의 가격을(l1-data-pricing-dimensions), 8141은 트랜잭션의 모양을(erc-8141) 바꿉니다. 셋 다 앱을 다시 쓰라고 요구하지 않고, 셋 다 앱이 조용히 전제하던 것을 바꿉니다.