FTSO AU Staking Implementation | Flare Network

Staking on Flare via the vast number of wallets available has its technical hurdles to overcome due to the network operating with three individual chains; the C, P & X chains.

The chain we all know and use by default is the C chain which is using the EVM enabling a familiar user experience such as the use of smart contracts and 0x addresses.

The P chain is a UTXO chain (like Bitcoin) which is isolated from the C chain and is where validator staking takes place.

The biggest challenge of all is the security complication when signing and issuing transaction via popular wallets which is a result of little support for this type of sub chain architecture.

We can very easily build transactions and issue them to EVM chains in a safe manner due to certain standards implemented by wallets that provides transparency between an application and the user signing a transaction.

But even with this transparency, the security is still mostly dependant on the user understanding the transaction they are signing. Complacency often leads us to ignore reading the details of our wallet's signature request pop up and proceed to just click ‘sign’ with little thought.

So, no matter what measures are taken by an application to provide security for their users - there are always risks involved.

The implementation of staking from Flare (found at staking.flare.network) only allows the usage of Ledger devices for signing staking transactions such as cross chain transfers and delegations to validators.

They haven’t excluded other wallets due to a lack of time or skill but rather to minimise the security risk involved as much as possible until options exist that satisfy their risk tolerance.

On the other hand - that means there ARE options to stake using other wallets but the risk to the security of the signers assets increases.

But just because the security risk is higher, it doesn’t inherently mean that other methods of signing are unsafe. We just must take certain steps to protect our assets.

The approach taken for app.au.cc does not expose private keys - which is vitally important but rather employs a method provided by wallets called ‘eth_sign’.

Eth_sign was a very early way of signing data before wallets began implementation of newer signing methods that provide more transparency between the data and the user is signing it.

It allows the signing of arbitrary hashes - which means any data can be requested to be signed and issued on chain and the user is not easily able to decipher what they are signing.

If you have heard of “blind signing” before, particularly on Ledger devices, this is more or less the same thing. The risk is that you could be signing a transaction that you do not intend to.

Why is this a bad thing?

As previously mentioned, complacency in signing transactions and skipping straight to the sign button would be no different to blind signing - so the point here is that if you trust the app requesting the signature your risk is substantially lowered.

If we could undoubtedly trust every app we interact with then there wouldn’t be much of an issue - except for two things…

• Compromised App: If the app is compromised, the attacker could replace what you normally sign with some malicious data to drain your assets.
• You are mislead: If you find yourself on a phishing site where the trusted app has been copied and looks like the trusted app, you could be lead to sign a malicious transaction.

Unfortunately, there isn’t a lot that can be done if the trusted app is compromised. This is likely where the greatest risk is.

You do however have a defence against being mislead: get the link to the trusted website from a trusted source, and bookmark it. Additionally, always verify the URL before signing any transactions.

These attacks are an equal risk even without considering Eth_sign - but it’s a greater threat due to being unable to immediately identify if what you have signed was malicious or not.

With these considerations, Eth_sign is, generally speaking, safe to use if you understand what you are signing and trust the issuer of the transaction; with the caveat of a compromised app or being mislead.

It is therefore recommended to only enable and use Eth_sign with apps that you trust and have verified. Furthermore, you should only have Eth_sign enabled temporarily while it’s required and disable it after usage.

You can also create an additional address within your wallet to isolate assets to reduce losses in the event of becoming a victim to an attacker (this is best practise, again even without considering eth_sign).

Now, how is Eth_sign used when it comes to staking?

A package released by Flare called ‘FlareJS’ provides helper methods to create and issue transactions specific to Flare.

This includes cross chain assets transfers, staking and helpers for deriving user addresses (ie. their P chain address).

Our app interfaces with FlareJS, providing parameters input by the user, such as the number of tokens they wish to move to stake, this is translated into a format that can be signed.

With the signable data in hand, we request the users MetaMask wallet to sign it. This returns the users signature which, along with the data, can be submitted on chain with a method call with FlareJS.

The transactions are submitted through our secure Flare nodes that have been in operation since Flare launched.

This process never exposes the users private key (we couldn’t request it from MetaMask even if we wanted to).

We value our users security and as such actively assess our security and conduct frequent internal security audits - though we must still be aware of threats that are sometimes out of our control. So to reiterate, if you wish to use eth_sign, our recommendations are the following:

• Only enable eth_sign requests temporarily and toggle off this functionality after completing tasks requiring it.
• Always verify the website you are accessing and only visit our app from verified sources. Links can be spoofed, it’s always better to type it in or click from an official source).
• Isolate your assets with multiple accounts. We recommend having an account (address) dedicated to staking as in the event a malicious transaction is signed, your asset exposure would be limited.

If you do not understand these risks or are unsure at any stage about what you are signing, you should STOP, close any wallet windows and exit the website immediately.

FTSO AU will always be here to support you through the process and help you understand the process, so exercise caution and always ask for assistance from our official sources Website, Twitter.