Skip to content

support a param on SubmitEvidence to inform whether to advance #10748

Closed
@turadg

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
Loading

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

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions