An overview

Further Information

Everyone is aware of blockchain's immutability feature, which is unquestionably one of its most appealing features in some ways.

However, it isn't always beneficial because there must be an assumption that a deployed smart contract contains a flaw and holds users funds.

The developers should repair the bug(s) as soon as possible, just like they would in Web2 applications but it's not the case when it comes to Web3 development.

Such extensive updates are not possible via smart contract paradigms on their own.

Investors who are reading this Novoos section of the whitepaper must have been in projects where they have a bug or an issue with their contract, they deploy a new one, airdrop or ask you to send tokens to their new contract or a wallet.

This also brings rise to additional scams where clones can take over and investors lose their tokens they had brought with downtime and loss of precious time that could be allocated to other important parts of the project itself.

When there is a bug or issues existent within a smart contract, for example raised by an auditor as recommendations, the developers must create a new contract and keep doing this for each fix or/and change. There then come migrations and relaunches as many of you know, this causes those specific projects to lose some traction and investors have to be airdropped, loss of time and therefore the whole process becomes inconvenient.

In parallel, this is not the case for $NOVO as we are using the latest technology of upgradeable contracts, this is essentially scarce in the space and not being implemented by most of the projects out there.

This is mainly due to lack of experience and the fact this route is rather complicated and requires much experience to create a contract of this nature, the average Smart Contract Developer will find it rather difficult to replicate the $NOVO contact to it's full capacity, they mainly work on Remix, Truffle etc.

The NAC is also beneficial as when an auditor states certain recommendations, these can be implemented right away without any inconvenience to investors at all and therefore the project.

While it doesn't seem like a benefit at first, it'll be a major burden as the codebase expands and new features are added, Novoos can do this with minimum disruption and on the fly.

With standard contracts, data must be moved from one contract to another to reflect the protocol's current condition.

Although physical limitations may prevent you from upgrading certain components, the solution to this problem is to employ different upgradability patterns which have been implemented by $NOVO already.

The proxy pattern, in particular, is considered the most genuine form of upgradability, we are using a more advanced protocol with transparency methods which are more secure.

The $NOVO upgradeability feature is unique, as an example, the investor who holds Novoos tokens, continues to interact with the same contract at all times without any inconvenience (The NAC - 0xD655981fB2F15498e3279EC34CAe2baC6c6744CD - proxied), but the underlying logic can be upgraded as needed without losing any past data on the blockchain.

The $NOVO contract protocol has several advantages and follows recommended patterns without the security concerns that are existent in current upgradeable contracts, which are scarce in themselves.

The $NOVO contract protocol is not a simple and straight forward upgradeable protocol, and the standard has been raised.

The $NOVO contract is exclusively a rather gas-efficient surrogate pattern, and it has several benefits.