NEM2 : Burn account using Account Operation Restriction

Technical Discussion
#1

I would like to implement ‘proof of burn’, which a withdrawal token from the nem catapult network is transfer to a restricted account.

Now I am thinking of using Account Operation Restriction method to do it. I added operation type 0x4154 to the account, to prevent any transfer transaction. Is it safe?

My question is can I sign the AccountRestrictionTransaction with another account private key?

1 Like
#2

Hey there,

you can use account restrictions yes with following restriction type: https://github.com/nemtech/nem2-sdk-typescript-javascript/blob/master/src/model/account/RestrictionType.ts#L33

Then for the entity 0x4154 which is transfer transaction. :+1:

@dgarcia360, is there any pre-requisites for this transaction to be accepted ?

1 Like
#3

Hi @Kelvin,

Now I am thinking of using Account Operation Restriction method to do it. I added operation type 0x4154 to the account, to prevent any transfer transaction. Is it safe?

It is not safe for proof of burn, as you still own the private key of the account. Having the private key allows you to remove restriction after announcing another AccountOperationRestrictionTransaction.

My question is can I sign the AccountRestrictionTransaction with another account private key?

An account can propose to add an account restriction to another target account using aggregate transactions. However, the account will have to accept the restriction, by cosigning the aggregate. This would not be usable for your use case, as the target account could remove the restriction at a later point.

The following alternatives might help you with your use case, keeping into account that you will access to the mosaics you send to these accounts:

a) Generate the public key for an account without knowing its private key. Then, send mosaics to this generated address.

b) Send mosaics to the account that signed the first network block (nemesis). This account is not allowed to send transactions in the future, as the protocol raises Failure_Core_Nemesis_Account_Signed_After_Nemesis_Block validation error.

Would like to hear from others: what do you think about the alternatives proposed, and could you think of another possible solution for burning tokens using NEM built-in features?

3 Likes
#4

Hi @dgarcia360, Where to get the nemesis account that signed the first block?

Is it the signer from the http://localhost:3000/block/1?

Update:

Yes signer of the first block at http://localhost:3000/block/1 is the nemesis_signer.

2 Likes