cyber.domain
smart contract is designed to create and handle domain names, create or delete a link of domain names to accounts, change domain name owners, as well as to handle a purchase of domain names at auction.cyber.domain
smart contract includes the following actions:checkwin
, biddomain
, biddmrefund
and newdomain
are used to purchase a domain name at auction. The procedure for buying a domain name at the auction is the same as the procedure of buying an account name. The following rules apply to the procedure:newdomain
and become its owner.golos.io
can create subdomains such as api.golos.io
, ws.golos.io
and etc). In this case the only direct inheritance of domain names is allowed. It means that if the owner has created a domain for the second level, a domain for the third level can’t be created.Note: The account names are formed by adding parts to the right (for example,cyber.msig
,cyber.domain
can be formed fromcyber
).
checkwin
action is used to register a domain name owner (a winner) at auction. This action does not require a special call and is called automatically when either biddomain
or biddmrefund
is performing.checkwin
action has the following form:biddomain
action allows an account to bid at the auction. The action has the following form:bidder
— an account name which bids at the action. name
— a domain name (a string value in accordance with the requirements) on which the bid is done. bid
— a bid (in system tokens, asset
structure). cyber.domain
contract account should have the rights of the bidder
account to call transfer
action in cyber.token
contract. If a bid with a bigger value appears at the auction, the previous bid is returned to the bidder
account. The refunds are made automatically by internal calling biddmrefund
from biddomain
.biddmrefund
is used to return a bid which was made at the auction to purchase a domain name if a higher bid is made for the same domain name. The action has the following form:bidder
— the account name to which the funds are returned from the auction. name
— the domain name for which the bid was made. biddmrefund
action can be called apart from calling biddomain
(non-standard calling biddmrefund
).newdomain
action is used to create a new domain name. The action has the following form:creator
— account name that creates a domain name. name
— domain name being created. newdomain
action can be used:cyber.domain
(without an auction). cyber.domain
must be privileged or have a permission to transfer funds from cyber.names
(in case of a refund). Upon completion of this action, the creator
account becomes the owner of the created domain name.newusername
action is used to create a user name. The newusername
declaration has the following form:creator
— an account name in scope of which the user name is created. owner
— an account name that is to be the domain name owner. name
— a string representation of the user name to be created. newusername
must be signed by creator
account.passdomain
action is used to transfer a domain name from one account to another one (to change the domain name owner). The passdomain
declaration has the following form:from
— an account from which a domain name is transferred and which owns it. to
— an account to which the domain name is transferred and which will be a new domain name owner. name
— a string representation of the domain name to be transferred. from
that is the domain name owner.linkdomain
action is used to link a domain name to account name. After linking, the account can be found by domain name instead of account name. The linkdomain
declaration has the following form:owner
— an account that is a domain name owner. to
— an account account to which the domain name is linked. name
— a string representation of the domain name to be linked. unlinkdomain
action is used to remove domain name link from account name (unlinking a domain name from the account name). The unlinkdomain
declaration has the following form:owner
— an account that is a domain name owner. name
— a string representation of the domain name to be unlinked. unlinkdomain
, the linked domain name will not point to the account.ajhgsd23qw
. To eliminate this drawback, this account buys the hello
domain name and links it to its contract usinglinkdomain
. It is easier for users to remember such domain as @hello
and send transfers to this name. In contrast to sending transfers to the account name ajhgsd23qw
the domain name @hello
will be converted to ajhgsd23qw
and the declarenames
action will be added to the transaction indicating the used domain names.@hello
the account has to call the unlinkdomain
action. After that, the domain name @hello
will not be converted to ajhgsd23qw
and sending a transfer to it will be impossible.ajhgsd23qw
account in its environment can create usernames. For example, thic account can take the name admin
for owan use, and can assign the short name t
for the contractcyber.token
. In this case, the name [email protected]@ajhgsd23qw
(note the double @@
) will be resolved in the name ajhgsd23qw
, and [email protected]@ajhgsd23qw
in cyber.token
. When adding a domain name, it is possible to use [email protected]
and [email protected]
respectively.[email protected]
. The domain part defines a scope. The accounts with the same name can exist in different scopes. There are several variants that support username
data and allow a textual representation of a user name to match an account name.declarenames
action is used to submit a list of structures with information about the domain names (or user names) used in transactions and their respective accounts. The action has the following form:domains
— an array of descriptions, each description of which is a structure in form of name_info
. declarenames
action can be called by any account.name_info
structure is used to check the presence of all elements at the time of executing the procedure, as well as the existence of linking a domain name with the specified account. The name_info
structure declaration has the following form:domain
— a domain name. account
— an account name matching to the domain name. users
— a list of domain name users. declarenames
declaration is an array of structures. This array should not be empty.domains
array should satisfy the following requirements:.domain
), except for empty values (“ ”). .account
must not contain an empty value. declarenames
exist in other actions. The implementation of validation is difficult because the actual validation process requires a lot of resources to read the ABI file format and deserialize the action. A lack of such control causes a certain risk. That is a sender may add more information to the transaction, so the superfluous part of it will not be checked. As a result, it will have to pay extra for overused bandwidth
resources. someaction(name 1, name 2, name 3, name 4, name 5)
.
If a user sends an action like someaction(acc1, [email protected], [email protected], acc1, [email protected])
and it converts to (someaction(acc1, acc1, acc1, acc1, acc3)
), then declarenames
will contain only used user names or domain names. At the same time, it is impossible to determine the positions where user names were used, for example:[email protected]@account
( a presence of the symbols «@@» in the name means that the right side is not a domain, but the account name). For example, if a transaction converts view names [email protected]@token
, [email protected]@token
, [email protected]@golos.io
, then the declareames
declaration will contain the following arguments:users
in declarenames
indicate the usernames used, and in the account
- the scope where these users are registered. Although, the final accounts into which names are resolved are not specified, an explorer (or some other application) can always identify required account via using the pair username
+scope
.