🛡️$WANDER Token Security

A layer of security has been implemented through simply inheriting OpenZeppelin’s ERC20PresetMinterPauserUpgradable’s functionalities. As how the nature of $WANDER token should be, regular users are given the access to execute a transfer of its own $WANDER token to another address, burning of own $WANDER token can be conducted by regular users, and any user (Address A) that are given the approval to transfer/burn on behalf of another user (Address B) can transfer/burn a certain allocated amount of the tokens owned by the user (Address B) that gave the approval (This is done by executing the approval function in advanced, which exist in OpenZeppelin’s standard ERC20Upgradable template).

However, some functionalities are only to be granted to Wanderverse's administrator, these include the minting of tokens, the pausing of smart contract and the unpausing of smart contract. These functions are restricted by adding the appropriate modifier, only allows a certain address to call upon the function. The address that deploys the smart contract is automatically granted with the admin role and the deployment of $WANDER token’s smart contract into the Polygon mainnet means that the address that holds the admin role can’t be tampered by hackers.

Despite the high level of complexity for malicious actors to hack any blockchain, we as a company take security very seriously. As such, we have implemented an additional layer of security to reduce the risk of any malicious actors to take full control of $WANDER token’s operations.

$WANDER token incorporates a multi-signature architectural design in its smart contract, in order to diminish a “one-point of failure” nature in a ERC20 smart contract template by restricting the ease to execute functions that proves to cause detrimental effects when it falls into the wrong hands. The execution of the mentioned security layer requires the involvement of multiple wallet accounts. Aside from the deployer of the contract, we set up 3 other wallet accounts generated from its own different seed phrases, which will act as administrators of the smart contract. Administrators plays an important role, as they would cast a confirmation vote for the execution of any critical functions. To execute a critical function, the caller of the function needs to send a special request to the smart contract and would need the approval of at least 3 confirmation votes (the vote owned by the function’s caller counts) before being able to execute the operation. This is done to ensure that in the circumstance that a malicious actor manages to get a hand on the involving accounts, the actor would still need the access to the other administrator accounts before being able to do his/her mischievous conducts.

The crucial functions that would be restricted by the smart contract’s architectural design is given by the following:

  • The addition and removal of an account’s administrator rights.

  • A transfer of equal or more than 1,000,000 (1 million) $WANDER tokens coming out from the administrators' wallet (which can be used as an administrator pool).

  • The minting of $WANDER tokens.

  • Pausing or un-pausing the state of the smart contract.

  • Clearing up the request pool that holds upon the requests to execute the crucial functions mentioned above.

Last updated