support a param on SubmitEvidence
to inform whether to advance #10748
Description
What is the Problem Being Solved?
Currently the Fast USDC contract advances every transaction that it learns about (if it can). The problem is some transactions are too risky.
We need the oracles to assess the risk using the chainPolicy and include information for the Advancer to decide.
We also need the reasons to be logged and written to vstorage for the end user to see in the transaction dashboard.
Description of the Design
A second parameter to submitEvidence
, riskAssessment
. For now it will just have one property risksIdentified?: string
. That means the risks identified so far. Over time the riskAssessment
can include other properties and the contract can identify new risks or excise ones identified upstream.
It's possible that oracles provide different riskAssessment
values. It's unlikely but one might update to a new policy faster than another and the system should accept that. Differing evidence we treat as failure because they conflict and the system can't know what to trust. For risksIdentified
it can and should take the union.
If the advance is deemed to risky (for now risksIdentified?.length > 0
) then it should transition to a new state, AdvanceSkipped
, writing that status along with the risksIdentified
to vstorage. The settler should treat AdvanceSkipped
the same as AdvanceFailed
(the advance didn't start).
The README should be updated:
stateDiagram-v2
Observed --> AdvanceSkipped : Risks identified
Observed --> Advancing : No risks, can advance
Observed --> Forwarding : No risks, Mint deposited before advance
Forwarding --> Forwarded
Advancing --> Advanced
Advanced --> Disbursed
AdvanceSkipped --> Forwarding : Mint deposited
AdvanceFailed --> Forwarding : Mint deposited
Advancing --> AdvanceFailed
Forwarding --> ForwardFailed
For rationale:
✔️ How should the contract handle conditional advancing?
Security Considerations
This empowers the oracles to prevent advancing. Technically it is only advisory and the contract can change to ignore it or expect other information.
Scaling Considerations
none
Test Plan
Contract tests will suffice in CI. It should verify that when the info is included it's written to vstorage.
We'll also need to cover this in UI integration testing with oracle operators.
This should be covered in the C18 requirement test.
Upgrade Considerations
not yet deployed