GFP-4: Blacklist Multichain Contract

Final GFPs
,
1

Abstract

$GUARD used Multichain protocol to bridge to Arbitrum and Polygon chain. This was to expand its outreach. Multichain was exploited however and many crypto assets using Multichain, including $GUARD have suffered. This proposal is to blacklist the Multichain contract, 0xCDd28a3033a6DC1472a1403156B426905bF127bA which will prevent it from transferring any of the GUARD tokens that it holds.

Proposal Category

Process

About the Team

The KS team consists of individuals with a diverse skill set.
Wizard, Owner and Founder of KnightSwap. Runs a Development Firm that has full capability for Web 2/Web 3 projects from beginning to end
Frumpo/Lord Frumpsalot, Operations, Risk Analysis, Project Manager for KS. A Guardian of TGA.
RealJayDee, Backend Support Manager
V, Community Manager
Arrow, Graphic Artist

Motivation

To avoid the impacts of the exploit, Blacklisting the Multichain Address from selling which contains large amounts of $GUARD, can minimize the exploit’s impact and provide an opportunity forward to preserve the value of $GUARD on Polygon and Arbitrum chains.

Benefit to Guardian Ecosystem

The main benefit in implementing this proposal is to begin creating a pathway to preserving the value of the $GUARD tokens on the Polygon and Arbitrum chains. This in turn should protect the holders of $GUARD on those chains.

Rationale

In order to keep the value of $GUARD and accounting accurate, Multichain’s address needs to be blacklisted as it was not intended for that address to have access to sell. Multichain was meant to be a locking mechanism to allow for $GUARD to move to other chains and unlock as they were bridged back. By Blacklisting, it gives an opportunity for a solution to preserve the value of $GUARD on the other chains. Otherwise, Multichain can sell at a moment’s notice and double counting would occur.

Specifications

GUARD smart contract on BNB chain
Multichain contract: 0xCDd28a3033a6DC1472a1403156B426905bF127bA

Steps to Implement

  1. Schedule Blacklist of Multichain contract 0xCDd28a3033a6DC1472a1403156B426905bF127bA
  2. Wait 3 days for Guard timelock
  3. Push transactions through

Timeline

5 days after passing proposal

Overall Cost

0

10 Likes
2

Sounds like a good idea

3

I think this should be implement asap, as it is it leaves Guard vulnerable and adds no benefit as it is.

4

Another solid idea, and agree this needs to be done asap to mitigate risk

5

Feel like this needs to implemented asap.

6

Agreed, a top priority!

7

Hey everyone. Thanks for all the participation!

This post has been archived per the Governance Framework. New replies are no longer allowed. We’re moving into the Draft Phase! Follow this post as new updates will be posted below!

9

Hey all,

The voting period has closed for this proposal and it has been accepted with a 100% pass rate. The proposal is now following the steps outlined in the implementation section.

The multichain contract has been submitted for blacklisting, but has not yet been blacklisted.

The Guard contract has a 3 day timelock. This waiting period serves as a crucial mechanism to ensure transparency, security, and protection against malicious activities or hasty decision-making.

We now wait for the 3 day timelock to take effect. Once the timelock time passes, the blacklist will go through, and an update will be posted in this thread.

10

Update:

We had multiple proposals wrap up at the same time. As such we’ve scheduled multiple modifications to the guard contract. After the 3 day wait, blacklisting of the multichain address didn’t go through for some reason. It might’ve been missed when we were scheduling in the other modifications.

To solve this we’ve re-input blacklisting the multichain contract into the time lock and we’re awaiting the passing of the 3 day wait time. Once passed the blacklist will go through, and an update will be posted here.

11

The multichain contract has been blacklisted per the community vote!