Question: Gateway workflow design vs contract access control (E2E finding)

[gilbertsahumada]

Background

The gateway has 236 unit/integration tests, but they all mock contract interactions. This means any mismatch between what the gateway expects and what the contracts actually do goes undetected until a real deployment.

To close this gap, I'm building an E2E test suite that deploys the full ChaosChain contract stack on an Anvil local testnet and runs gateway workflows against it. The approach is to dockerize both the gateway and the blockchain (Anvil), so tests exercise the real contract calls end-to-end without mocks. Running against real contracts exposed one design question and two gateway-side bugs.

Related: #25 (ABI alignment fix — first finding from this effort)

Before proposing fixes, I need to clarify the gateway's intended role.

---

Core question: Who runs the gateway?

The RegisterWorkStep and RegisterValidatorStep in the gateway call registerWork() and registerValidator() on RewardsDistributor. These functions are onlyOwner by design.

This means the gateway's signer must be the RewardsDistributor owner for these steps to succeed. Today the workflow uses input.signer_address (the worker/validator) for these calls, which will always revert unless that address happens to be the owner.

Two possible interpretations:

1. The gateway is always operated by ChaosChain (the owner) — the workflow should use the gateway's own signer (which is the owner) for registerWork/registerValidator calls, not the worker/validator signer.
2. The gateway is meant to be run by anyone — the contract access control would need to change to allow this, but that's a contract design decision, not a gateway bug.

Which is the intended model? The answer determines how to fix the workflow.

---

Additional finding (gateway-side bug)

This is an issue in the gateway's own logic, independent of the question above.

1. RegisterValidatorStep precondition blocks direct mode

Where: src/workflows/score-submission.ts#L955

The step checks if (!progress.reveal_confirmed) before proceeding. In commit-reveal mode this works — AwaitRevealConfirmStep sets reveal_confirmed = true. But in direct mode, AwaitScoreConfirmStep sets score_confirmed = true instead. Since reveal_confirmed is never set, the precondition always fails and the workflow ends in FAILED.

Suggested fix: if (!progress.reveal_confirmed && !progress.score_confirmed)

2. Reconciliation ADVANCE_TO_STEP skips progress state

Where: src/workflows/reconciliation.ts#L227 and #L653

When reconciliation detects work already exists on-chain and advances from SUBMIT_WORK_ONCHAIN to REGISTER_WORK, it updates the step but doesn't set progress.onchain_confirmed = true. Any downstream logic that checks onchain_confirmed won't see it, even though the work is confirmed on-chain.

---

How this was found

Local E2E testing with:

• Anvil local testnet (port 8546, --block-time 1)
• Full contract deployment via Foundry script: MockIdentityRegistry → ChaosChainRegistry → RewardsDistributor → StudioProxyFactory → ChaosCore → PredictionMarketLogic
• Gateway with EthersChainAdapter, InMemoryWorkflowPersistence, MockArweaveAdapter

Result

Test suite	Result
Unit/integration (236 tests)	All pass
E2E (4 tests)	1 pass, 3 STALLED

The E2E infrastructure (Docker Compose with Anvil + gateway + PostgreSQL) will be added in a follow-up PR.

[gilbertsahumada]

Resolution

Regardless of who operates the gateway, the ownership question for registerWork/registerValidator has been resolved with an admin signer approach:

• The gateway accepts an ADMIN_SIGNER_ADDRESS config (env var) that specifies the RewardsDistributor owner
• RegisterWorkStep and RegisterValidatorStep use the admin signer for these onlyOwner calls, while submitWork/submitScoreVectorForWorker continue using the agent's own signer
• This is architecturally safe: the to address is hardcoded to RewardsDistributor, function selectors are hardcoded in encoders, and user input only controls parameters (studio, epoch, dataHash, validator) — all validated by the contract

PR: #28 (draft — E2E infrastructure + admin signer)

Files changed

File	Change
packages/gateway/src/app.ts	adminSignerAddress config, passed to workflow factories
packages/gateway/src/workflows/work-submission.ts	Admin signer for RegisterWorkStep + AwaitRegisterConfirmStep
packages/gateway/src/workflows/score-submission.ts	Admin signer for RegisterValidatorStep + AwaitRegisterValidatorConfirmStep; precondition bug fixed
e2e/setup.ts	Writes DEPLOYER address to addresses.json
e2e/gateway-entrypoint.sh	Exports ADMIN_SIGNER_ADDRESS from deployer

E2E results after fix

Test	Result
WorkSubmission → COMPLETED (6 steps incl. registerWork)	PASS
ScoreSubmission direct → COMPLETED (4 steps incl. registerValidator)	PASS
All 8 gateway E2E tests	PASS
All 284 unit tests	PASS

---

Bug status

1. RegisterValidatorStep precondition blocks direct mode — FIXED

The step checked if (!progress.reveal_confirmed) which is only set in commit-reveal mode. In direct mode, AwaitScoreConfirmStep sets score_confirmed instead, so the precondition always failed.

Fix: score-submission.ts#L958 — now checks if (!progress.reveal_confirmed && !progress.score_confirmed).

2. Reconciliation ADVANCE_TO_STEP skips progress state — STILL OPEN

When reconciliation detects work already on-chain and advances from SUBMIT_WORK_ONCHAIN to REGISTER_WORK, it updates the step but does not call appendProgress to set onchain_confirmed = true.

Where: reconciliation.ts#L653-L662 — ADVANCE_TO_STEP only updates step and step_attempts, no progress fields.

Impact: Only affects crash-recovery scenarios (gateway restarts while a tx is in-flight). The current E2E tests don't cover this because they test the happy path without gateway restarts. A downstream step that checks onchain_confirmed would fail even though the work is confirmed on-chain.

---

Open question: contract-level change

The admin signer approach works for MVP but introduces a centralization point — all registerWork/registerValidator txs go through one signer. A possible follow-up is to modify RewardsDistributor to allow permissionless registration with on-chain proof (e.g. verify that work/score exists in StudioProxy before accepting registration). This would:

• Remove the single-signer bottleneck
• Eliminate lock contention under high concurrency
• Allow anyone to operate a gateway without needing owner keys

Is this the intended long-term direction, or is onlyOwner the deliberate design for these functions?