cyber.domainsmart 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.domainsmart contract includes the following actions:
newdomainare 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:
newdomainand become its owner.
golos.iocan create subdomains such as
ws.golos.ioand 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.
cyber.domaincan be formed from
checkwinaction 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
checkwinaction has the following form:
biddomainaction 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,
cyber.domaincontract account should have the rights of the
bidderaccount to call
cyber.tokencontract. If a bid with a bigger value appears at the auction, the previous bid is returned to the
bidderaccount. The refunds are made automatically by internal calling
biddmrefundis 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.
biddmrefundaction can be called apart from calling
newdomainaction 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.
newdomainaction can be used:
cyber.domain(without an auction).
cyber.domainmust be privileged or have a permission to transfer funds from
cyber.names(in case of a refund). Upon completion of this action, the
creatoraccount becomes the owner of the created domain name.
newusernameaction is used to create a user name. The
newusernamedeclaration 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.
newusernamemust be signed by
passdomainaction is used to transfer a domain name from one account to another one (to change the domain name owner). The
passdomaindeclaration 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.
fromthat is the domain name owner.
linkdomainaction 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
linkdomaindeclaration 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.
unlinkdomainaction is used to remove domain name link from account name (unlinking a domain name from the account name). The
unlinkdomaindeclaration 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
hellodomain name and links it to its contract using
linkdomain. It is easier for users to remember such domain as
@helloand send transfers to this name. In contrast to sending transfers to the account name
ajhgsd23qwthe domain name
@hellowill be converted to
declarenamesaction will be added to the transaction indicating the used domain names.
@hellothe account has to call the
unlinkdomainaction. After that, the domain name
@hellowill not be converted to
ajhgsd23qwand sending a transfer to it will be impossible.
ajhgsd23qwaccount in its environment can create usernames. For example, thic account can take the name
adminfor owan use, and can assign the short name
tfor the contract
cyber.token. In this case, the name
[email protected]@ajhgsd23qw(note the double
@@) will be resolved in the name
cyber.token. When adding a domain name, it is possible to use
[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
usernamedata and allow a textual representation of a user name to match an account name.
declarenamesaction 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
declarenamesaction can be called by any account.
name_infostructure 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_infostructure 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.
declarenamesdeclaration is an array of structures. This array should not be empty.
domainsarray should satisfy the following requirements:
.domain), except for empty values (“ ”).
.accountmust not contain an empty value.
declarenamesexist 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
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
declarenameswill 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]@golos.io, then the
declareamesdeclaration will contain the following arguments:
declarenamesindicate 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