Resources

Glossary

Steem Developer Portal

An operation on Steem is a way of expressing intention on the blockchain.
They are also known as Broadcast Operations. They have types, like vote
or comment. They pass parameters like author and permlink, depending
on what their purpose is.

Operations are grouped into transactions and passed as parameters to
methods like network_broadcast_api.broadcast_transaction, in
the operations array. Transactions must be signed in order for the
blockchain to accept them. Here is an example of a transaction that
contains one operation (shown without signatures).

vote

This operation is used to cast a vote on a post/comment. The primary
purpose of voting is to express Proof-of-Brain about content to the
blockchain. When a vote is cast, the content is considered in the
consensus rules involving author and curation rewards.

An upvote can be cast from the point in time that the content is created
up to 6.5 days. The remaining 12 hours are locked out of upvotes at
which time only downvotes may be cast.

A secondary aspect to voting involves reputation, which is not part of
consensus.

Reputation Rules:

Must have non-negative reputation to effect another user’s reputation.

If you are down voting another user, you must have more reputation than them to impact their reputation.

transfer

Transfers asset from one account to another. The memo is plain-text,
any encryption on the memo is up to a higher level protocol.

Notes:

Transferring of Steem Power (VESTS) is not allowed.

Cannot transfer a negative amount (aka: stealing).

Memo must be less than 2048 bytes.

Memo must be UTF-8.

Roles: active owner

Parameters: from to amount memo

Example Op:

["transfer",{"from":"steemit","to":"alice","amount":{"amount":"10","precision":3,"nai":"@@000000021"},"memo":"Thanks for all the fish."}]

transfer_to_vesting

This operation converts STEEM into VFS (Vesting Fund Shares) at the
current exchange rate. With this operation it is possible to give
another account vesting shares so that faucets can pre-fund new accounts
with vesting shares.

report_over_production

Disabled in HF4

This operation is used to report a miner who signs two blocks
at the same time. To be valid, the violation must be reported within
STEEM_MAX_WITNESSES blocks of the head block (1 round) and the
producer must be in the ACTIVE witness set.

Users not in the ACTIVE witness set should not have to worry about their
key getting compromised and being used to produced multiple blocks so
the attacker can report it and steel their vesting steem.

The result of the operation is to transfer the full VESTING STEEM balance
of the block producer to the reporter.

Roles: active owner

Parameters: reporter first_block second_block

witness_update

Users who wish to become a witness must pay a fee acceptable to
the current witnesses to apply for the position and allow voting
to begin.

If the owner isn’t a witness they will become a witness. Witnesses
are charged a fee equal to 1 weeks worth of witness pay which in
turn is derived from the current share supply. The fee is
only applied if the owner is not already a witness.

If the block_signing_key is null then the witness is removed from
contention. The network will pick the top 21 witnesses for
producing blocks.

Notes:

The fee paid to register a new witness, should be 10x current
block production pay.

delete_comment

Roles: posting active owner

Parameters: author permlink

Example Op:

custom_json

Serves the same purpose as custom but also supports required posting
authorities. Unlike custom, this operation is designed to be human
readable/developer friendly.

follow

As of HF9, the follow plugin will track follow/unfollow/ignore events.

reblog

As of HF14, allows users to share blogs they find with those who follow
them. This change implemented entirely outside the blockchain consensus
which means that reblogging does not create a new post, it merely shares
an existing post with people who follow you.

witness

As of HF18, the witness plugin has a custom operation called
enable_content_editing that allows a user to signal they want to edit
their content. By consensus, content is editable indefinitely, but is
soft forked to be frozen after payout. This operation requires an
active key and is designed to prevent vandalism if a posting key is
compromised. #1017

comment_options

Authors of posts may not want all of the benefits that come from creating a post. This
operation allows authors to update properties associated with their post.

Typically, these options will accompany a comment operation in the same transaction.

As of HF17, content can specify beneficiaries to receive a part of
their author rewards. The beneficiaries are specified in the extension
field of the comment_options_operation and is a sorted vector (by
account name) of account name, weight pairs. The beneficiaries can only
be specified once and must be specified before any votes are cast on the
comment. Most apps are already adding a comment_options in the
transaction that creates the comment, so this should not be much of a
challenge to add to existing apps.

Notes:

The max_accepted_payout may be decreased, but never increased.

The percent_steem_dollars may be decreased, but never increased.

Part of comment_option validation process, to be called when
allowed_vote_assets object has been added as comment option extension are:

set_withdraw_vesting_route

Allows an account to setup a vesting withdraw but with the additional
request for the funds to be transferred directly to another account’s
balance rather than the withdrawing account. In addition, those funds
can be immediately vested again, circumventing the conversion from
vests to steem and back, guaranteeing they maintain their value.

Notes:

Percent must be valid steem percent.

Roles: active owner

Parameters: from_account to_account percent auto_vest

Example Op:

limit_order_create2

This operation is identical to limit_order_create except it serializes
the price rather than calculating it from other fields. The maximum expiration time for any limit order is 28 days from head_block_time().

challenge_authority

Disabled in HF14.

Roles: posting active owner

Parameters: challenger challenged require_owner

prove_authority

Roles: active owner

Parameters: challenged require_owner

Since: HF11

request_account_recovery

All account recovery requests come from a listed recovery account. This
is secure based on the assumption that only a trusted account should be
a recovery account. It is the responsibility of the recovery account to
verify the identity of the account holder of the account to recover by
whichever means they have agreed upon. The blockchain assumes identity
has been verified when this operation is broadcast.

This operation creates an account recovery request which the account to
recover has 24 hours to respond to before the request expires and is
invalidated.

There can only be one active recovery request per account at any one time.
Pushing this operation for an account to recover when it already has
an active request will either update the request to a new new owner authority
and extend the request expiration to 24 hours from the current head block
time or it will delete the request. To cancel a request, simply set the
weight threshold of the new owner authority to 0, making it an open authority.

Additionally, the new owner authority must be satisfiable. In other words,
the sum of the key weights must be greater than or equal to the weight
threshold.

This operation only needs to be signed by the the recovery account.
The account to recover confirms its identity to the blockchain in
the recover account operation.

Notes:

recovery_account: The recovery account is listed as the recovery account
on the account to recover.

account_to_recover: The account to recover. This is likely due to a
compromised owner authority.

new_owner_authority: The new owner authority the account to recover
wishes to have. This is secret known by the account to recover and
will be confirmed in a recover_account.

change_recovery_account

Each account lists another account as their recovery account.
The recovery account has the ability to create account_recovery_requests
for the account to recover. An account can change their recovery account
at any time with a 30 day delay. This delay is to prevent
an attacker from changing the recovery account to a malicious account
during an attack. These 30 days match the 30 days that an
owner authority is valid for recovery purposes.

On account creation the recovery account is set either to the creator of
the account (The account that pays the creation fee and is a signer on the transaction)
or to the empty string if the account was mined. An account with no recovery
has the top voted witness as a recovery account, at the time the recover
request is created. Note: This does mean the effective recovery account
of an account with no listed recovery account can change at any time as
witness vote weights. The top voted witness is explicitly the most trusted
witness according to stake.

Roles: owner

Parameters: account_to_recover new_recovery_account extensions

Example Op:

escrow_transfer

The purpose of this operation is to enable someone to send money
contingently to another individual. The funds leave the from account
and go into a temporary balance where they are held until from
releases it to to or to refunds it to from.

In the event of a dispute the agent can divide the funds between the
to/from account. Disputes can be raised any time before or on the
dispute deadline time, after the escrow has been approved by all
parties.

This operation only creates a proposed escrow transfer. Both the agent
and to must agree to the terms of the arrangement by approving the
escrow.

The escrow agent is paid the fee on approval of all parties. It is up to
the escrow agent to determine the fee.

Escrow transactions are uniquely identified by from and escrow_id,
the escrow_id is defined by the sender.

escrow_approve

The agent and to accounts must approve an escrow transaction for it to
be valid on the blockchain. Once a party approves the escrow, they
cannot revoke their approval. Subsequent escrow approve operations,
regardless of the approval, will be rejected.

Roles: active owner

Parameters: from to agent who escrow_id approve

Example Op:

transfer_to_savings

For time locked savings accounts. A user can place Steem and Steem
Dollars into time locked savings balances. Funds can be withdrawn from
these balances after a three day delay. The point of this addition is to
mitigate loss from hacked and compromised account. The max a user can
lose instantaneously is the sum of what the hold in liquid balances.
Assuming an account can be recovered quickly, loss in such situations
can be kept to a minimum.

Parameters: from request_id to amount memo

Example Op:

cancel_transfer_from_savings

Roles: active owner

Parameters: from request_id

Example Op:

["cancel_transfer_from_savings",{"from":"alice","request_id":1}]

Since: HF14

custom_binary

The semmantics for this operation are the same as the custom_json
operation, but with a binary payload. The json deserialization has a
non-trivial cost associated with it. This operation will allow for
binary deserialization of plugin operations and should improve overall
performance of plugins that chose to use it.

Roles: posting active owner

Parameters: id data

Since: HF14

decline_voting_rights

An account can chose to decline their voting rights after a 30 day
delay. This includes voting on content and witnesses. The voting rights
cannot be acquired again once they have been declined. This is only to
formalize a smart contract between certain accounts and the community
that currently only exists as a social contract.

delegate_vesting_shares

Delegate vesting shares from one account to the other. The vesting
shares are still owned by the original account, but content voting
rights and resource credit are transferred to the receiving
account. This sets the delegation to vesting_shares, increasing it or
decreasing it as needed (i.e. a delegation of 0 removes the delegation).

When a delegation is removed the shares are placed in limbo for a week
to prevent a satoshi of VESTS from voting on the same content twice.

Parameters: delegator delegatee vesting_shares

Example Op:

account_create_with_delegation

Deprecated as of HF20 If an account creation service would still like to provide a delegation of Steem Power
to the accounts they create, they can still follow the account creation operation with an additional call to
delegate_vesting_shares to add a delegation of SP to the account.

Instead of paying the entire account creation fee with Steem, creators
can now pay a smaller fee (30x less) and delegate some Steem Power for
30 days. The exact amount is 5 * min_fee + STEEM_POWER == 150 * min_fee.
You can pay any combination of STEEM and Steem Power along that curve
(so long as the minimum fee is paid).

The witness voted STEEM fee is now the minimum required STEEM fee for
delegation. Witnesses should reduce their fee by 30x when the hardfork
goes live to preserve the same required fee for an all STEEM account
creation.

Roles: posting active owner

Parameters: hardfork_id

comment_payout_update

Roles: posting active owner

Parameters: author permlink

return_vesting_delegation

Roles: posting active owner

Parameters: account vesting_shares

Since: HF17

Virtual Operation

comment_benefactor_reward

Roles: posting active owner

Parameters: benefactor author permlink reward

Since: HF17

Virtual Operation

producer_reward

Witness rewards for block signing are hard to account for. Making these
rewards visible will help witnesses and prospective witnesses by
providing them with more complete and accurate information to guide
their decisions to invest in the platform.