top of page
  • Writer's pictureIndividual Pirate

What are FRC759?

A few days ago all Chainge FRC758 token contracts and liquidity contracts were replaced with new ones. The transition happened in a way where value was perserved for all regular holders and Chainge users. Though tokens held in contracts outside Chainge will need a more manual approach in settling balances.

After this transition there's only 2 FRC758 contracts that are still valid, the FREE and FMN token contracts. Since these have unique tokenomics, replacing them fully with new contracts is a bit tougher, but will also be happening with time. More information about that will be provided later. In the meantime continue to use and gather with the FRC758 contracts.

But let's get back to FRC759 what is it exactly? The code has only been made public as the contracts were rolled out on the Fusion Foundation githib and is still lacking in comments explaining it.

Developers seem to like what they see in the new code though and descibe it as more elegant, complete but also very different than the FRC758 predecessor. There seem to be two things that make them fundamentally different than FRC758 contracts.

New things:

-For FRC759 each new time used for time-frames will be a seperate contract

-It's possible to make the contracts controlled by an address

These fundamental changes come with both advantages and disadvantages. The advantage of having time-frames as seperate contracts is that they become easier to track and are more "distinguished". It rhymes well with the current use cases of giving value to a very specific "time" (the major one being the end of the year in Chainge). Identifying a contract is much easier than identifying an exact time in case you wish to buold something that interacts with something someone else built. Overall, building cool new contracts with time features, should get easier as a result.

The disadvantage might be that this is likely to kick off a plethora of different contracts and as such navigating in the contract jungle may get more difficult. It could also end up increasing the amount of data needed to be stored by staking nodes at a much quicker pace than before. Block Explorers may also be challeneged by this.

As for point 2, if a token contract can be controlled, it is also controlled by a centralized party, which clould perhaps blacklist and adjust balances if needed. I'm not going to go into detail about what this could mean because I feel like I already wrote on this subject here. For the future $FMN FRC759 contract, we will definatly not be using this aspect by seting controls to a burn address. The advantage of something like this, is that it probably keeps regulators happy.

We have also discovered something else, and this is that interaction between FRC758 and FRC759 contracts isn't ideal, which might explain the decision to so quickly replace everything by Chainge and also why they are no longer supporting any FRC758 contract. Effectively this will end up making FRC758 contracts useless and anyone that wishes to establish themself on Fusion, really needs to be using FRC759 contracts. It's not really an option. So those hoping to build on Fusion, please get to know the code of FRC759 (same link again).

Another role of these contracts is that they seem to be key in the coming cross-chain DEX aggregator. Chainge is describing this change in the contracts as step 1 in a 3-step process towards the aggregator. Given the regulatory aspect of the contracts, I think it's also fair to say that they are also part of the process in establishing the fita gateway.

242 views0 comments

Recent Posts

See All


bottom of page