Provider Name(s): N/A
Provider Delegation Addresses:
sgb provider
0x000000000000000000000000000000000000dEaD
flr provider
0x000000000000000000000000000000000000dEaD
Network: FLR, Songbird
Overview:
Purpose of this proposal is to formally declare if erroneous data submitted by a FTSO to either network is grounds for a chillable offense (whether or not the provider acted maliciously.) As we all know, the FTSO management group proposal highlighted no formal rules or framework for the group, however, as a community, it might be in the network(s) best interest to safeguard our algorithm submissions to prevent harm to the protocol and dApps/other protocols that may depend on the feeds today, and into the future.
This is an informal discussion with no time limit – Over time, if we garner enough interest to put up for a vote, it may come in multiple pieces.
E.g.
Vote 1.) Erroneous data spikes/submits are a chillable offense
Vote 2.) Stable coin depeg protections should be set a .XX ratio as a FTSO Guideline
Vote 3.) Other things we may want to consider
This first appeared as a public consideration on @AtlasTSO thread at Common Price Fluctuations (spikes) between Ivy Oracle + Anon - #3 by Neil_AU
Many things to consider that may include but are not limited to:
Warnings for first offenses
Pattern of the Behavior
Tenure on the network (give a break to new providers)
Whether the provider is acting maliciously
Etc.
Request of Management Group Members:
Pop in and give your thoughts over time if you see this thread.
Request to the Flare Foundation:
N/A – don’t chill these addresses, please