· Justin Traglia (EF, 보안): 합의를 깨는 변경이라 지금 넣으면 세폴리아가 깨지고 구현을 두 벌 관리해야 하는데, 공격은 자기 슬래싱이 필요해 실익이 적다며 헤고타에서 고치자고 했다.
· Barnabas Busa (EF DevOps): 버그를 보고하면서도 실제로 일어날 일이 거의 없다며 헤고타에서조차 고칠 필요가 있는지 의문이라고 했고, 글램스터담 포함에는 분명히 반대했다.
· Dustin Brody (Nimbus): 메인넷만 고치는 방안은 성립하지 않는다고 반박했다. 님버스는 네트워크별로 릴리스를 쪼개지 않고 단일 릴리스만 내기 때문이라는 근거다.
· Toni Wahrstätter (EF, 리서처): 공격자 입장에서 매우 비매력적인 공격이라 사실상 문제가 아니라고 봤고, 같은 조작이 RANDAO로도 가능하다는 점을 짚었다. (채팅)
· Pawan Dhananjay: 수정을 다음 포크로 미루는 데 동의한다고 밝혔다. (채팅)
"이건 실행하기 어렵고 이득은 거의 없으며, 하려면 스스로를 슬래싱까지 해야 한다." (Justin Traglia, 00:12:29)

· Jochem Brouwer (EF, EthereumJS · EIP-8037 공동 저자): 현 사양으로는 글램스터담 최악 블록 처리에 8초가 걸려 너무 느리다며 순차 읽기·쓰기를 최소 1000MB/s, 가급적 2000MB/s로 올리자고 했고, 소통의 명확성을 위해 포크마다 별도 사양 EIP를 두자고 제안했다.
· Maria Silva (EIP-8037 제1저자): 이번 포크의 병목 때문만이 아니라 현 수치 자체가 실제 노드가 쓰는 장비 대비 이상하게 낮아서 고치는 것이라고 논점을 보탰다.
· Ben Adams (Nethermind): Maria에 동조하며 스펙에 적힌 낮은 속도의 NVMe 드라이브는 해당 용량에서 애초에 존재한 적이 없다고 지적했다.
· Dustin Brody (Nimbus): 사양이 전반적으로 낮다는 서사에는 반박했다. RAM과 CPU 같은 다른 항목은 오히려 지나치게 높으며 님버스 사용자들은 16GB ARM 보드에서도 잘 돌린다는 근거를 들었다.
· Łukasz Rozmej (Nethermind, EIP-8037 공동 저자): 평소 블록은 낮은 장비로도 돌지만 권장 사양은 최악의 공격 블록을 감당해야 한다며 둘을 구분했고, 사양 EIP는 여러 개로 쪼개면 더 혼란스러우니 하나로 유지하며 포크별 이력을 담자고 jochem에 반대했다.
· Barnabas Busa (EF DevOps): EVM 작업에는 순차 처리량보다 랜덤 4K IOPS가 훨씬 중요하므로 그 수치에 집중해야 한다고 했다. (채팅)
"EIP에 요구사항으로 넣는 하드웨어는 최악의 블록을 처리할 수 있어야 하고, 그게 바로 차이점이다." (Łukasz Rozmej, 00:23:34)

· Justin Traglia (EF, 보안): 클라이언트들이 시간 내 구현을 못 하면 슬롯을 12초로 두어 퀵 슬롯을 사실상 선택 사항으로 하고, 3개 이상 클라이언트가 준비되면 그때 10초로 바꾸자고 제안했다.
· Barnabas Busa (EF DevOps): 선택 사항이라면 아예 한 주 일찍 띄우자고 했고, 2주를 미룰 거라면 그때는 참여자 모두가 10초 전환 능력을 갖춰야 한다고 봤다. 채팅에서는 10월 21일 12초안 또는 10월 28일 10초안을 선호한다고 밝혔다.
· Dustin Brody (Nimbus): 님버스는 이 기간 안에 퀵 슬롯을 구현하지 못할 것이며, 10초가 필수가 되면 님버스는 참여하지 않을 가능성이 크다고 했다.
· Jihoon: 테쿠도 12초 퀵 슬롯은 지원한다고 채팅에 밝혔다며 12초 유지안에 힘을 실었다.
· Matthew Keil (ChainSafe, Lodestar): 슬롯을 12초로 유지해야 한다고 했다. (채팅)
· Pawan Dhananjay: 라이트하우스는 28일까지 준비할 수 있다고 했다. (채팅)
"어느 쪽이든 괜찮지만, 후자라면 님버스는 참여하지 않을 가능성이 매우 크다." (Dustin Brody, 00:37:51)

· Spencer Taylor-Brown (EF, 테스팅): 데브넷 두 단계 앞까지 EIP를 미리 정하면 팀들이 앞서 일할 수 있고 번아웃도 줄일 수 있다며, 이번 포크가 아니라 다음 포크부터라도 프로세스를 바꿔보자고 제안했다.
· Dustin Brody (Nimbus): CFI의 목적은 EIP가 실제로 작동하는지 확인하는 것인데, 파이프라인식 계획은 아직 모르는 앞선 데브넷의 결과를 미리 가정하게 된다며 신중론을 폈다.
· Justin Florentine (Besu): 제안의 취지는 인정하면서도 FOCIL과 프레임처럼 상호작용이 용량에까지 영향을 줄 수 있으므로, CFI 전부를 구현해놓고 나중에 고르는 방식으로 가기 전에 이 순환 문제부터 풀어야 한다고 했다.
· Maria Silva (EIP-8037 제1저자): 셀프디스트럭트 비활성화를 일찍 넣으면 테스트에서 엣지 케이스가 줄어드는지 물었고, 그렇다는 답을 듣자 복잡하지 않은 EIP이니 조기 포함이 합리적이라고 했다.
· Jochem Brouwer (EF, EthereumJS · EIP-8037 공동 저자): 셀프디스트럭트를 비활성화하면 기존 패턴이 경제적으로 비싸지므로 EIP-8360(TCREATE)도 함께 우선해야 한다고 했다가, 테스트 관점에서는 별개 문제라는 Justin Florentine의 반박에 좋은 지적이라고 수긍했다.
· Carlos Pérez (CPerezz) (EF, EIP-8037 공동 저자): SETCODEFROM은 포스트퀀텀 마이그레이션의 사실상 유일한 경로이고 네서민드와 게스가 이미 구현해 테스트를 통과했으며 프레임과의 통합 검증에도 도움이 된다며 조기 포함을 주장했다.
"이런 식의 계획 파이프라인의 위험 하나는, 앞선 데브넷에서 아직 알지 못하는 결과를 미리 가정하기 시작한다는 것이다." (Dustin Brody, 00:43:31)

· Dima Gusakov (Lido): 포크 시점 대기 예치 큐에 빌더(0xB0) 예치가 검증자 예치보다 앞서 있으면 검증자 예치가 빌더의 톱업이 되어 검증자가 아예 생기지 않는 제3의 결과가 발생하고 기존 앱 계층 보호 장치가 이를 감당하지 못한다며 간단한 스펙 수정을 요청했다.
· Barnabas Busa (EF DevOps): 실제 문제라면 5~6개월 전에 제기했어야 했고 이미 세폴리아에 배포됐으며 후디도 일정이 잡혔다며 반대했다. 메인넷에만 적용될 수정을 라이브 프로덕션에 넣을 수는 없다고 했다.
· Pavel (MixBytes): 여러 프로토콜의 우회책을 감사해 봤는데 전부 지나치게 복잡하고 로직이 많아 모니터링과 다중 감사가 필요하다며 보안 관점에서는 베이스 계층 수정이 더 쉽다고 디마를 지지했다.
· Matthew Keil (ChainSafe, Lodestar): 결정을 미뤄도 마음이 바뀔 사람은 많지 않고 모든 팀이 이미 후디 릴리스를 잘랐다며 지금 경로를 바꾸기는 어렵다고 반대했다.
· Cambridge: 일부 클라이언트만 이 변경을 적용하면 체인이 분기되므로 합의 파괴적 변경이라고 지적했다. (채팅)
· Nico Flaig (ChainSafe, Lodestar): EIP-8282가 포크 이후에는 이 문제를 해결한다고 알렸다. (채팅)
"당신은 지금 메인넷에만 적용될 수정을 라이브 프로덕션에 넣어 달라고 요구하는 것인데, 그런 일은 일어나지 않을 것이다." (Barnabas Busa, 00:30:20)

· ignacio: EELS 팀 규칙상 메인 브랜치 업스트림에는 CFI가 필요하고 업스트림하면 1년째 이어 온 리베이스 부담과 PBT 등 다른 기능과의 조율 비용이 사라진다며 CFI를 요청했다. 16K 라인 PR 중 상태 전이 함수를 건드리는 것은 65줄뿐이라고 했다.
· lightclient (Matt Garnett) (EF, geth): 브랜치 관리가 어렵다는 것은 코어 EIP를 거버넌스에 통과시킬 이유가 못 된다며 이그나시오에 반박했다. 이더리움의 다른 대형 기능들도 수년간 같은 과정을 견뎠다고 했다.
· Iván Litteri (LambdaClass, ethrex 테크 리드): zkEVM 로드맵에 상당한 통합·테스트 작업이 필요해 클라이언트 팀들의 조기 약속이 있어야 한다며 CFI를 지지했다. 기능은 운영자에게 선택이지만 지원은 모든 클라이언트의 기본 기대치가 돼야 한다고 했다.
· Manu: CFI 여부가 프리즘의 작업량을 바꾸지는 않지만 몇몇 팀이 이 EIP에 진지하다는 신호가 되므로 CFI에 약하게 찬성한다고 했다. 라이트하우스가 이미 unstable 브랜치에 머지한 것도 암묵적 지지라고 봤다.
· Potuz (Offchain Labs, Prysm): 헤제(Heze) 메인 포크 브랜치 머지에 강하게 반대했다. 선택 기능이 더 이상 선택이 아니게 되고 이후 모든 포크의 모든 EIP 작성자가 이 변경과 호환돼야 하기 때문이라고 했다.
· Mario Vega (EF, 테스팅, ACDT 진행): EL 스펙에서도 똑같은 문제라며 포투즈에 동의했다. 메인 브랜치에 머지하면 나머지 EIP 전부가 그것에 맞춰야 하므로 개발자들이 찬성하지 않는 한 사실상의 고착을 원치 않는다고 했다.
"나는 이것을 메인 포크 브랜치에 머지하는 데 반대한다. 그 순간 선택 기능이 아니게 되고 우리가 하는 모든 포크와 모든 작업에 영향을 주기 때문이다." (Potuz, 01:13:24)

· Oisin Kyne: 지난 5년 중 최악의 클라이언트 중앙화 상태로 3개 클라이언트 각각이 단독 장애만으로 라이브니스 문제를 일으킬 수 있다며 비활성 페널티를 최대 256배까지 가중해 분산을 유도하자고 했다.
· Matthew Keil (ChainSafe, Lodestar): 제안 자체는 마음에 들지만 포크에 포함된 EIP 수가 걱정이라며 당장 확정하기보다 남겨 뒀다가 시간이 나면 막판에 넣자고 했다.
· Łukasz Rozmej (Nethermind, EIP-8037 공동 저자): 큰 장애가 오기 전까지는 아무도 이 페널티를 체감하지 못해 행동이 바뀌지 않을 수 있다고 우려했다.
· Ben Adams (Nethermind): 이미 DFI된 발행량 변경을 만약 하게 된다면 이 페널티와 MEV 번 같은 것들을 함께 묶어 가져와야 한다고 했다.
· stokes: CFI의 기준은 강한 지지여야 하며 무관심은 CFI 사유가 아니라고 했다. 강한 지지가 들리지 않아 DFI로 정리했다.
"CFI에는 강한 지지가 필요하다고 본다. 사실상의 무관심은 CFI가 되어서는 안 된다." (stokes, 01:36:10)

· Dima Gusakov (Lido): 이더리움 스테이크의 대다수가 위임 스테이킹이고 비컨체인 출범 때부터 있던 문제라며 공개키와 출금 자격증명을 묶는 약속을 7002류 시스템 컨트랙트로 제출하고 4788로 증명하는 단순한 해법을 헤고타에 넣자고 했다. 스펙과 테스트, 컨트랙트 코드가 준비됐고 감사 비용은 리도가 대겠다고 했다.
· meditationduck: ACK3는 위임 스테이킹 예치를 강화하므로 지지한다고 했다. 모든 위임 스테이킹 프로토콜이 이 EIP를 채택해야 한다는 점이 유일한 우려라고 했다.
· Tomer Ganor: 0x02 전환은 문제를 풀지 못한다며 디마를 지지했다. 자금이 인출되고 다시 예치되면 결국 새 검증자를 배포해야 하므로 보안 관점에서 이 EIP가 많은 가정과 우회책을 단순화한다고 했다.
· Matthew Keil (ChainSafe, Lodestar): 앱 계층 해법이 이미 존재하고 특정 이해관계자 집단을 위해 코어 프로토콜을 바꾸는 선례가 걱정된다며 반대했다. 다음 포크에서 PQ 키를 다루게 되니 PQ 예치 컨트랙트 재설계에서 한 번에 푸는 편이 낫다고 했다.
· Greg K (Lido): 7분 발표로는 논의가 부족했고 지금 분위기가 DFI로 들리지도 않는다며 최종 결정을 다음 콜로 미루자고 요청했고 그대로 받아들여졌다.
"요점은 합의 계층이 곧 스테이킹이라는 것이고, 이더리움 스테이크의 대다수는 위임 방식으로 스테이킹돼 있다는 것이다." (Dima Gusakov, 01:52:59)