Audit & Remarks
Last updated
Last updated
– Upgradeability
Contract is an upgradeable Comment: As noted in the Inheritance Graph, p. 21, each contract is upgradeable per our base/upgradeable design. This design incorporates risk management measures for our digital asset certificate of deposit. It derives from the unique design of our source code, and ~90% of contracts are upgradable. The NXN team will use gnosis safes to safely control upgrades per the LLC’s operating agreement.
– Ownership
The ownership is not renounced
Comment: The owner has significant control over each contract’s operations, meaning the LLC will act in accordance with the operating agreement to alter any contract’s operations via gnosis safes. Common best practice is to utilize the upgradeable contracts for core business functions to balance risk management.
– Minting Tokens
Contract owner can mint new tokens
Comment: Only callers can mint new tokens, not owners. The contract will be placed into a multi-signature wallet in accordance with reasonably commercial business practices of this nature, which will be controlled by the LLC; no one person will serve as the contract owner.
– Burning Tokens
Contract owner can burn tokens
Comment: Only callers can burn tokens, not owners, which derives from NXN’s unique approach to tokenomics. The total supply of tokens is contingent upon how many tokens are sold and minted in each phase of the raise; any earmarked tokens not minted will be burned in accordance therewith. Also, the contract will be placed into a multi-signature wallet in accordance with reasonably commercial business practices of this nature, which will be controlled by the LLC; no one person will serve as the contract owner.
– Lock User Funds
Contract owner can lock the user funds
Comment: The LLC needs the ability to pause the contract in the event of a discovered/known vulnerability, so we can remediate and patch the same without compromising user funds.
This privilege is a commercially reasonable information security practice in the event of the discovery of a vulnerability–critical or otherwise.
#1 | Unprotected Burn
Comment: This function was designed by NXN and directly reflects our approach to tokenomics. This was done by design, as the adoption amplifier is supposed to end on a specific date, and thereafter, a portion of tokens will be burned on a successive schedule (i.e., burn X tokens every X days thereafter).
#2 | Caller Addresses can Burn Tokens without allowance
Comment: This function was designed by NXN and directly reflects our approach to tokenomics. This was done by design, as the adoption amplifier is supposed to end on a specific date, and thereafter, a portion of tokens will be burned on a successive schedule (i.e., burn X tokens every X days thereafter).
#1 | Logical Error
Comment: This is a difference of opinion for code design. While SOLIDProof’s feedback is helpful, we designed our code for this action to be done purposefully, and all areas in the code that call this method do in fact send the funds before calling.
#2 | Locked Tokens for callers
Comment: Per our source code, it is not possible to make two successive calls. The initializer modifier is on the initialize function (e.g., see code below for reference).
modifier initializer() {
bool isTopLevelCall = !_initializing;
require(
(isTopLevelCall && _initialized < 1) || (!AddressUpgradeable.isContract(address(this)) && _initialized == 1),
"Initializable: contract is already initialized"
);
_initialized = 1;
if (isTopLevelCall) {
_initializing = true;
}
_;
if (isTopLevelCall) {
_initializing = false;
emit Initialized(1);
}
}
#3 | Owner can drain tokens (Centralization Risk)
Comment: There will be no NXN tokens to drain. This ensures that if an end user erroneously sends funds to this contract then their assets will be protected and not lost because of end user error. This is a commercially reasonable risk management practice that is governed by the LLC’s operating agreement.
#1 | Missing Events
Comment: This code metric was intentional as not every state variable change needs to emit events. Our CTO rendered an opinion on this product development feature during development, and our LLC agreed unanimously to move forward given the nature of the NXN token.
Please see AA Documentation for more info:
Please see AA Documentation for more info:
Please see AA Documentation for more info:
Please see AA Documentation for more info: