Change compromised address' vesting

[sem]

Hello everyone,

The address of a community member has been compromised, and he asked me to prepare a vote to revoke their TEC vesting and assign it to another address. To do so, the whole community has to vote through a Tao Voting in the garden here.

The vote will grant permission to revoke vestings to Tao Voting and then use Tao Voting to revoke the vesting for 0x5c44E8982fa3C3239C6E3C5be2cc6663c7C9387E, returning the locked tokens to the token manager address. In a subsequent vote, we can assign those tokens again to a new address provided by this member, respecting the vesting schedule of the rest of the hatchers.

I know that Tao votes should take more time and go through the advice process, but it looked to me that the sooner this vote passes, the fewer TEC tokens the attacker will have. Of course, if somebody thinks it is not enough justified reason, they can challenge the proposal, and I will gladly retire it and go through the standard procedure. Still, I think it should be fine to make an exception in a case where there is a compromised address and funds at risk.

EVMcrispr script used

load aragonos as dao
dao:connect 0x1fc7e8d8e4bbbef77a4d035aec189373b52125a8 disputable-voting.open --context "Revoke hacked account vesting" (
  grant disputable-voting.open wrappable-hooked-token-manager.open REVOKE_VESTINGS_ROLE disputable-voting.open
  exec wrappable-hooked-token-manager.open revokeVesting 0x5c44E8982fa3C3239C6E3C5be2cc6663c7C9387E 0
)

[natesuits]

Hey Sem!

I understand that this is important, but we really need to go through the advice process on this one. If you are unable to remove the proposal, I will challenge it in Celeste.

I mean, in all honesty it does appear that the wallet has been compromised as of 23 days ago. The exiting of positions, the use of relays, etc.

However, I find it strange that the compromised wallet is the only one voting in favor of this proposal in the Gardens. As you can see here:

Gnosis Transaction Hash (Txhash) Details | GnosisScan

In order to assist in facilitating the advice process, perhaps you can explain the following:

1. Once the Revoke Vesting is removed from the compromised wallet and all unvested tokens are sent to the Token Manager, what happens next? Is there anyway for the controller of the compromised wallet to front-run a transaction?

2. The consequences of subjecting the role of Revoke Vesting to Disputable Voting is not clear to the community. Perhaps this is something you can speak on!

Thanks!

An additional note: I am currently at this time unable to challenge the proposal. Failed transaction on both creating a proposal and challenging a proposal. Perhaps its just on my end, but worthy of note.

[sem]

It’s okay. I challenged my proposal to cancel it, leaving time for the advice process.

We will make a new proposal when we finish the advice process.

I will answer your concerns, @natesuits:

However, I find it strange that the compromised wallet is the only one voting in favor of this proposal in the Gardens.

It is the confirmation that the address that receives the vesting desires to revoke it. @Tamara and I have been talking with the address owner through telegram, and we will provide more proof when we do the second vote to reassign the vested tokens to a new address.

Once the Revoke Vesting is removed from the compromised wallet and all unvested tokens are sent to the Token Manager, what happens next? Is there anyway for the controller of the compromised wallet to front-run a transaction?

Once we know how many tokens are in the Token Manager (which depends on the time when the first vote is executed), we will create a second vote that will vest the tokens for a new address, such as:

load aragonos as dao
set $newAddr 0x...
dao:connect 0x1fc7e8d8e4bbbef77a4d035aec189373b52125a8 disputable-voting.open --context "Reassign hacked account vesting" (
  grant disputable-voting.open wrappable-hooked-token-manager.open ASSIGN_ROLE disputable-voting.open
  exec wrappable-hooked-token-manager.open assignVested $newAddr @token.balance(TEC,wrappable-hooked-token-manager.open) @date(now) @date(now) 1690261681 true
)

As you can see, Tao Voting (disputable voting) also needs the ASSIGN_ROLE to perform this action. However, it does not affect the DAO permissions per se since Tao Voting always has had permission to manage app permissions, and you still will need a vote to assign tokens from now on.

The consequences of subjecting the role of Revoke Vesting to Disputable Voting is unclear to the community. Perhaps this is something you can speak on!

As in the previous answer, since Tao Voting can manage the DAO permissions, granting new permissions to Tao Voting has virtually no effect on what it can do. Tao Voting enables the god mode of the DAO, which is why the whole community has to vote. Adding this permission to Tao Voting is necessary for the vote to run, but since it’s Tao Voting who grants it to itself, we still need a tao vote to revoke vestings.

It would be different if we granted these permissions to an address different from Tao Voting. Then it would require an explanation of why we do that.

[Joel]

Hi everyone. I’m the affected user. Wanted to highlight a few key points.

• As mentioned my account got compromized, I still have the private key, but the hacker does as well
• My primary motive is to get the tokens burned so that the hacker can’t sell the tokens on the bonding curve once they vest (burning value for the entire community)
• The hacker has already sold some TEC and will likely do so again once the tokens vest
• The total value held by this account currently is 8,009.844 TEC

If the community is willing then I’d ofc love to get the burned tokens into a secure account I control, but just making sure that the tokens don’t end up in the hackers control is a huge win imo.

Happy to provide any sort of proof if anyone desires to see them!

[ZeptimusQ]

The is already a vote going, need 10% quorum to pass it. Vote here: Gardens ( This vote is to unvest and send the tokens to the Token manager which is in control of the DAO )

[ZeptimusQ]

load aragonos as dao

dao:connect 0x1fc7e8d8e4bbbef77a4d035aec189373b52125a8 disputable-voting.open --context "https://forum.tecommons.org/t/change-compromised-address-vesting/1132" (
  grant disputable-voting.open wrappable-hooked-token-manager.open ASSIGN_ROLE disputable-voting.open
  exec wrappable-hooked-token-manager.open assignVested <receiver> wrappable-hooked-token-manager.open::token()::balanceOf(token-manager) @date(now) @date(now) 1690261681 true
)

We are missing @Joel address to add on the <receiver>. Hatcher outreach crew will reach him and like Joel’s response to confirm the address posted is correct

[ZeptimusQ]

load aragonos as dao

dao:connect 0x1fc7e8d8e4bbbef77a4d035aec189373b52125a8 disputable-voting.open --context "https://forum.tecommons.org/t/change-compromised-address-vesting/1132" (
  set $tm wrappable-hooked-token-manager.open
  grant disputable-voting.open $tm ASSIGN_ROLE disputable-voting.open
  exec $tm assignVested <receiver> $tm::token()::balanceOf($tm) @date(now) @date(now) 1690261681 true
)

@sem was helping me with EVMcrispr and he said the code I shared above have a mistake and facilitate this one for the second vote, Praise!

[Joel]

Hi @ZeptimusQ Sorry for my delayed response.

My address is 0xAEE23b2c38732a191aa5CE33D2db5efCf51868Ae. Let me know if you need something else to verify!

[sem]

The vote for resigning the tokens to the new address breaks the frontend due to a radspec description error. We upgraded the app with the fix, but it looks it’s cached somewhere I am not identifying.

So it may take a bit longer to vote for the return of the tokens, @Joel, but we are on it.

[sem]

The vote has been fixed thanks to @gabi for fixing the connector that was retrieving the bad description.

Unfortunately it appears now as no description, so a further explanation is required to show the vote is doing what this forum post is saying it is doing.

The evmcrispr code used to create the vote is:

load aragonos as dao
dao:connect 0x1fc7e8d8e4bbbef77a4d035aec189373b52125a8 disputable-voting.open --context "https://forum.tecommons.org/t/change-compromised-address-vesting/1132" (
  set $tm wrappable-hooked-token-manager.open
  grant disputable-voting.open $tm ASSIGN_ROLE disputable-voting.open
  set $token.tokenlist https://tokens.honeyswap.org/
  exec $tm assignVested 0xAEE23b2c38732a191aa5CE33D2db5efCf51868Ae @token.balance(TEC,$tm) @date(now) @date(now) 1690261681 true
)

Which generates the following data if you plug it into EVMcrispr:

Data generated:

0x5e754d55000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000001c0000000000000000000000000000000000000000000000000000000000000015c00000001ded166f3222bef8621b6cbce21b6ef95bed16442000000640a8ed3db0000000000000000000000009126f1e7e3ab7414b921fb09ac2c2eb9e8e27061000000000000000000000000080c696b7bd6d830bf5092fe7dfcb72b42bdd8b7f5a08927c847d7a29dc35e105208dbde5ce951392105d712761cc5d17440e2ff080c696b7bd6d830bf5092fe7dfcb72b42bdd8b7000000c421cb18cd000000000000000000000000aee23b2c38732a191aa5ce33d2db5efcf51868ae000000000000000000000000000000000000000000000190ed18f948fb7ad68300000000000000000000000000000000000000000000000000000000634dfd1800000000000000000000000000000000000000000000000000000000634dfd180000000000000000000000000000000000000000000000000000000064bf58b1000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000000000000004568747470733a2f2f666f72756d2e7465636f6d6d6f6e732e6f72672f742f6368616e67652d636f6d70726f6d697365642d616464726573732d76657374696e672f31313332000000000000000000000000000000000000000000000000000000

Which is the same generated in the vote #22 creation transaction (with some minor encoding differences that do not change the result of the vote).

So the vote is safe to execute, and will return @Joel the tokens with the same vesting schedule as any other hatcher.

[sem]

The message is now fixed thanks to @gabi.