Sirius Chain Cheat Sheet
Reading guides
Documents under the "Protocol" category are categorized as a basic/common concept for most of the blockchain.
Documents under the "Built-in features" are features specifically for Sirius Chain.
You do not need to understand the "Schema" sections of the documents if you are just using the SDKs, unless you need it for reference for SDK developments.
Check out the coding guides here, the client and some SDKs guides are still missing. We will update it soon.
List of SDKs -> here.
Wallet and explorer -> here.
Sirius Chain
Use Proof-of-Stake and Proof-of-Greed consensus algorithms. Read more.
Each block will be generated every 15 seconds on average.
Chain network config can be found at
{API_URL}/config/{block_height}
All the fee, maximum duration and supported transaction information can be found here. eg. MosaicRentalFee, NamespaceRentalFee
The config might change at different block heights as the chain goes.
eg. http://arcturus.xpxsirius.io:3000/config/177060 which is main net API looking for config at block 177060
If you clicked the link above, there is a height returned which is 132969. It means that config is updated at height 132969 and block 177060 is following these config,
Please use REST API to debug or get information from Sirius Chain.
Development and Debugging
You can use REST API for debugging and retrieval of information.
You can use the websocket listener and services provided in the SDKs to ease your development.
If your transaction is not getting confirmed,
please check the transaction status with the REST API or websocket listening to your public key for transaction status. For REST API, you can check the status at
{API_URL}/transaction/{transaction_hash}/status
Transactions with errors will not be synced across different nodes, so make sure to connect to the same API node to get the error message with the transaction hash.
Account
From | You can get |
---|---|
Private Key | Public Key, Address |
Public Key | Address |
Address | - |
Private key - the seed for the account.
Public key - it can be regenerated by the private key but not vice versa, will be saved under transaction info and is visible to the public.
Public key is used to represent the owner of mosaic, owner of namespace and signer of transaction.
Account can be represented by a public key or address.
Security concerns :
Signing of transactions with a private key can be done locally, to avoid exposing the private key to external parties.
Client app/wallet must make sure the private key is stored and exposed only locally.
With the private key, it will have full control over the account. For better security, you can upgrade the account to a multisig account.
Please copy the private key down and keep it safe, there will be no way to get it back once lost.
Please use only trusted wallets.
Address
An address is a string with 40 characters or 46 characters with a dash in between.
The first character represents the different network types.
Network Type | Address Prefix |
---|---|
Public Mainnet | X |
Public Testnet | V |
Private Test | W |
Private | Z |
REST API
All response of REST API is in json format
The value that will be returned by REST API
- number in array
- array
- string
- object
Uint64 value
Since REST API is returned with json format, the uint64 number is not supported. Hence, it needs to be separated into 2 uint32 arrays: the higher and lower part.
[
0 : lower
1 : higher
]
Uint64 id in hex
Refering to the above, the lower and higher, we can represent uint64 id in a hex string.
hex id = (higher_in_hex_8_length ) + (lower_in_hex_8_length)
Mosaic
Representation of an asset.
Mosaic id is the lower bracket of uint64, therefore the first mosaic id hex is represented by
00
to7F
.- All mosaic id hex will start from
00XXXXXXXXXXXXXX
to7FXXXXXXXXXXXXXX
.
- All mosaic id hex will start from
The mosaic id will always be different as it is generated by a nonce and the owner's public key.
Only owners can make changes to their mosaics.
The default fee for creating a new mosaic is 10,000 XPX.
The default max duration is 3650 days or approximately 10 years.
- Duration is calculated by block, so 1 minute = 4 blocks and an average block generation is 15 seconds.
Namespace
The concept is similar to dns, which uses the domain name to represent the IP address.
Likewise, a registered namespace is not necessarily linked to anything.
Namespace id is the upper bracket of uint64, therefore the first namespace id hex is represented by
80
toFF
.- All namespace id hex will start from
80XXXXXXXXXXXXXX
toFFXXXXXXXXXXXXXX
.
- All namespace id hex will start from
Namespace id will always be the same for the same names:
- prx will always be
b16d77fd8b6fb3be
hex id. - prx.xpx will always be
bffb42a19116bdf6
hex id.
- prx will always be
Namespace example :
prx
- rootnamespaceprx.xpx
- rootnamespace and subnamespace,xpx
is the subnamespacemycompany.address.sea
- rootnamespace, subnamespace and subsubnamespace
Rootnamespace
Default.
Fee - 0.004576 XPX per block.
Max duration - 365 days or approximately 1 year.
Duration is calculated by block, so 1 minute = 4 blocks, average block generation is 15 seconds.
Subnamespace
Default creation fee - 10,000 XPX.
Duration will follow rootNamespace.
It has a parent id linked to the rootnamespace or subnamespace.
Alias
Use namespace to represent a single address or mosaic.
Use AliasTransaction to link or unlink the namespace to address or mosaic.
You can send transactions to linked namespaces directly instead of using addresses or mosaic ids.
eg.
mycompany.address
can be linked to mycompany's address.mycompany.coin
can be linked to mycompany's utility coin mosaic.- You can even use
mycompany
to link any address or mosaic.
Fee
effective_fee = transaction_final_size_in_bytes * fee_multiplier. eg.
213 * 100 = 21300 = 0.021300 XPX
.fee_multiplier is an integer value starting from 0.
If effective_fee >= max_fee(defined by user), the validator can opt to include the transaction in the block.
Max_fee and effective_fee value is in the lowest currency absolute value. eg.
5000 max fee = 0.005000 XPX
.Transactions sent might not be the final transaction size; the size might be increased due to more complex transactions such as aggregate transactions with multisig accounts that come with extra cosigner information. Fee_multiplier will calculate with the final transaction size.
For validator
Validators need to define
fee_multiplier
, which considered as fee per byte.You can read more on our Proof-of-Greed Extension and transaction fee for
fee_multiplier
strategy.
For User
Need to specify
max fee
or leave it to let the SDK calculate it. SDK will cap the fee at 5 XPX per transaction.SDK currently is using a
max fee
of 250 per byte.Transaction fee paid will always be less than or equal to the
max fee
, depending on thefee_multiplier
used by the validator.