proposal(evm): trust-model hardening for signer controls and finTransfer domain binding

[omarespejel]

Proposal: EVM trust-model hardening (alignment first, then implementation)

This is a proposal issue to align on design before opening code PRs.

Current behavior is functional; this is a hardening pass to improve operational safety and replay resistance over time, with backward-compatible migration.

Scope

In scope:

• signer/governance controls around privileged EVM operations
• stronger signature domain binding for finTransfer

Out of scope (intentional design choices already documented):

• changing deployToken chain-agnostic metadata signatures
• fee-on-transfer token support policy

Targeted areas

• evm/src/omni-bridge/contracts/OmniBridge.sol
  • setNearBridgeDerivedAddress(...)
  • _authorizeUpgrade(...)
  • finTransfer(...) signature hash domain

Proposed approach

1) Domain binding hardening for finTransfer

Add a v2 domain for signed transfer messages that includes native execution context:

• block.chainid
• address(this)

Migration-safe rollout:

• temporary dual-verify support (legacy + v2)
• explicit switch to disable legacy path once signers/relayer are migrated
• no breaking cutover in a single release

2) Privileged control hardening

Strengthen privileged operations with clearer separation and auditability:

• split privileges for signer updates vs upgrade authorization (role separation)
• optional two-step signer update flow (propose/apply) with delay window
• explicit eventing on propose/apply and role-sensitive config changes

Delivery plan (after alignment)

• PR A: finTransfer domain-binding v2 + dual-verify migration + replay tests
• PR B: role separation (and optional delayed two-step signer update) + auth tests

Test expectations

• unit tests for hash/domain generation
• integration tests proving replay rejection across:
  • same payload, different contract address
  • same payload, different chain id
• authorization tests for each privileged pathway
• migration tests for legacy acceptance toggle

Maintainer decisions requested

1. For signer updates, prefer:

• role separation only, or
• role separation + delayed two-step apply?

2. For migration, prefer:

• dual-verify with explicit legacy-disable switch, or
• strict cutover at deployment boundary?

3. Any additional constraints for relayer/signer rollout sequencing?

If this direction looks good, I can open PR A first with minimal, isolated scope.

[omarespejel]

Clarification to avoid scope confusion:

• This proposal is not about adding emergency rescue admin methods like evm: add controlled ETH recovery path for accidental transfers #548/feat(evm): add admin-controlled ETH rescue function #549.
• It is focused on signer/governance model alignment and signature domain hardening, with migration-safe rollout.
• If maintainers prefer current pause+upgrade model for some controls, proposal can be narrowed to domain-binding + observability only.