Audit & Remarks
SOLIDProof Audit Security Assessment - NXN Network dated 16 April 2024
Post-Audit Report - NXN Feedback updated 20 April 2024
Overall Security (p. 11-12)
– 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.
Ownership Privileges (p.13-18)
– 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.
Please see AA Documentation for more info: Adoption Amplifier | NXN Documentation
– 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.
Please see AA Documentation for more info: Adoption Amplifier | NXN Documentation
– 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.
High issues (p. 24)
#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).
Please see AA Documentation for more info: Adoption Amplifier | NXN Documentation
#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).
Please see AA Documentation for more info: Adoption Amplifier | NXN Documentation
Medium issues (p. 25)
#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.
Low issues (p. 27)
#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.
Last updated