Summary
From CONTRACT.md's "Known gaps": update_resolvers is currently a single-admin-key operation, a bigger centralization point than the resolver committee itself. A resolver self-rotation scheme (the committee votes to replace one of its own, rather than the admin unilaterally deciding) was considered during the original design but not built for v1.
Scope
Design task first, implementation second. Propose how a self-rotation vote would work: what majority is required, how it interacts with the existing per-dispute committee snapshot (Assertion.resolvers), and whether it fully replaces update_resolvers or coexists with it as an alternative path.
Proposed approach
See ARCHITECTURE.md's "Resolver committee is snapshotted per dispute" section for the existing snapshot mechanics this design needs to stay consistent with.
Summary
From CONTRACT.md's "Known gaps":
update_resolversis currently a single-admin-key operation, a bigger centralization point than the resolver committee itself. A resolver self-rotation scheme (the committee votes to replace one of its own, rather than the admin unilaterally deciding) was considered during the original design but not built for v1.Scope
Design task first, implementation second. Propose how a self-rotation vote would work: what majority is required, how it interacts with the existing per-dispute committee snapshot (
Assertion.resolvers), and whether it fully replacesupdate_resolversor coexists with it as an alternative path.Proposed approach
See ARCHITECTURE.md's "Resolver committee is snapshotted per dispute" section for the existing snapshot mechanics this design needs to stay consistent with.