Hello there Readers!
 
  If you’ve been keeping up, you’ll know that on October 13, 2023, we dived into an exciting audit process that lasted nearly a month. This wasn’t with just anyone - it was with CertiK, a company leading the charge in blockchain cybersecurity.
 
  So who are we? We’re the dedicated technical team behind Guardians of the Ball. We’re here today to break down the ins and outs of this audit - what exactly it involved, its significance, and importantly, how it’s helping us fortify our technology on the blockchain.
 
  The audit process brought to light 12 significant findings, thankfully, none of them were critical. That’s why we chose to put together this post - to present these results in a straightforward way that’s easy for you to digest. Of course, for our tech-savvy readers wanting all the gritty details, here’s the link to the full report: https://skynet.certik.com/projects/guardians-of-the-ball.
 
  Buckle up as we delve into how we’re implementing measures to not only protect ourselves but ensure that our users are also safeguarded. Let’s dive right in!
 
 

Overview

  Our first audit kick-started with a thorough review of the safety protocols and best practices of the GOBAL token’s source code, which was recently deployed on the Polygon PoS Mainnet. It wasn’t just the token we focused on; we also dove into the transitional ERC1155 token marketplace, the OTC (over-the-counter) controller, and the vesting of the GOBAL token.
 
  It’s paramount to note the intrinsic relationship all these smart contracts have with one particular element: The GOBAL token. This token acts as the seed token of our project, with its sole purpose being the purchase of NFT assets of Guardians of the Ball. Given this unique role of the token and its specific rules, we had to concoct a technology that would allow the immediate purchase and use of this token. However, we had to balance this with protecting the investment of our initial investors, ensuring the token doesn’t leak into the decentralized market before we’ve prepared everything to ensure its success.
 
  This is where our marketplace comes in, designed to allow purchases using tokens locked in the Vesting smart contract. Given the complex nature of this setup, we roped in the expertise of CertiK to ensure no security details slipped through the cracks. Their job was to ensure this ‘unlocking’ mechanism for buying NFTs doesn’t turn into a potential security loophole.
 
  Ready to understand more about how all these pieces fit together? Let’s keep going!
 
 

Understanding the OTC controller

 

https://polygonscan.com/address/0x0d8e798a258badff01db29a99dcb9f9c81baade4

At its core, OTC Controller is a contract that allows token sales. It’s specially designed for Over-The-Counter (OTC) deals using stablecoins, which are cryptocurrencies designed to maintain a stable value relative to a specific asset or a pool of assets. In this case, the selected and supported stablecoins are pegged to the US dollar.

The OTCController contract essentially creates a marketplace that enables the sale of GOBAL tokens to the public.

The token sale controlled by this contract is conducted in phases with specific open and close states. Plus, the contract ensures control measures, for instance:
 
 

• Token prices are managed by an assigned role (PRICE_MANAGER_ROLE).
• Stablecoins can be added or removed by the PRICE_MANAGER_ROLE.
• The token sale can be opened and closed by an assigned role (SALES_TRIGGERER_ROLE).

For a purchase to happen, a buyer calls the buyTokens function with the stablecoin they want to use and the amount they want to buy. Upon a successful purchase, the bought tokens are not instantly transferred to the buyer, rather they are moved to the ‘Vesting’ contract. This separate contract ensures that the tokens are distributed to the buyer after three (3) months of being bought.
 
  While much of this might sound complicated, at its core, this contract system serves a simple, essential function - controlling the sale of GOBAL tokens in a controlled, scheduled, and secure manner using different stablecoins.
 
 

Deciphering the Vesting smart contract

 

https://polygonscan.com/address/0xfd0ec420b3332950974d22668d7415f52afd1968

We are going to dissect a piece of code that is central to the operation of a digital asset transaction mechanism, similar to the concept of shares vesting in traditional corporate finance.

In simple terms, vesting is a process where the ownership of tokens is scheduled to be transferred over time, under certain agreed-upon conditions - a bit like an installment plan for buying a house.
 
  This smart contract code is necessary for our project, aiding them to manage the smooth release of locked GOBAL tokens over a fixed period of time. An ‘agenda’ or vesting schedule is set up for each beneficiary, defining when and how many tokens are to be released.
 
  The code works to ensure a fair and transparent distribution mechanism, minimizing the chance of market manipulation by preventing a large quantity of tokens hitting the market all at once. The withdraw and withdrawFrom functions provide the beneficiaries with the autonomy to claim tokens subject to vesting rules, such as the linkage with the Marketplace that we explained before, where our marketplace can use your locked tokens to allow you purchase an NFT.
 
  But, who is in charge of defining “who” can withdraw tokens from our vesting agendas? Let’s take a closer dive at the roles defined in this contract:
 
 

The withdrawFrom function

  TL;DR: The withdrawFrom function is one of the key functions within the Vesting Contract. This function essentially enables the withdrawal of vested tokens by an authorized operator (address with the AUTHORIZED_SPENDER_ROLE) on behalf of the actual beneficiary (agenda owner).
 
  We felt it necessary to place special emphasis on vesting, as many of you have asked, “Why haven’t my tokens reached my wallet after purchasing?” We believe this question merits a clear and comprehensive explanation.
 
  Let’s break down the withdrawFrom function (scroll down if you’re not interested!):
 
 

functionwithdrawFrom (
        addressagendaOwner,
        uint256amount
    ) externalonlyRole (AUTHORIZED_SPENDER_ROLE) {
        require ( amount > 0, "Vesting:amountiszero" );
        require ( agendaOwner != address(0) , "Vesting:agendaOwneristhezeroaddress" );

        addressoperator = _msgSender();

        require (
            _substractBalances(agendaOwner, amount, true) == amount,
            "Vesting:amountexceedsbalance"
        );

        IERC20(token).safeTransfer(operator, amount);
        emitWithdrawn(agendaOwner, operator, amount);
}

 
  Function Declaration: The function takes two parameters, agendaOwner (the actual beneficiary on whose behalf withdrawal is made) and amount (how many tokens to withdraw).
 
  onlyRole(AUTHORIZED_SPENDER_ROLE): This modifier ensures that the function can only be called by an address that has been assigned the AUTHORIZED_SPENDER_ROLE. This is a security measure that restricts access to the function.
 
  Sanity Checks: The function checks that the amount to be withdrawn must be greater than zero, and the agenda owner must not be the zero address.
 
  Subtracting Balances: The amount requested is then subtracted from the beneficiary’s account using the private _subtractBalances function. It checks whether enough balance exists in the beneficiary’s account since the tokens can only be withdrawn if they have already vested.
 
  Transfer of Tokens: If everything checks out, tokens equal to the amount requested are then transferred to the operator. It uses a secure transfer function (from the SafeERC20 library) to handle this with added error checks.
 
  Emitting an Event: Finally, an event Withdrawn is emitted, recording the details of the transaction for tracking on the blockchain. This includes the agenda owner, the operator and the amount of tokens withdrawn. You can connect your event tracking application to this event if you want to be notified about movements of this contract.
 
 

Roles and Permissions

  AUTHORIZER_ROLE :

Authorizers have the ability to delegate the AUTHORIZED_SPENDER_ROLE to various addresses. This means authorizers can control who has the ability to withdraw vested tokens on behalf of the agenda owner. The initial authorized address is our recently deployed and audited ERC1155 assets Marketplace which we’ll talk more about below.
 
  AUTHORIZED_SPENDER_ROLE :

If an address has been assigned the AUTHORIZED_SPENDER_ROLE, they are allowed to withdraw vested tokens on behalf of the agenda owner. The withdrawFrom function performs this operation.
 
  OTC_CONTROLLER_ROLE :

Over The Counter (OTC) controller is the central authority having the power to initiate new vesting schedules for beneficiaries. The createAgenda function is used by the OTC controller to set up these vesting schedules, specifying the beneficiary, and the amount and duration of the vesting period. This role cannot be modified once the sales are open.
 
 

Now, the Marketplace:

 

Current implementation, previous to the security audit: https://polygonscan.com/address/0x956a9c5b1eddd5b9e7da0d6f44e5698765b8e7df

 

Audited and deployed version: https://polygonscan.com/address/0x58870c040f3fb3d52245dd503cac7dd775f5a0d6

 
  Since our project involves intricate methods of selling NFTs, we made the decision to create our very own NFT marketplace. In this preliminary version of what will eventually become our full-blown marketplace, we’ve implemented just a handful of the planned functions with the primary aim of hastening our time to market. More exciting features are on their way, so stay engaged with us for more updates!
 
  By definition, GOB Market sells unique digital assets. These assets are the so-called ERC1155 tokens, which are one of the types of tokens used in the Ethereum blockchain ecosystem. It mints, or creates, new ERC1155 tokens when a purchase is made, and allows for a versatile range of payment methods through various ERC20 tokens
 
  Sound complex? Fear not! There are three methods provided for making a purchase:
 
 

• buyItem (): This method allows purchasing an item using any approved stablecoins like USDT or USDC.
• buyItemWithVesting (): Here, the payment process takes a bit of a turn. In this scenario, payment is carried out directly with those GOBAL tokens you have heard about, which are securely ‘locked in’ by the Vesting Smart Contract. The key advantage here? No need for prior release or waiting until the end of the Vesting Schedule. Convenient, isn’t it? Seamless transitions and user satisfaction are what we aim for!
• buyItemWithSeed (): This is where the seed truly shines. Buyers get the flexibility to pay using GOBAL tokens that have been freed up, be it from purchases made on the marketplace, from presales, or after the token has launched on DeXes. Flexibility is key here, so we make it easy for everyone to participate!

Notably, the GOBMarket contract also emits various events in response to actions such as a token being purchased, a new item being listed for sale, or the price of an item changing. Those “events” act as logs of the transactions happening on the blockchain, and are where we monitor for unforeseen events, security breaches or just normal transactions.
 
 

The Audit results

  Right off the bat, the audit showed no critical problems, which is excellent news! We maintained a close cooperation with CertiK to systematically manage and rectify all the identified concerns.
 
  Let’s break down what the audit unveiled:
 

• There were a total of ten findings.
   
• The breakdown of findings is as follows:
   
  • Acknowledged: 2
  • Mitigated: 1
  • Resolved: 7

We know the term “mitigated” might raise some eyebrows among our community members. Let’s put that concern to rest by explaining what “mitigated” entails and why our smart contract remains secured. You’ll notice in the below screenshot that the two Major Findings fall within the Acknowledged category; however, CertiK will soon update these two Major Findings to “mitigated”. As this change takes place, we’ll update this post accordingly so everyone stays informed.
 
 
 
 
 
  Grab some coffee, and let’s dive into these findings together.
 
 

Centralization Related Risks

  Privileged functions exist in most smart contracts, allowing only the contract’s owner or creator to execute the process. These functions generally steer project management. They include actions such as setting token levels and introducing novel project functionality. CertiK flags the presence of such privileged functions as a potential centralization risk. The project could end up on shaky grounds if a single account holds access to these privileged functions and somehow gets compromised.
 
  Past occurrences where projects like bZx, MGold, Dego Finance, and Vulcan Forged faced severe losses—millions of dollars in user funds—due to key compromises underscore this issue.
 
  In our case, CertiK pointed out that the management functions and updatability of our smart contract carry elements of this centralization risk. We responded swiftly and tackled this risk by transferring the high-level role to a smart-contract-based account, reinforcing our security practices.
 
  If you’ve been following along with the previous points, you’ll have noticed that we’ve outlined a variety of roles’ or permissions’ across all our contracts, with the exception of the GOBAL token.
 
  Seeing as these permission systems are crucial for enabling the functionality of our sales system, and they also provide us the flexibility to manoeuvre the addition of new features as we continue developing, it wasn’t possible for us to just get rid of the permission systems. Instead, we chose to implement a practice suggested by CertiK in order to add an extra layer of security to this process. Stick around as we delve into this solution further.
 
  CertiK had a fantastic recommendation for us. They proposed coupling a multisig wallet with a timelock contract that has a reasonable latency period. After considering our options, we decided to set up multiple timelocks and multisig wallets to operate each role within each contract, while also implementing time adjustments that align with each specific role. Want to understand more about these security measures? We’ll explain these in the sections below.
 
 

Multiple Signature Authentication (Multisig wallet or SAFE)

  In an effort to offer enhanced security, a multisig, or multiple signature authorization, is implemented. This valuable safeguard requires more than one account to approve a suggested transaction before it gets processed. This prevents a single compromised key from jeopardizing the project. The Guardians of the Ball team utilizes Gnosis Safe to apply multisig authorization for privileged functionalities. As a result, any modifications to our smart contract necessitate the verification from at least two out of three multisig members before any potential transaction gets processed.
 
 

Delayed Transaction Protocol (Timelock)

  Moreover, our project has a built-in delay period before a transaction is put into action. This deliberate pause ensures that any alterations in our contract are adequately broadcasted to the network ahead of the implementation. This level of transparency allows users and admins sufficient time to adapt and strategize as needed.
 
 

Per role deployed timelocks:

  We’ve strategically deployed a timelock for each critical role within our contracts. Additionally, we’ve designated multisig wallets for the execution permissions of these timelocks. As a result, a minimum of two signatures from the Multisig administrators is required to trigger an action tied to each role. These administrators are strategically located in various parts of the world, spread across different time zones, and are continually updated on each action our contracts take, thanks to the previously mentioned event monitoring system. And that’s how we ensure our operations are secure and monitored 24/7!
 
  AUTHORIZER_ROLE Timelock:

https://polygonscan.com/address/0x4373F57BcD54C43122336DFF74daA40A8A852ecA

Delay to execute: 48hs
 
 
  MANAGER_ROLE Timelock:

https://polygonscan.com/address/0xB83524292639a86e144E4bd1DFE8826dd0Cb80D6

Delay to execute: 7 hours
 
 
  DEFAULT_ADMIN_ROLE Timelock:

https://polygonscan.com/address/0xCc354eaBFe47dF21f5aF20F1167480E214a29823

Delay to execute: 48 hours
 
 
  SELLER_ROLE Timelock:

https://polygonscan.com/address/0xDEE6Acb1e866b41478350951d9921442c69C02A0

Delay to execute: 6hs
 
 
  PRICE_MANAGER_ROLE Timelock:

https://polygonscan.com/address/0xb75D3f6ccaac665f93069F81E0a10dF7Cc7E1834

Delay to execute: 24 hours
 
 
 

Proof of role delegations and renounce for OTC Controller and Vesting Smart Contracts:

 
 

Proof of Default Admin Role transferred to the designated timelock by the GOB Deployer 1 wallet:

https://polygonscan.com/tx/0x920e94dc029770092010b648818bcd6138175875f9056b8b72fce2a65d7a7c8b

 
 

Proof of Price Manager Role transferred to the designated timelock by the GOB Deployer 1 wallet:

https://polygonscan.com/tx/0x4a7325adada863af744cc433752b08561679edf861917b85a783d6ed758f4571

 
 

Proof of Sales Triggerer Role transferred to our Contract Manager Multisig (low risk role) by the GOB Deployer 1 wallet:

https://polygonscan.com/tx/0x385b87035025cfc0708feda3b7f9ef9aa6cfb8ce314b767d4923abea51f06136

 
 

Proof of Withdraw Role transferred to our Revenue Withdrawal Multisig (role protected by the Default Admin Timelock) by the GOB Deployer 1 wallet:

https://polygonscan.com/tx/0x3c77e746d09da3f95c28e3bcac308426ce7a66a99a064da345d07677ca9ffceb

 
 

Proof of renounce of the Default Admin Role by the GOB Deployer 1 wallet:

https://polygonscan.com/tx/0xdc11cef1f5198df11202d2743fd3503409853824d7bd62f09a2df6ea0b45f3fb

 
 

Proof of OpenSales function triggered, assigning the AUTHORIZER_ROLE to the designated timelock and opening the sales with a vesting time of 3 (three) months:

https://polygonscan.com/tx/0xdc4efd86a74dd0a8c08a7825deb4b4b7bad0082db8353ce3ed414edbcc363ff8

 
  Note: Given that this transaction was against a multisig wallet, you might want to take a look at the event logs to see what actually happened:

 
 
 

 
 
  Over there, the role identified by this code “0x 14dd32 7f3834be9d0f7cf44f6cf11c96ded83bd68d1a1b3926d35739e7 bb88d0” corresponds to the ” AUTHORIZER_ROLE” within the Vesting contract. Here, the term “Account” is referencing the account that currently holds the Role. Meanwhile, “Sender” pertains to the entity that initiated this execution. In this particular scenario, since we triggered the “Open Sales” function, it is the OTC Controller contract that communicates with the Vesting and assigns the role to our timelock. A pretty nifty process, isn’t it?
 
  This transaction has particular significance. It’s highlighted in the ” GCK-02 | The privileged role is allowed to withdraw tokens from the Vesting contract” as a potential risk, given it could theoretically allow any address to withdraw GOBAL funds from users without their consent. To mitigate this risk, we have implemented a 48-hour timelock. This safety measure comes into play before any execution of functions related to this role can occur. By introducing this pause, we ensure an added layer of security for our users’ transactions.
 
 

Proof of role delegations and renounce for GOB Market Contract:

 

Proof of Default Admin Role transferred to the designated timelock by the GOB Deployer 1 wallet:

https://polygonscan.com/tx/0xf3d8cbaf4ac4b20039872826b0d8c7d2168bcb36dea85df295faca17bfde0c77
 
 
 

Proof of Manager Role transferred to the designated timelock by the GOB Deployer 1 wallet:

https://polygonscan.com/tx/0x21ab0fb8a2c44b2bff89b27fcf0cae5641a24681117f677a7600b77ebe1191f9
 
 
 

Proof of Seller Role transferred to the designated timelock by the GOB Deployer 1 wallet:

https://polygonscan.com/tx/0xd6a871cc64123892411a8a0eb020d98cfab40fb94fd923756ae1920047af22bd
 
 
 

Proof of Withdraw Role transferred to our Revenue Withdrawal Multisig (role protected by the Default Admin Timelock) by the GOB Deployer 1 wallet:

https://polygonscan.com/tx/0xc631120fca8572c2be4f375612245740e21b6ba2f7fa3eff081d5e11a4048ddd
 
 
 

Proof of renounce of the Default Admin Role by the GOB Deployer 1 wallet:

https://polygonscan.com/tx/0xe18e5d86499913d69cce631157fb340764ef1161b494da7c377ac91f85934493
 
 
  Once all the necessary parameters have been set by the timelocks, this newly established marketplace contract is all set to take over the reins from the currently deployed and active GOBMarket. You can find the GOBMarket at https://polygonscan.com/address/0x956a9c5b1eddd5b9e7da0d6f44e5698765b8e7df. Changes are on the horizon - and it’s all part of our effort to continuously enhance our ecosystem!
 
 

Initial Token Distribution issue

  Here are the important links and details relevant to our token distribution and the signatories involved:
 
 

Known Signers:

 

Unset
matic:0xf6403bfAA76aC5abc055EB4184E5cdd4932b1B3E
matic:0x52145b7667b1740A6b58F7D02B5AC9E5b6e4F86c
matic:0x04B0994e016BAC502ef74B91858CA217A90F1a9d
matic:0xDd372f20C7854d6429D752c82eebBE21C224952c
matic:0x6FdE671aC8722A257ea67149f56c8ed9Ae69Cdd9

 

Link to the token distribution plan:

https://guardiansoftheball.com/GOB_Corporate_English.pdf
 
 

Deployed token information:

https://polygonscan.com/token/0x70F300FE3c8d62A169D3c1d656D284c3b4E00461

https://polygonscan.com/token/0x70F300FE3c8d62A169D3c1d656D284c3b4E00461#balances
 
 

Details of deployed multi sigs and signers holding the initial distribution:

 
 
 
 

Global Team, Advisors, and Early Investors

 

• Address: matic:0xa7D940212F49991Ff55D8C7F831060dD68507d02
• Tokens: 12.5M
• Signers:
  • matic:0xf6403bfAA76aC5abc055EB4184E5cdd4932b1B3E
  • matic:0x52145b7667b1740A6b58F7D02B5AC9E5b6e4F86c
  • matic:0x6FdE671aC8722A257ea67149f56c8ed9Ae69Cdd9
     
     

Turkish Team

 

• Address: matic:0x18fe1E3df9e7F656DFD99c2EAA249Aab4701DBb8
• Tokens: 9M
• Signers:
  • matic:0x4caE0631CB1f784aca6fc79C528c7cA7BeBAE4F2
  • matic:0xf6403bfAA76aC5abc055EB4184E5cdd4932b1B3E
  • matic:0x52145b7667b1740A6b58F7D02B5AC9E5b6e4F86c
  • matic:0x04B0994e016BAC502ef74B91858CA217A90F1a9d
     
     

Public Sales

 

• Address: matic:0x59abDe6b20F4Eb79e6f6f79F1864325f81B8C042
• Tokens: 45M
• Signers:
  • matic:0xf6403bfAA76aC5abc055EB4184E5cdd4932b1B3E
  • matic:0x52145b7667b1740A6b58F7D02B5AC9E5b6e4F86c
     
     

Liquidity and Staking

 

• Address: matic:0x221764d13bFa217d25959DDD7cC29ABD2Cf7420e
• Tokens: 15M
• Signers:
  • matic:0xf6403bfAA76aC5abc055EB4184E5cdd4932b1B3E
  • matic:0x52145b7667b1740A6b58F7D02B5AC9E5b6e4F86c
     
     

GOB Treasury

 

• Address: matic:0xB54B8691e96f8eFC6f8bC84002b5903635D12C87
• Tokens: 0
• Signers:
  • matic:0xf6403bfAA76aC5abc055EB4184E5cdd4932b1B3E
  • matic:0x52145b7667b1740A6b58F7D02B5AC9E5b6e4F86c
     
     

Marketing Community & Airdrop

 

• Address: matic:0xe3e413d9F1f53170667b77B9FC46290F3E0b64B6
• Tokens: 10M
• Signers:
  • matic:0xf6403bfAA76aC5abc055EB4184E5cdd4932b1B3E
  • matic:0x52145b7667b1740A6b58F7D02B5AC9E5b6e4F86c
  • matic:0x4caE0631CB1f784aca6fc79C528c7cA7BeBAE4F2
  • matic:0x04B0994e016BAC502ef74B91858CA217A90F1a9d
     
     

Seed Round

 

• Address: matic:0x5F1075308df8b3C45D6d76A61A9F3425e3e2DbE7
• Tokens: 5M
• Signers:
  • matic:0xf6403bfAA76aC5abc055EB4184E5cdd4932b1B3E
  • matic:0x52145b7667b1740A6b58F7D02B5AC9E5b6e4F86c
     
     

OTC For-Sale token holding multisig

 

• Address: matic:0xF447c79218F9fDB4aA42eB151c06eD59d8A04AD2
• This multisig is used to deposit the tokens for sale at the OTC contract. The wallet will approve the amount to be sold using the OTC contract, and with every sale, the OTC will take the tokens from this address.
• Signers:
  • matic:0x6FdE671aC8722A257ea67149f56c8ed9Ae69Cdd9
  • matic:0x52145b7667b1740A6b58F7D02B5AC9E5b6e4F86c
  • matic:0xf6403bfAA76aC5abc055EB4184E5cdd4932b1B3E

All these measures are integral to ensuring transparency, security, and proper distribution of tokens. So, to wrap up, the complexities of our token distribution process and multisig deployment have been designed with the utmost diligence to ensure transparency, efficiency and, above all, the security of our users.
 
  By taking these meticulous steps, we can guarantee that our users feel confident in their transactions and the overall security of our ecosystem. We take pride in keeping our users informed about every step of the process and hope this detailed breakdown serves to reinforce that commitment.
 
  Remember, you can always refer back to our website at https://guardiansoftheball.com for more details.
 
  Once again, thank you for trusting us and supporting our mission. Stay tuned for future updates, and as always, if you have any questions or concerns, don’t hesitate to reach out to us.
 
  Happy investing!