Is there a way to unstake/undelegate using Briskett? #17

New issue

Open

opened 2023-07-05 20:32:49 +00:00 by adept · 4 comments

adept commented

2023-07-05 20:32:49 +00:00

(Migrated from github.com)

Hi!

Is there a way to unstake/undelegate using Briskett?

If I am reading tezos API right, it could be as simple as not setting the delegate here: github.com/lousando/briskett@5b778db9dd/pages/delegate.vue (L211)

Would you consider implementing this?

Hi! Is there a way to unstake/undelegate using Briskett? If I am reading tezos API right, it could be as simple as not setting the delegate here: https://github.com/lousando/briskett/blob/5b778db9dd04c716d7fcd66d5a9e5189275afe7d/pages/delegate.vue#L211 Would you consider implementing this?

lousando commented

2023-07-06 02:10:24 +00:00

(Migrated from github.com)

Correct, there is currently no way to undelegate. What would be the use case though? From my understanding it's better for people with a wallet to delegate to prevent risk of deflation.

adept commented

2023-07-06 21:12:07 +00:00

(Migrated from github.com)

Scenario in which I would've wanted to undelegate:

As you know, you can't drain account completely. So even if you moved all funds to a different account, there would be a small residual amount left. Unless undelegated, this amount would keep generating very small staking "revenue"

Depending on the regulatory regime, this staking revenue might need to be tracked for tax/reporting purposes. The amount of effort required to do that would greatly outweigh any financial benefits one might gain from staking this residual amount - it would be best to undelegate it and leave it be.

Scenario in which I would've wanted to undelegate: As you know, you can't drain account completely. So even if you moved all funds to a different account, there would be a small residual amount left. Unless undelegated, this amount would keep generating very small staking "revenue" Depending on the regulatory regime, this staking revenue might need to be tracked for tax/reporting purposes. The amount of effort required to do that would greatly outweigh any financial benefits one might gain from staking this residual amount - it would be best to undelegate it and leave it be.

👍 1

lousando commented

2023-07-06 21:25:53 +00:00

(Migrated from github.com)

Depending on the regulatory regime, this staking revenue might need to be tracked for tax/reporting purposes. The amount of effort required to do that would greatly outweigh any financial benefits one might gain from staking this residual amount - it would be best to undelegate it and leave it be.

Fair point. I'll add it to the roadmap.

> Depending on the regulatory regime, this staking revenue might need to be tracked for tax/reporting purposes. The amount of effort required to do that would greatly outweigh any financial benefits one might gain from staking this residual amount - it would be best to undelegate it and leave it be. Fair point. I'll add it to the roadmap.

lousando commented

2023-08-29 05:47:44 +00:00

(Migrated from github.com)

Adding this additional info in here so it doesn't get lost.

Essentially the developer would have to sign a transaction against a KT1 (smart contract) address to cancel the delegation.

Not sure which/where the KT1 address lives yet, but I imagine the owner would have to be either the baker or the wallet address.

Another thing to note for the future:

During the migration from proto004 to proto005, all KT1 addresses that migrated got a contract called [manager.tz](https://gitlab.com/nomadic-labs/mi-cho-coq/blob/master/src/contracts/manager.tz). As a result, there are no longer any "script-less" KT1 addresses in Tezos.

A call to the KT1's smart contract's do method must be made to delegate to a KT1 address with the new manager.tz contract. The do method takes a lambda function, and it is this lambda function that causes changes to occur in the KT1 address.

Source: https://tezostaquito.io#set_delegate

Adding this additional info in here so it doesn't get lost. Essentially the developer would have to [sign a transaction against a KT1](https://docs.trezor.io/trezor-suite/packages/connect/methods/tezosSignTransaction.html) (smart contract) address to cancel the delegation. Not sure which/where the KT1 address lives yet, but I imagine the owner would have to be either the baker or the wallet address. Another thing to note for the future: ``` During the migration from proto004 to proto005, all KT1 addresses that migrated got a contract called [manager.tz](https://gitlab.com/nomadic-labs/mi-cho-coq/blob/master/src/contracts/manager.tz). As a result, there are no longer any "script-less" KT1 addresses in Tezos. A call to the KT1's smart contract's do method must be made to delegate to a KT1 address with the new manager.tz contract. The do method takes a lambda function, and it is this lambda function that causes changes to occur in the KT1 address. ``` Source: [https://tezostaquito.io#set_delegate](https://tezostaquito.io/docs/set_delegate/#delegation-involving-originated-addresses-kt1-prefix)