oldBalance + newBalance is the right call for AHM - delta computable directly from the log is exactly what stateless scoring needs. Looking forward to the redeploy. Will update our OnChainWatcher to subscribe to EvaluatorStakeUpdated once it lands.
Checked the events on-chain for Job #16 - JobCreated at block 40137201 shows evaluator as 0x000...0000, so EvaluatorAssigned hasn’t fired yet. Daemon is running and will pick it up automatically once assignment lands. @Bakugo32 - does this need a manual trigger on your side?
Quick clarification on the EvaluatorAssigned detection issue.
The event is emitted but from EvaluatorRegistry, not AgentJobManager. In the current deployment, fund() calls evaluatorRegistry.assignEvaluator() internally, and the event originates from that contract on job #16.
This is a genuine DX gap. Watching AgentJobManager for assignment events is the natural assumption, and it’s wrong in the current deployment. We’re fixing this in the next release : EvaluatorAssigned will be emitted from AgentJobManager.fund() directly, removed from EvaluatorRegistry.assignEvaluator() so daemons only need to watch one contract.
For what it’s worth job #16 completed the full flow : your daemon evaluated and rejected the deliverable. The auto-assign mechanism itself is working correctly end-to-end.
Good to know.. makes sense that fund() triggers the assignment internally via EvaluatorRegistry. Glad the full flow completed on Job #16. Will hold off patching the daemon to watch EvaluatorRegistry since the mirror fix is coming - let us know when that’s deployed.
1 Like
Confirmed on Option 1. We’re implementing EvaluatorStakeUpdated(address indexed evaluator, uint256 oldBalance, uint256 newBalance), emitted in slash() and on every stake deposit/withdrawal. remainingStake will be dropped from EvaluatorSlashed, reverting to the 4-field signature originally agreed.
One additional change is going into the same deployment, flagged by pablocactus : EvaluatorAssigned will be emitted from AgentJobManager.fund() only, removed from EvaluatorRegistry.assignEvaluator() so daemon integrators only need to watch one contract instead of two.
Since evaluatorRegistry is immutable in AgentJobManager, both contracts redeploy together. New addresses will be posted here before we ask evaluators to restake. A 2-day governance delay applies post-deployment before the contracts are fully wired. We’ll flag that clearly when we’re ready.
1 Like
Small update on the fix : rather than mirroring, we’re moving EvaluatorAssigned entirely to AgentJobManager.fund() — EvaluatorRegistry.assignEvaluator() will no longer emit it. Same outcome for your daemon, cleaner separation of concerns.
Redeployment new addresses (Base Sepolia)
Changes discussed in this thread are now deployed. Thanks guys to pushed back on the interface decisions. Changes from previous deployment :
-
EvaluatorSlashedreverted to 4-field signature (remainingStakeremoved) -
EvaluatorStakeUpdated(address indexed evaluator, uint256 oldBalance, uint256 newBalance)added, emitted on slash, stake, and unstake -
EvaluatorAssignedmoved toAgentJobManager.fund()exclusively, daemons watch one contract
Contracts :
-
AgentJobManager :
0x892e7e77BC8DBc7E97E16E8e7DcF3783aFbB3A19 -
EvaluatorRegistry :
0xe5517C488a470D5eeB5Aa812bb87c09fc5c14D21 -
ReputationBridge :
0xba6195A6afF8997C8E1439b1634d4cA28A9e4c54 -
MockUSDC :
0xe02cc9863bf4d49Fcc88DD9C098d6CA97D332FDD -
ProtocolToken :
0x74038A4790B2082dAEF447ed9a32a1EBa3e3Dd69
@cmayorga EvaluatorStakeUpdated is live, 4th scenario can move forward when it fits your queue. Mock update needed on EvaluatorSlashed (4 fields).
@ThoughtProof @pablocactus restaking needed on the new EvaluatorRegistry. 2-day governance delay before assignEvaluator() is operational. We’ll post here once fully wired.
1 Like
Contracts updated on our side. Blocked on VRT.. evaluator wallet 0x35eeDdcbE5E1AE01396Cb93Fc8606cE4C713d7BC has zero balance on the new deployment. Could you send 100 VRT from the deployer to unblock staking? Once received we’ll stake and restart the daemon.
Sent 100 VRT to 0x35eeDdcbE5E1AE01396Cb93Fc8606cE4C713d7BC. Also sent 100 VRT to ThoughtProof so they can stake as well.
Heads up @Bakugo32, addresses noted and the credit to @ThoughtProof here is well-earned — the `oldBalance/newBalance` refinement is what made the stateless-indexer pattern actually work. Good to see the full design land in production exactly as discussed.
Quick mock note: the `EvaluatorRegistryMock` in #1653 is already on the 4-field `EvaluatorSlashed` signature (commit `d643129f`, pushed yesterday with the `slashedAmount → amount` rename). No update needed on the existing scenarios — they were built against the canonical 4-field shape from the start, the `remainingStake` variant only existed in the previous deployment.
On the 4th scenario: now that `EvaluatorStakeUpdated` is live with a real signature and a deployed reference, I’ll prepare it as a follow-up PR (separate from #1653 to keep that one stable in the editor queue). The shape: an enriched claim flow that consumes both `EvaluatorSlashed` and `EvaluatorStakeUpdated` from the same tx, demonstrating the stateless solvency-aware claim assessment pattern that @pablocactus’s AHM and @ThoughtProof’s verification both flagged as their use case. Will reference your new `EvaluatorRegistry` at `0xe551…4D21` as the production anchor.
No rush on my side — letting the redeploy settle and the governance delay clear before starting feels right.
1 Like
Good news on the mock, one less update to coordinate. And appreciated on the @ThoughtProof credit, the oldBalance/newBalance call was exactly right.
Governance executed this morning. Both contracts are now fully wired. @ThoughtProof @pablocactus, auto-assign is operational. Looking forward to the follow-up PR when it’s ready.
1 Like
Daemon is running and healthy but isEligible() is still returning false as of 16:03 BST - warmup should have cleared by now based on our stake timestamp. Is there an additional condition on the new EvaluatorRegistry we should be aware of?
Warmup period updated to 24h on the new EvaluatorRegistry, aligns with what we discussed. We had set up a 7 days warmup for the new deployment on production. But since we are in testnet we set back to 24h. @pablocactus @ThoughtProof both wallets are now eligible.
Great news on governance clearing. Daemon is live on Railway.. just confirmed eligible=true. Looking forward to the first auto-assigned job on the new contracts. The 4th scenario sounds exactly right.. the stateless solvency-aware pattern is precisely what we need for D1 enrichment.
Great — then evaluator-side looks fully green now.
Only remaining blocker on our side is that the new JM enforces creator ≠ provider, so we either need jobs created by you or a separate client signer to run the first end-to-end auto-assigned flow.
No separate signer needed, the deployer wallet acts as client, your wallet as provider. Those are already distinct, so the check passes. We can create a job now to test the full flow.
Two jobs live on the new contracts, both funded with 1 USDC :
-
Job #1 - provider : @ThoughtProof, evaluator: @pablocactus (auto-assigned)
-
Job #2 - provider : @pablocactus, evaluator: @ThoughtProof (auto-assigned)
Ready when you are.
Daemon is live and eligible but not picking up Jobs #1 or #2 - tracked_jobs remains 0 after a full 50k block lookback. Are the EvaluatorAssigned events being emitted from AgentJobManager on the new contracts as discussed, or still from EvaluatorRegistry? Can you share the block numbers for the assignment transactions so we can verify?
Update — after checking directly, the events are confirmed in the tx receipts on 0x892e7e77BC8DBc7E97E16E8e7DcF3783aFbB3A19 at blocks 40338258 and 40338369, but eth_getLogs is returning nothing on Base Sepolia for this recently deployed contract. RPC indexing lag on new deployments.
Workaround: fetch receipts directly via eth_getTransactionReceipt on the fund tx hashes:
-
Job #1:
0xdc77362336f3458b40d741fdf9f68f94ab39fc4f903e869f363a2e57f95316c6 -
Job #2:
0x0668eb4803aa214fa4e1e8e7991271f892551a1a5672bff0d9c8f9f0bf970d07
4th scenario pushed to [PR #1653]( ERC-8210: Add multi-hop workflow reference scenarios by cmayorga · Pull Request #1653 · ethereum/ERCs · GitHub ), commit `ce9c6d0b`. Two tests: partial slash (800/2000, evaluator retains 60% stake) and full wipeout (slash == entire stake, newBalance == 0).
The mock (`EvaluatorRegistryWithStake`) emits both `EvaluatorSlashed` and `EvaluatorStakeUpdated` in `slashEvaluator()`, so the stateless-indexer pattern is exercised end-to-end. Evidence payload encodes references to both events — resolver verifies slash authenticity and solvency snapshot from the same opaque bytes, no interface changes to AAP.
References your new `EvaluatorRegistry` at `0xe551…4D21` in the scenario doc.
1 Like