FTSO matters

[BillyOckham]

I saw a post by @FTSO_AU and started to wonder if they or others in that space would consider speaking here about the FTSO.

For instance, as I understand it,  we can delegate our vote to an org that is providing a feed and be rewarded with some share of the FTSO rewards.  But how would we decide which one to delegate to?
 

And wouldn’t the system likely centralise like PoW miners have?  If the rewards are split across according to vote share,  then won’t the biggest just grow bigger?

Would you @FTSO_AU (or anyone else in this space who is planning on providing a feed),  share any information about this with us?

 

 

Edited May 27, 2021 by BillyOckham

[LaBelleSaison]

1 hour ago, BillyOckham said:

And wouldn’t the system likely centralise like PoW miners have?  If the rewards are split across according to vote share,  then won’t the biggest just grow bigger?

 

In my understanding the FTSO rewards will be decided not solely by the number of votes but also by the accuracy of feed provided, thereby avoiding the situation of your concern to some extent. Am I correct? 

[ftso_au]

4 hours ago, BillyOckham said:

I saw a post by @FTSO_AU and started to wonder if they or others in that space would consider speaking here about the FTSO.

We'd be happy to join the discussion, although there's still some areas we're waiting on clarification so we'll do our best.

Regarding the accuracy of the feed accuracy ... here's a question that was asked of us recently:

Q./ How does the FTSO determine if the prices the FTSO providers are providing are accurate? I understand the top and bottom 25% votes are discarded, but how does the FTSO know the middle 50% are accurate?

A./ It’s based on consensus. All Flare networks users can vote with Spark or the corresponding Fasset, so the price assumed to be accurate if a majority of people believe it to be.

4 hours ago, BillyOckham said:

But how would we decide which one to delegate to?

There'll be a number of factors you can consider when making your decision ...

- Fees charged + win rate %. There's no point choosing the FTSO based solely on the fees if their % win rate is well below the others. 

- Participation in the Flare community. You want an FTSO that's engaged with all areas of the Flare community.

- Supporting the ecosystem. Things like running validators / nodes for Flare and other integrated networks, XRP, XLM, LTC, DOGE etc ...

- Informative website. A thorough well designed and maintained website should give you peace of mind you're dealing with a professional and trusted business.

- We're working on a few delegator benefits at the moment but I'd rather not divulge just yet, but they'll be very good reasons that differentiate us from the others.

The process to delegate your vote will be simple and easily / quickly changed if for some reason you're not happy with the service you're getting from an FTSO. It's also possible to split your votes among several providers so that's another safety net that you don't need to have all your eggs in one basket.

I hope that helps!

[BillyOckham]

9 minutes ago, FTSO_AU said:

We'd be happy to join the discussion, although there's still some areas we're waiting on clarification so we'll do our best.

Regarding the accuracy of the feed accuracy ... here's a question that was asked of us recently:

Q./ How does the FTSO determine if the prices the FTSO providers are providing are accurate? I understand the top and bottom 25% votes are discarded, but how does the FTSO know the middle 50% are accurate?

A./ It’s based on consensus. All Flare networks users can vote with Spark or the corresponding Fasset, so the price assumed to be accurate if a majority of people believe it to be.

There'll be a number of factors you can consider when making your decision ...

- Fees charged + win rate %. There's no point choosing the FTSO based solely on the fees if their % win rate is well below the others. 

- Participation in the Flare community. You want an FTSO that's engaged with all areas of the Flare community.

- Supporting the ecosystem. Things like running validators / nodes for Flare and other integrated networks, XRP, XLM, LTC, DOGE etc ...

- Informative website. A thorough well designed and maintained website should give you peace of mind you're dealing with a professional and trusted business.

- We're working on a few delegator benefits at the moment but I'd rather not divulge just yet, but they'll be very good reasons that differentiate us from the others.

The process to delegate your vote will be simple and easily / quickly changed if for some reason you're not happy with the service you're getting from an FTSO. It's also possible to split your votes among several providers so that's another safety net that you don't need to have all your eggs in one basket.

I hope that helps!

Awesome stuff.  Thanks heaps for engaging.  I wish you every success with this endeavour.
 

Can I ask a follow up?   If the switch can be made at any time...  do we get pro-rata from the previous provider for the period that we were with them?

 

[ftso_au]

1 hour ago, BillyOckham said:

Can I ask a follow up?   If the switch can be made at any time...  do we get pro-rata from the previous provider for the period that we were with them?

No, there's no carry over between signal providers. The reward periods will be very frequent too so its not like you'll need to plan when to make a change.

A little more info. When delegating you'll do so by %, let's say you choose 30% with provider X, 45% with provider Y and 25% with provider Z. You'll be able to adjust these % quite dynamically ... I don't see once you've delegated that there'll be a time where you won't be counting towards the voting power therefore earning rewards ... unless you chose to un-delegate all together.

[ftso_au]

There’ll be a document released by Flare next week detailing more about the FTSO price provider process. 

[ftso_au]

I’m working on a blog post to outline the delegation process, it’s understandably much sought after information.

The precursor for me to publish it, is the release of the “FTSO Price Provider” document from Flare, which *should* be released in the coming days.

We should start to see lots more information / documentation released in the very near future … as soon as I get it, I’ll share it here.

[ftso_au]

Here's the FTSO price provider design paper, released today by Flare Network.

Have a read of it and let's discuss. I removed a large block of code at the end of the document, I deemed it irrelevant to this thread.

I'm in direct contact with the Flare team and can advise them of any feedback.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

FTSO price provider

Providing prices to the Flare time series oracle for fun and for profit

TL;DR

On chain FTSO prices will be updated every few minutes. Any user (address) can provide prices (data) by reading prices from any chosen source and submitting them to a dedicated API on the ftso contract. Any FLR holder can participate by delegating their vote power (1:1 based on flare balance) to another address (price provider) that submits prices. Good price feeds will be rewarded with part of the FLR inflation, in the form of FLR tokens on the Flare network. An address must have some minimum vote power in order to submit prices.

FTSO overview

The FTSO or ‘Flare Time Series Oracle’ is a service to gather price (and data) signals of off-chain assets for consumption by other smart contracts on the Flare blockchain. The system is designed to encourage FLR holders to submit accurate prices to the FTSO contracts. Prices will be submitted in price epochs of a few minutes. For every price epoch, a weighted median algorithm will aggregate all price submissions to find the median price, which will become the current FTSO price. Good price submissions will be rewarded with newly minted FLR tokens (FLR inflation).

Price submissions are considered good if they are within the interquartile range (within 25% of either side) of the submissions around the weighted median price. The rewards will be distributed between good submissions according to the relative weight (balance / vote power) of each address.

An FTSO contract will be deployed for any new data signal supported by the Flare network, as determined by governance. The Flare Foundation currently plans to deploy contracts that will provide USD prices of FLR, XRP, LTC, XLM, DOGE, ADA, Algo, BCH, Digi and more to come.

More detail about the FTSO can be found here: https://blog.flare.xyz/ftso-a-breakdown/ Introducing WFLR - a vote power token

The WFLR token represents wrapped FLR. Any user can wrap their FLR by sending FLR to the WFLR contract via the deposit API. WFLR can then be converted back to FLR by calling a withdrawal transaction on the WFLR contract. FLR and WFLR will always have a 1:1 ratio.

WFLR must be used in the price submission process. It is an ERC20 token that also supports vote power delegation from one address to another. Meaning, any WFLR holder can delegate their vote power to any other addresses. FLR depositors always maintain custody of their WFLR. When delegating vote power, WFLR holders retain full custody over their WFLR.

Note that although WFLR and FLR always have the same value, they differ in usage. Only FLR can be used to pay for flare network transactions (gas), while only WFLR can be used to represent and delegate vote power in price submissions.

Who can submit prices

Any account (Flare address) submitting prices will require a minimum amount of WFLR voting power, vote power must be some minimal percentage of the total WFLR supply. In essence, WFLR vote power reflects any given account’s balance, plus the vote power delegated by any other account. Use getpriceepochdata() (below), to query minimal required vote power.

Price providers must have WFLR voting power and/or FAsset (flare XRP, flare LTC, etc.) voting power. However, only WFLR holders will receive FLR rewards for good price submissions.

How does this work?

A WFLR holder can delegate vote power by percentage to a limited number of addresses, currently 3. The actual delegated vote power will be updated upon each token transfer.

Example:

Alice has 10 FLR, she has no vote power delegated to her.
Alice wraps her 10 FLR by calling WFLR.deposit(), thus she now has vote power of 10.
Bob has 30 WFLR so he has vote power of 30.
Bob decides to delegate 50% of his vote power to Alice. Now Alice has vote power of 25 and Bob has vote power of 15.
Bob receives 20 more WFLRtokens, so now Alice has vote power of 35 and Bob has vote power of 25.
Notice how when a delegator receives additional WFLR, the contract automatically updates vote power for all relevant delegatees according to their delegation percentage. It is important to note that although Bob has delegated 50% of his vote power to Alice, he still retains his 30 WFLR.

Note that for the Beta run of FTSOs, any address holding WFLR can submit prices However, there will be minimum thresholds of vote power required to submit prices at mainnet launch.

How to submit prices

Price epochs follow the commit and reveal scheme. The commit period is the price epoch period (few minutes long) immediately followed by x minutes of the reveal period. More on this scheme can be found here. This scheme is designed to stop individuals from submitting prices based on others’ price proposals. Within the commit period, all submissions are secret. After the commit period passes, individuals will no longer be able to change their submissions. During the reveal period, individuals must mandatorily reveal their prices to be considered by the FTSO. At this point, changes can not be made, and prices become public record.

Together with price data, any price provider must add a random number to their price submissions. This helps seed the source of randomness on the Flare chain for FTSO operations that require randomization.

Submit price hash

function submitPriceHash(bytes32 _hash) external; The _hash should be keccak256(price, random)

Reveal price

Epoch ID should match the epoch in which the hash was submitted. For keeping track of epoch IDs, see the next section.
Price and random should be the same ones that were used to create the hash in the relevant price epoch period. If they don’t match, the transaction will be reverted and the committed price will not be included in the price determination algorithm.

As soon as the reveal period ends, the weighted median algorithm will process all revealed prices, and publish the median as the current price of the asset.

Price submitter contract

A Price submitter contract will enable each provider to send the above Txs batched together. One Tx can be used to sbumitPrice to all FTSO contracts and later to revealPrice in all FTSO contracts

function revealPrice(uint256 _epochId, uint256 _price, uint256 _random) external;

function submitPriceHashes( IIFtso[] memory _ftsos, bytes32[] memory _hashes

) external;

function revealPrices( uint256 _epochId, IIFtso[] memory _ftsos, uint256[] memory _prices, uint256[] memory _randoms

) external;

With batched transactions the price provider sends a list of FTSO addresses and the relevant data according to the operation type (submit or reveal). One can use this contract to interact with all FTSOs or a parietal list.

Price submission timing

The price provider should maintain accurate timing synchronization with the on-chain timestamp value. Note, both high and low on-chain activity as well as high API node activity will affect the accuracy of the queried timestamp. It is advisable to run a flare node (more instructions to be made public) that is dedicated for price provider activity and event polling. When using a public API node to interact with the Flare network, one should expect lower accuracy.
The time frame for an epoch can be taken from:

function getPriceEpochData() external view returns ( uint256 _epochId, uint256 _epochSubmitEndTime, uint256 _epochRevealEndTime,

uint256 _votePowerBlock, uint256 _minVotePowerFlr, uint256 _minVotePowerAsset, bool _fallbackMode

);

●  All time values are using timestamp from the unix epoch.

●  When in fallback mode, the FTSO takes price values from a trusted list of addresses

(chain link style).

Price submission vote power

Each price epoch has a specific vote power block which is used as a snapshot to find vote power of each address. The above function - getPriceEpochData() - can be used to determine the vote power block of each price epoch. Each provider should check their own vote power at the block and make sure they have enough vote power to submit prices. The same vote power block will be used in a series of price epochs. More on this will be described in a separate blog post. WFLR vote power can be determined using API WFLR.votePowerOfAt(address, block). Later when the fAsset system goes live, the same API will be used for the fAsset tokens to query the vote power of an address.

Events

Price submission event

event PriceHashSubmitted(

address indexed submitter, uint256 indexed epochId, bytes32 hash, uint256 timestamp

);

A submitter can listen for this event to know which epoch ID the price was submitted for.

Price reveal event

The event will be emitted only if the price reveal was accepted, meaning the submitting address holds enough vote power (in either WFLR or FAsset) and that the hash of the submitted data matches the committed hash.

Events pxrice Epoch init + finalize

event PriceRevealed( address indexed voter, uint256 indexed epochId, uint256

price, uint256 random, uint256 timestamp, uint256 votePowerFlr, uint256 votePowerAsset

);

event PriceFinalized( uint256 indexed epochId, uint256 price, bool rewardedFtso, uint256 lowRewardPrice, uint256 highRewardPrice,

PriceFinalizationType finalizationType, uint256 timestamp

);

event PriceEpochInitializedOnFtso( uint256 indexed epochId, uint256 endTime, uint256 timestamp

);

General recommendations for system design

Congested API nodes can cause delays in events, revert messages, or lead to any other web3 exception. The same holds for any data query. That being said, it is not advisable to rely on the timing of events: PriceSubmitted, PriceRevealed etc.
Due to the above, it is advised that price providers:

-  Maintain internal timing mechanisms for sending TXs at correct times

-  Maintain internal nonce count.

-  Do not send PriceReveal and PriceSubmit calls near the end of the allowed time

frame. Congested networks can cause price reveals to confirm after the reveal period ends even if the transaction was initiated within the reveal period.

Price provider pseudocode

Code removed as I deemed it largely irrelevant.

[brianwalden]

2 hours ago, FTSO_AU said:

Here's the FTSO price provider design paper, released today by Flare Network.

Have a read of it and let's discuss. I removed a large block of code at the end of the document, I deemed it irrelevant to this thread.

I'm in direct contact with the Flare team and can advise them of any feedback.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

FTSO price provider

Providing prices to the Flare time series oracle for fun and for profit

TL;DR

On chain FTSO prices will be updated every few minutes. Any user (address) can provide prices (data) by reading prices from any chosen source and submitting them to a dedicated API on the ftso contract. Any FLR holder can participate by delegating their vote power (1:1 based on flare balance) to another address (price provider) that submits prices. Good price feeds will be rewarded with part of the FLR inflation, in the form of FLR tokens on the Flare network. An address must have some minimum vote power in order to submit prices.

FTSO overview

The FTSO or ‘Flare Time Series Oracle’ is a service to gather price (and data) signals of off-chain assets for consumption by other smart contracts on the Flare blockchain. The system is designed to encourage FLR holders to submit accurate prices to the FTSO contracts. Prices will be submitted in price epochs of a few minutes. For every price epoch, a weighted median algorithm will aggregate all price submissions to find the median price, which will become the current FTSO price. Good price submissions will be rewarded with newly minted FLR tokens (FLR inflation).

Price submissions are considered good if they are within the interquartile range (within 25% of either side) of the submissions around the weighted median price. The rewards will be distributed between good submissions according to the relative weight (balance / vote power) of each address.

An FTSO contract will be deployed for any new data signal supported by the Flare network, as determined by governance. The Flare Foundation currently plans to deploy contracts that will provide USD prices of FLR, XRP, LTC, XLM, DOGE, ADA, Algo, BCH, Digi and more to come.

More detail about the FTSO can be found here: https://blog.flare.xyz/ftso-a-breakdown/ Introducing WFLR - a vote power token

The WFLR token represents wrapped FLR. Any user can wrap their FLR by sending FLR to the WFLR contract via the deposit API. WFLR can then be converted back to FLR by calling a withdrawal transaction on the WFLR contract. FLR and WFLR will always have a 1:1 ratio.

WFLR must be used in the price submission process. It is an ERC20 token that also supports vote power delegation from one address to another. Meaning, any WFLR holder can delegate their vote power to any other addresses. FLR depositors always maintain custody of their WFLR. When delegating vote power, WFLR holders retain full custody over their WFLR.

Note that although WFLR and FLR always have the same value, they differ in usage. Only FLR can be used to pay for flare network transactions (gas), while only WFLR can be used to represent and delegate vote power in price submissions.

Who can submit prices

Any account (Flare address) submitting prices will require a minimum amount of WFLR voting power, vote power must be some minimal percentage of the total WFLR supply. In essence, WFLR vote power reflects any given account’s balance, plus the vote power delegated by any other account. Use getpriceepochdata() (below), to query minimal required vote power.

Price providers must have WFLR voting power and/or FAsset (flare XRP, flare LTC, etc.) voting power. However, only WFLR holders will receive FLR rewards for good price submissions.

How does this work?

A WFLR holder can delegate vote power by percentage to a limited number of addresses, currently 3. The actual delegated vote power will be updated upon each token transfer.

Example:

Alice has 10 FLR, she has no vote power delegated to her.
Alice wraps her 10 FLR by calling WFLR.deposit(), thus she now has vote power of 10.
Bob has 30 WFLR so he has vote power of 30.
Bob decides to delegate 50% of his vote power to Alice. Now Alice has vote power of 25 and Bob has vote power of 15.
Bob receives 20 more WFLRtokens, so now Alice has vote power of 35 and Bob has vote power of 25.
Notice how when a delegator receives additional WFLR, the contract automatically updates vote power for all relevant delegatees according to their delegation percentage. It is important to note that although Bob has delegated 50% of his vote power to Alice, he still retains his 30 WFLR.

Note that for the Beta run of FTSOs, any address holding WFLR can submit prices However, there will be minimum thresholds of vote power required to submit prices at mainnet launch.

How to submit prices

Price epochs follow the commit and reveal scheme. The commit period is the price epoch period (few minutes long) immediately followed by x minutes of the reveal period. More on this scheme can be found here. This scheme is designed to stop individuals from submitting prices based on others’ price proposals. Within the commit period, all submissions are secret. After the commit period passes, individuals will no longer be able to change their submissions. During the reveal period, individuals must mandatorily reveal their prices to be considered by the FTSO. At this point, changes can not be made, and prices become public record.

Together with price data, any price provider must add a random number to their price submissions. This helps seed the source of randomness on the Flare chain for FTSO operations that require randomization.

Submit price hash

function submitPriceHash(bytes32 _hash) external; The _hash should be keccak256(price, random)

Reveal price

Epoch ID should match the epoch in which the hash was submitted. For keeping track of epoch IDs, see the next section.
Price and random should be the same ones that were used to create the hash in the relevant price epoch period. If they don’t match, the transaction will be reverted and the committed price will not be included in the price determination algorithm.

As soon as the reveal period ends, the weighted median algorithm will process all revealed prices, and publish the median as the current price of the asset.

Price submitter contract

A Price submitter contract will enable each provider to send the above Txs batched together. One Tx can be used to sbumitPrice to all FTSO contracts and later to revealPrice in all FTSO contracts

function revealPrice(uint256 _epochId, uint256 _price, uint256 _random) external;

function submitPriceHashes( IIFtso[] memory _ftsos, bytes32[] memory _hashes

) external;

function revealPrices( uint256 _epochId, IIFtso[] memory _ftsos, uint256[] memory _prices, uint256[] memory _randoms

) external;

With batched transactions the price provider sends a list of FTSO addresses and the relevant data according to the operation type (submit or reveal). One can use this contract to interact with all FTSOs or a parietal list.

Price submission timing

The price provider should maintain accurate timing synchronization with the on-chain timestamp value. Note, both high and low on-chain activity as well as high API node activity will affect the accuracy of the queried timestamp. It is advisable to run a flare node (more instructions to be made public) that is dedicated for price provider activity and event polling. When using a public API node to interact with the Flare network, one should expect lower accuracy.
The time frame for an epoch can be taken from:

function getPriceEpochData() external view returns ( uint256 _epochId, uint256 _epochSubmitEndTime, uint256 _epochRevealEndTime,

uint256 _votePowerBlock, uint256 _minVotePowerFlr, uint256 _minVotePowerAsset, bool _fallbackMode

);

●  All time values are using timestamp from the unix epoch.

●  When in fallback mode, the FTSO takes price values from a trusted list of addresses

(chain link style).

Price submission vote power

Each price epoch has a specific vote power block which is used as a snapshot to find vote power of each address. The above function - getPriceEpochData() - can be used to determine the vote power block of each price epoch. Each provider should check their own vote power at the block and make sure they have enough vote power to submit prices. The same vote power block will be used in a series of price epochs. More on this will be described in a separate blog post. WFLR vote power can be determined using API WFLR.votePowerOfAt(address, block). Later when the fAsset system goes live, the same API will be used for the fAsset tokens to query the vote power of an address.

Events

Price submission event

event PriceHashSubmitted(

address indexed submitter, uint256 indexed epochId, bytes32 hash, uint256 timestamp

);

A submitter can listen for this event to know which epoch ID the price was submitted for.

Price reveal event

The event will be emitted only if the price reveal was accepted, meaning the submitting address holds enough vote power (in either WFLR or FAsset) and that the hash of the submitted data matches the committed hash.

Events pxrice Epoch init + finalize

event PriceRevealed( address indexed voter, uint256 indexed epochId, uint256

price, uint256 random, uint256 timestamp, uint256 votePowerFlr, uint256 votePowerAsset

);

event PriceFinalized( uint256 indexed epochId, uint256 price, bool rewardedFtso, uint256 lowRewardPrice, uint256 highRewardPrice,

PriceFinalizationType finalizationType, uint256 timestamp

);

event PriceEpochInitializedOnFtso( uint256 indexed epochId, uint256 endTime, uint256 timestamp

);

General recommendations for system design

Congested API nodes can cause delays in events, revert messages, or lead to any other web3 exception. The same holds for any data query. That being said, it is not advisable to rely on the timing of events: PriceSubmitted, PriceRevealed etc.
Due to the above, it is advised that price providers:

-  Maintain internal timing mechanisms for sending TXs at correct times

-  Maintain internal nonce count.

-  Do not send PriceReveal and PriceSubmit calls near the end of the allowed time

frame. Congested networks can cause price reveals to confirm after the reveal period ends even if the transaction was initiated within the reveal period.

Price provider pseudocode

Code removed as I deemed it largely irrelevant.

Can you explain why WFLR is being used?

Does that mean that voting is going to incure an Ethereum transaction fee?

Edited June 3, 2021 by brianwalden
Changed invite to incure

[BillyOckham]

15 minutes ago, brianwalden said:

Can you explain why WFLR is being used?

Does that mean that voting is going to invite an Ethereum transaction fee?

Nah it is on Flare not the Etherium network.  So it will be at Flare network fee rate not Ethers.

[BillyOckham]

To be honest, although I’m fairly sure that this will likely work out ok, the whole idea of a collective wisdom on a price feed is a bit fraught for me.

I’m not sure what form it could take,  but I wonder what shenanigans a whale could play with contracts if she can get a majority of FTSO votes.

[ftso_au]

21 minutes ago, brianwalden said:

Can you explain why WFLR is being used?

Does that mean that voting is going to invite an Ethereum transaction fee?

I'm a little uncertain exactly how Flare leverages the EVM but that's an interesting question I haven't though about before.

In the whitepaper it states:

3.1 Spark technical use
The Flare Network uses the Ethereum Virtual Machine (EVM) [Woo+]. The EVM defines a transaction’s computational
complexity in terms of units of Gas. To avoid extremely lengthy or interminable transactions, Flare imposes a complexity
limit, defined in Gas units. A Gas conversion rate between Gas and Spark tokens is set by the network. Thus, a
transaction cost is defined as the complexity limit multiplied by the conversion between Gas and Spark. The transaction
cost is burned rather than accruing to some set of participants. Both the complexity limit and Gas to Spark conversion
rate are governance parameters, see section 5 for further information on governance.

[BillyOckham]

Also, I am a babe in the woods with smart contracts, but I wonder what sorts of things might need a more frequent price feed than “a few minutes” granularity.  Does it create arbitrage opportunities?

[brianwalden]

1 hour ago, BillyOckham said:

Nah it is on Flare not the Etherium network.  So it will be at Flare network fee rate not Ethers.

It says WFLR is an ERC20 token. The only place ERC20 tokens exist is on Ethereum. Is that a typo? Was it supposed to be FLR20? @FTSO_AU

[Seoulite]

25 minutes ago, brianwalden said:

It says WFLR is an ERC20 token. The only place ERC20 tokens exist is on Ethereum. Is that a typo? Was it supposed to be FLR20? @FTSO_AU

I think it probably is. It is likely that it is a “delegate” transaction which will cost FLR gas. It seems like it would be a massive oversight and huge complication if the Ethereum blockchain was a central part of the Flare network functioning. Think about it: every flare address would also be required to hold eth for gas in order to contribute to the FTSO. That would be a huge thing to forget to mention before now.