-
Notifications
You must be signed in to change notification settings - Fork 18
-
This thread is meant to be a general place for open discussion concerning the state of SIP-11 (Transaction Insights V2).
The SIP is meant to define an additional severity property to the transaction insight return object.
Beta Was this translation helpful? Give feedback.
All reactions
Replies: 5 comments 3 replies
-
I think it would be useful to define the intended behavior for different severity levels.
Some severity levels that deserve definition:
- Nothing to say, wallet can exclude this snap from display.
- Some basic analysis to present, no certainty of confidence level.
- A confident analysis to show the user, which can be treated as an accurate and comprehensible representation of the action, and should be shown to the user without collapsing.
- Caution advised, some degree of risk recognized.
- Rejection recommended, a confident dangerous signal was detected.
Beta Was this translation helpful? Give feedback.
All reactions
-
We've had some discussion around severity levels in the snaps team and we landed on just doing the critical level for now. There was some concern that most users would interpret caution advised situations as rejection so there wouldn't be a point in adding that granularity. I do agree that the existing critical should probably have a concrete definition, it would probably fall in with a "rejection" recommendation. We left it as an enum so we can update the SIP in the future with more levels that we think make sense. A "nothing" to say snap is essentially one that doesn't return a result, we filter those out when we make a request to the transaction insight snaps installed -- I don't think that needs its own severity level.
Beta Was this translation helpful? Give feedback.
All reactions
-
If only one more, I recommend " A confident analysis to show the user", as the design team is recommending collapsing most to a truncated view by default, since most are useless, and this strikes me as admitting defeat. We need to reserve space for coherence whenever it is available.
Beta Was this translation helpful? Give feedback.
All reactions
-
What is the difference between a confident analysis and one analysis that is truncated by default? If we make a distinction, a confident analysis (one that isn't truncated) is implicitly saying that the one that is truncated is not "confident". I think that's where I'm struggling to see a use case. Snap developers would then just want to mark every analysis as confident to circumvent the truncation.
Beta Was this translation helpful? Give feedback.
All reactions
-
I’d rather we fail to showing too much info than too little, and am concerned that if we have no mechanism to ensure display, we will risk underinforming users.
Beta Was this translation helpful? Give feedback.
All reactions
-
That's fair, I'll discuss more with the team
Beta Was this translation helpful? Give feedback.
All reactions
-
I want to take my feature request further: If a snap declares it can provide a confident, authoritative representation of a confirmation, its view should appear at the top of the confirmation, as the primary view to represent it. I can imagine this becoming the default info that is usually shown when interacting with a smart contract.
Beta Was this translation helpful? Give feedback.
All reactions
-
We're talking about measuring "% of confident tx representations" as a KR to improve. This snap API could be used as a source of that data. There's an open question as to whether a simulation produces a confident (comprehensive) representation of an action, or merely represents some quantity of side effects. Ideally, a simulation snap would distinguish between which type of result it was providing.
Beta Was this translation helpful? Give feedback.