9

Looks like I found the answer I was looking for. cleos set account permission accountname active '{"threshold": 1, "keys": [{"key": "NEW_ACTIVE_PUBLIC_KEY", "weight": 1}]}' owner When having weight 1 you can simply use this alias instead: cleos set account permission accountname active NEW_ACTIVE_PUBLIC_KEY owner -p accountname@owner After, you can check ...


7

You can not forbid reading the data from a smart contracts table, because it is exposed by the RPC interface or CLI. What you can do to prevent understanding it by 3rd parties, is encrypt your data like @confused00 said. If you just want to limit access for adding, modyfing or deleting, you can use the scopes of the multi_index and the require_auth method, ...


7

How would users best ensure that the owner of the token didn't cheat and issue themselves additional tokens across a bunch of new accounts? This isn't really an issue, it's assumed by all involved in an airdrop that the creator isn't doing this out of benevolence. They need not cheat the system with a 'bunch of new accounts', that's a lot of unnecessary ...


6

To change the owner key, you can use this command: cleos set account permission account_name owner EOS_public_key_of_new_owner -p account_name@owner Multiple owners on an account is essentially a multi-sig account, it's possible and it's described here Accounts and Permissions As a concrete example, to configure two keys to the owner group of an account ...


6

Basically, pull the existing permission, change only what you need to change, then pass everything back to updateauth .. async function getNewPermissions(accountName) { const account = await eos.getAccount(accountName) const perms = JSON.parse(JSON.stringify(account.permissions)) return perms } const perms = await getNewPermissions(accountName) ...


6

There are basically two steps you need to do. First you create a new account permission and then you give it the authority to use voteproducer action on eosio contract. As a prerequisite for this instruction I expect that your account's active key is stored in a cleos wallet and the wallet is unlocked. 1. Create new account permission For the new ...


4

as explained in the message, you need to add 'eosio.code' permission to dice@active cleos set account permission dice active '{"threshold": 1,"keys": [{"key": "EOS7ijWCBmoXBi3CgtK7DJxentZZeTkeUnaSDvyro9dq7Sd1C3dC4","weight": 1}],"accounts": [{"permission":{"actor":"dice","permission":"eosio.code"},"weight":1}]}' owner -p dice


4

Bios sequence tutorial (Deprecated Wiki) explain these well - eosio.token, eosio.msig. The remaining accounts are described below. all RAM trading fees sent from user to eosio.ramfee all proceeds from selling RAM sent from eosio.ram all staked tokens sent to eosio.stake all unstaked tokens sent from eosio.stake all auction proceeds sent to eosio.names ...


3

Because _self is alice, your two push actions are not executed. If you set inc to alice@active, cleos push action alice increment '""' -p alice@inc will be executed.


3

The problem is that the first argument passed to the emplace() method in the multi-index structure is not an account you have permission to use as a payer. According to the docs, the parameters are as follows: Parameters payer - Account name of the payer for the Storage usage of the new object constructor - Lambda function that does an in-...


3

Because it is being paid for by _self, which is always allowed. In general, you can not charge other people RAM when doing transfers, only yourself. You can charge other people RAM when performing any other action.


3

The permission that you would set your account to would not be a key, but would instead be the account eosio.null@active. This is a special permission that can not be used by anybody ever (it has no associated keys and therefore can not be hacked). Note: This permission is implementation specific, so whilst it exists on the EOS mainnet, it could be that it ...


3

cleos set account permission MYACCOUNT active '{"threshold": 1, "keys":[], "accounts":[{"permission":{"actor":"eosio.null","permission":"active"},"permission":{"actor":"MYACCOUNT","permission":"eosio.code"},"weight":1}], "waits":[] }' owner -p MYACCOUNT cleos set account permission MYACCOUNT owner '{"threshold": 1, "keys":[], "accounts":[{"permission":{"...


2

As Jimmy mentioned contract callhello needs permission eosio.code. To solve that you can run the cleos set account permission command: cleos set account permission callhello active \ '{"threshold": 1, "keys": [{ "key": "'${EOS_KEY}'", "weight": 1 }], "accounts": [{ "permission": {"actor": "callhello", "permission": "eosio....


2

In https://github.com/LimeChain/eoslime (uses eosjs behind the scene) there is a addPermission method, which you can use in order to accomplish your aim. It will add a permission for example eosio.code to your active authority.


2

eosio.recovery contract provide user to recover their account if their owner keys are stolen. For this purpose you need to set a permission ‘recover’ and provide a trusted account for recovery. Now let any one stolen your account keys. If you are an active member of EOS then you must use your account at least one time in a month. So if your keys ...


2

You need to add an authority to eosconfig, e.g.: eos = Eos({ keyProvider, authorization: EOSIO_ACCOUNT_NAME + '@active', });


2

Testing with v1.5.1, adding a new permission to an account (set account): Corresponding contract action: updateauth RAM: 32 bytes NET: 185 bytes CPU: 320 time for set action permission: Corresponding contract action: linkauth RAM: 144 bytes NET: 127 bytes CPU: 664 time Important to know: Ram usage is about using the storage, that means if update a ...


2

You can go to eostoolkit to do that. Enter the public key you'd like to keep, set owner as parent, your account name, then keep the threshold at 1 and sign the transaction. Remove a permission Specify the Permission and Parent, and leave a single Authority row empty with the default Weight of 1. Link: https://eostoolkit.io/account/advanced


2

This can be done by deferred transaction. It's very normal use case, for example, unstaking EOS from CPU and NET bandwidth triggers refund action which is executed in 72 hours. In your case, add the action which handles tallying and adjusting balances and push it with time delay (transaction contains field named by delay_sec) so as to execute transaction ...


2

The ONLYBILL1ST proposal has now been approved by 15 Block producers. I have tested and OnlyBillFirstAuthorizer is working now. I'm using eos-sharp. But it's very similar to eos-js. It's very simple. Just add the account you want to bill for the transaction first in the 'authorization'-part. //Add the private keys List<string> ...


1

I had the same error shown when performing an action on a test network, and I solved it updating my permissions launching this single cmd: cleos.sh set account permission <your-account> active '{"threshold":1,"keys": [{"key":"<your-public-key>","weight":1}],"accounts": [{"permission":{"actor":"<your-account>","permission":"eosio.code"},"...


1

By default all EOS accounts come with two permissions owner and active which can share the same keypair or be seperate. From what you've described you can simple just make the owner key a cold storage keypair and use the active key for transferring Airdrops as they typically just look for the @active permission when executing transfer functions. However, ...


1

One reason this can happen is if you didn't import your active key into your cleos wallet. Remember that signing keys from your wallet is done completely separate from the contract. To check if your key is there cleos wallet unlock --password PW************ cleos wallet keys Then to import your key cleos wallet import 5XYZ***********


1

This article goes into detail. https://developers.eos.io/eosio-nodeos/docs/bios-boot-sequence Here are some that I found: The eosio.token contract. This contract enables you to create, issue, transfer, and get information about tokens. The msig contract enables and simplifies defining and managing permission levels and performing multi-...


1

This issue does not relate to account permissions. Permission errors would typically look like this: Error Details: transaction declares authority '{"actor":"player","permission":"active"}', but does not have signatures for it. This error main.cpp:2350 main ] Failed with error: Assert Exception (10) condition: assertion failed: unable to find key indicates ...


1

Yes, it is possible. The action is in native.hpp in the eosio.system contract from eosio.cdt repository: [[eosio::action]] void updateauth( ignore<name> account, ignore<name> permission, ignore<name> parent, ignore<authority> auth ) {} You would use ...


1

When a contract sends an inline action, it cannot send with the permission level passed by the caller; it sends with a special eosio.code permission name. In your example, makepokemon can only use makepokemon@eosio.code and not user@active, so user has to explictily give makepokemon permission to transfer tokens if they want to.


1

So the user pushes the action with -p user@active, and now the contract can "steal" those tokens unrightfully? Or am I missing something? No, that can not steal the tokens because you check the authenticity inside the action itself. Then, it does not matter what permission are you sending via command line. Your makepokemon action should check the ...


1

You can retrieve information about an account that is involved in a contract by querying the contract's table with the get table command. You can also use get account which reveals the associated permission levels and public keys. Example from docs: $ cleos get account eosio --json { "account_name": "eosio", "privileged": true, "last_code_update": ...


Only top voted, non community-wiki answers of a minimum length are eligible