Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
https://docs.scrt.network/cli/secretcli.html
The _secretcli
_ (Secret Network Light Client) is a command-line interface tool for interacting with nodes running on the Secret Network blockchain. With the _secretcli
_ you can perform many important functions related to:
Generating keys
Creating multisig wallets
Sending transactions
Deploying and interacting with Secret Contracts
Using governance
and more...
There are differences between secretcli
and secretd
. secretd
is a full node including the code running inside SGX, and secretcli is a command line interface (CLI) for sending and querying Secret Network transactions.
secretcli
And secretd
?Since secretd
requires a full node with SGX capabilities; it's less user-friendly than secretcli because users must do the secondary step of installing SGX for its use. Most users interacting with the Secret Network using a CLI will not require a full node for sending and querying transactions and do not need to access a full node with the code running inside SGX.
The decision to make a distinction between secretcli
and secretd
was created to improve user experience. Installing SGX on Windows (hard), Mac (not supported), and desktop Linux (hard) is challenging and only required for specific use cases like running a full node, checking the status of a node, viewing public keys associated with a node, backing up mnemonics of a node, etc...
To install the secretcli download the latest version here. Download the appropriate version of the secretcli based on the operating system you are using:
secretcli-Linux
secretcli-macOS
secretcli-MacOS-arm64
secretcli-Windows
After downloading secretcli-Linux you will need to navigate to the folder you have download it to make secretcli-Linux an executable program using a graphical user interface (GUI) or the command-line.
Note: Installing secretcli-Linux will ONLY give you access to the secretcli
commands. For secretcli
and secretd
commands install one of the .deb packages.
Right click on the secretcli-Linux file and select 'Properties', then select 'Permissions', and then check the 'Allow executing the file as program' box beside the 'Execute' column.
To make secretcli-Linux executable using the command-line navigate to where the file is located and use the following command:
You can now use the secretcli
by using the following command inside of the folder it is located in with:
You will see some outputs related to available commands, flags, and usage.
It is recommended to rename seretcli-Linux to 'secretcli', and move the executable file into the correct location so it is automatically executable by typing secretcli
anywhere within the command-line.
To achieve this use the following commands in the directory containing secretcli-Linux:
Congrats! The secretcli
is now installed!
Download the correct version of the secretcli
for the Mac hardware on your system here. After downloading the secretcli
there are two steps required to allow your system to execute the cli.
First, open your terminal application and navigate to the directory containing the secretcli
file for your systems hardware. Once in the correct directory you will need to rename the file, and make the file executable using the following commands:
Mac users are required to perform another step after making the secretcli
executable on their machines. This is because MacOs cannot recognize the developer of the secretcli file. Try running the following command in the directory containing the executable secretcli
:
You will get a warning popup window with text similar to the following --> “secretcli” cannot be opened because the developer cannot be verified. There will be two options: move to trash or cancel. Select cancel.
You will see the text: "secretcli" was blocked from use because it is not from an identified developer. Click the 'Allow Anyway' button.
Now you should be able to use the secretcli
when inside of the folder it is found in:
You will see the following warning popup, click 'open'.
After clicking open you should see the following output in your terminal application:
We recommend moving the secretcli
into your path to be able to use it anywhere within your systems terminal application with:
Congrats! The secretcli
is now installed!
secretcli-Linux
is compatible for use within the Windows Subsystem for Linux (WSL). Follow the Linux Command-line instructions to install it.
After downloading secretcli-Windows you can now use the secretcli
by using the following command inside of the folder it is located in:
You will see some outputs related to available commands, flags, and usage.
It is recommended to rename seretcli-Windows to 'secretcli.exe', and move the executable file to a location where it is automatically executable by typing secretcli
anywhere within the command-line.
To achieve this use the following commands in a Powershell terminal, in the directory containing secretcli-Windows:
Restart your terminal and test the installation by running:
To update or install a different version of SecretCLI on Windows, download the release of secretcli-Windows and move it to the correct location:
The other commands do not need to be run again if they have already been run on your account.
In order to get your MaOs system to be able to execute the secretcli
, you will need to change the system preferences on your mac by going to the Apple menu > System Preferences > click Security & Privacy > then click General.
SCRT Labs regularly updates a containing information required to configure the secretcli.
There are three primary Secret Network address types:
Secret
Secretvaloper
Secretpub
Secret keys are for receiving and sending funds. They are made using:
The command will generate an output similar to the following:
An example of what a secret key looks like is:
secret1knpfllytv22umrlahglwmhjxkgavccjltxwnca
Secretvaloper keys are used to associate a validator to it's operator, and to invoke staking commands. To view an accounts secretvaloper key use:
The command will generate an output similar to the following:
An example of what a secretvaloper key looks like is:
secretvaloper14c29nyq8e9jgpcpw55e3n7ea4aktxg4xnurynd
Secretpub keys are publicly available addresses that are distinct from the private / public key pair used for secret keys. They are primarily used by developers in Secret Network DApps, and by secretcli users to create multisig wallets with keys they do not own. To view an accounts secretpub key use:
The command will generate an output containing the corresponding accounts secretpub key:
After installing the secretcli, the next thing to do is to start generating your own keys (public and private) to begin receiving, sending, and bonding SCRT.
secp256k1
KeyTo generate a new secp256k1 key:
Note: The output of the above command contains a seed phrase. It's recommended to save the seed phrase in a safe place in case you forget the password of the operating system's credentials store.
The above command will generate an output similar to:
To delete a key use:
After deleting a key you will no longer have access to the associated key account. You may regenerate the deleted key using the secretcli and the keys seed phrase.
Multiple keys may be deleted at once. You will be prompted to confirm each keys deletion:
You can regenerate the key from the seed phrase with the following command:
You can also backup your key using export
— which outputs to stderr:
(copy and paste to a <key-export-file>
)
You can import a key using the secretcli with:
After importing your key, verify the key is imported with:
\
If you check your private keys, you'll now see <key-alias>
:
If you want to just see your secret address:
You can see all your available keys by typing:
View the validator operator's address via:
View the validator pubkey for your node by typing:
Note: This is the Tendermint signing key, not the operator key you will use in delegation transactions.
We strongly recommend NOT using the same passphrase for multiple keys. The Tendermint team and the Interchain Foundation will not be responsible for the loss of funds.
Local key types are Secret Network keys owned by a secretcli user (i.e controls the private keys). Local accounts are made using the secretcli keys add <alias>
command.
Multi key types, are Secret Network keys representing multi-signature wallet addresses. They are generated using the secretcli keys add --multisig=name1,name2,name3[...] --multisig-threshold=K command.
Offline key types are Secret Network keys that are imported into a secretcli users keyring, but NOT owned by the user. They are generated using the secretcli keys add <alias> --pubkey=<public_
address_
key>
command.
You can generate a multisig wallet using keys you own using the secretcli by:
The command above will generate an output similar to the following:
You can generate multisig wallets with your own keys, and using other public keys you do not own using the secretcli:
Now that all the keys are present in your local secretcli keyring, create a multisig wallet as you normally would with keys that you own:
To confirm the multisig wallet was made with the correct addresses use:
K
is the minimum number of private keys that must have signed the transactions carrying the public key's address as a signer. Typically the K value will be lower than the total number of wallets associated with the multisig wallet, and high enough to require the majority of associated wallets to approve transactions.
For example, if there are 6 controlling addresses associated with a multisig wallet it would be poor practice for set the K value to 1, 2, 5, or 6. If the K value is too low (i.e 1 or 2) a minority of multisig members will be always in control of the multisig wallet; if any one or two members agree on making a transaction they will be able to even if the remaining 4-5 members do not agree with the transactions. If the K value is too high, and one or two of the members wallets on the multisig are lost or compromised no transactions with the multisig will be possible, and all associated assets held by the multisig wallet will be lost.
The --multisig
flag must contain the name of public keys to be combined into a public key that will be generated and stored as new-key-alias
in the local database.
All names supplied through --multisig
must already exist in the local database. is set. The order of the supplied keys on the command line does not matter, i.e. the following commands generate two identical keys:
To make the multisig wallet keys get passed into the multisig wallet in a specific order (i.e the order they are given) the --nosort
flag must be used:
For demonstration purposes, the above command will produce a multisig wallet where each key is added in the exact order they are given to the public keys associated with the multisig wallet:
On a testnet, getting tokens is usually done via a faucet. You can get tokens for testing purposes using the Secret Network faucet.
After receiving tokens to your address, you can view your account's balance by typing:
Get your <secret-address>
using:
You can also supply your address with the following command:
Note: When querying an account balance with zero tokens, you will get the error: No account with address <secret-address> was found in the state.
This can also happen if you fund the account before your node is fully synced. These are both normal.
Use the following command to send tokens from one account to another:
Note: The amount
argument accepts the format <value|coin_name>
. You may want to cap the maximum gas consumed by transactions via the --gas
flag.
If you pass --gas=auto
, the gas supply is automatically estimated before transaction execution.
Inaccurate gas estimates may occur in-between the end of the simulation and the actual execution of a transaction. An adjustment needs to be applied on top of the original estimate for the transaction to be broadcasted successfully. Adjustment are controlled via the --gas-adjustment
flag, with a default value of 1.0.
To view updated balances of origin and destination accounts use:
You can also check balances at any block height using the --height
flag:
You can add a note (previously called 'memo') to any transaction using the --note
flag:
You can simulate a transaction without actually broadcasting it by appending the --dry-run
flag:
Furthermore, you can build a transaction and print its JSON format to STDOUT by appending --generate-only
to the list of arguments:
Note: The --generate-only
flag prevents secretcli
from accessing the local keybase. When the flag is supplied <sender-key-alias-or-address>
must be an address.
You can validate transaction signatures by typing the following:
You can broadcast the signed transaction to a node by providing the JSON file using:
Querying transaction commands use the following format:
Use the transaction search command to query for transactions matching a specific set of events
, which are added on every transaction.
Each event contains a key-value pair in the form of {eventType}.{eventAttribute}={value}
.
Events can be combined to query for more specific results using the &
symbol.
You can query transactions by events
as follows:
And for using multiple events
:
The pagination is supported as well via page
and limit
:
Note: The action tag always equals the message type returned by the Type()
function of the relevant message.
You can find a list of available events
on each of the SDK modules:
You can query a single transaction by its hash using the following command:
There are four flags associated with querying Secret Network transactions using the secretcli.
The --height [int]
flag uses a specific height to query the state of the Secret Network (there will be an error if the node is pruning state).
The --node [string]
flag uses <host>:<port> to connect with the Tendermint RPC for a specific chain (default is "tcp://localhost:26657").
The --type [string]
flag is for querying a tx, and can be the 'hash' (default), 'acc_seq', or 'signature'.
The --help
flag will generate an output giving further details on flags to use with the tx
class of secretcli
commands, and information about global flags
to use with the secretcli
.
Multisig transactions require signatures of multiple private keys, typically owned by multiple parties. A multisig transaction is initiated by any key holder, and at least one of them would need to import other parties' public keys into their Keybase and generate a multisig public key to finalize and broadcast multisig transactions.
When a new multisig public key test_multisig
is stored its address will be the signer of multisig transactions:
You may also view multisig threshold, pubkey constituents and respective weights by viewing the JSON output of the key:
The -p
flag can be used interchangeably with the --pubkey
flag to only show the output of pubkey information.
General usage of the secretcli for sending transactions uses the follow format:
The first step to create a multisig transaction is to initiate it on behalf of the multisig address created above using the following command:
The file unsignedTx.json
contains the unsigned transaction encoded in JSON. key1
can now sign the transaction with its own private key:
After generating the key1Signature.json file, other wallets making up the multisig need to use the unsignedTx.json to generate their own individual signed json files:
Since the 'k' value of test_multisig
is set to 2, a third signature from the final key making up the wallet (key3
) is not required to officially sign and broadcast the multisig transaction. Any the key holders of the multisig can now generate the multisig transaction by combining the required signature files:
The transaction can now be broadcast to the network using the singed.json file:
After executing the above command an output will be generated containing information about the transaction:
Note: To be able to correctly test multisig transactions you will need tokens owned by the multisig wallet.
Broadcasted transactions can be viewed online using a Secret Network block explorer by searching for the transaction has (txhash). For example, the testnet transaction above can be viewed .
On the Secret Network gas is a special unit used for tracking the the use of resources during code execution (usually paid by the transaction sender). Gas fees are normally paid to execute read / write commands, but can also be used to pay for more resource intensive computational tasks.
Gas primarily serves two purposes:
To ensure each block is not over consuming resources, and that each block will be finalized on-chain. The cost of gas
consumed during message
execution results in a fee
where fees = gas * gas-prices
.
To prevent end-users from spamming and abusing the Secret Network. Most applications implement fee mechanisms to prevent spam, but the secretcli
does not enforce gas pricing by default.
Each transaction supplies fees or gas prices, but never both.
Validator's have a minimum gas price (multi-denom) configuration used to determine if they should include a transaction in a block during CheckTx
, where gasPrices >= minGasPrices
.
Note: Transactions must supply fees greater than or equal to any fees set by validators. Validators may start to prioritize transactions by gasPrice
in the mempool, increasing transaction priority based on fees or gas prices.
e.g.
or
Transactions can be broadcast using the following command:
When broadcasting transactions, secretcli
can accept a --broadcast-mode
flag. The value of this flag can be sync
(default), async
, or block.
sync
makes the client return a CheckTx response (default)
async
makes the client return immediately
block
makes the client wait for the Tx to be committed (transaction may fail)
Note: The block
mode should not be used in most circumstances because broadcasting can timeout, but the Tx may still be included in a block which can create undesirable situations. Therefore, it is best to use sync
or async
, and query by Tx hash to determine when the Tx is included in a block.
To check current distribution parameters, run:
To query all coins in the community pool under Governance control:
To check current outstanding (un-withdrawn) rewards, run:
To check current outstanding commission for a validator, run:
To check historical slashes for a validator, run:
To check current rewards for a delegation (were they to be withdrawn), run:
To check all current rewards for a delegation (were they to be withdrawn), run:
To upload a contract:
--source
: Optional tarball of the source code, so your contract will be verifiable.
--builder
: Optional docker image used to compile ./contract.wasm.gz
, so that your contract will be verifiable. This is important for reproducible builds so you should figure out the exact version of enigmampc/secret-contract-optimizer
that you were using.
To get the contract's code ID:
This will output a long JSON output, like this:
You will then find the code id under the logs.events array on the object with key code_id.
In order to instantiate a contract, simply run the following command:
Where $CODE_ID
is the code id that you got from the command above and $INIT_INPUT_MSG
is a JSON encoded version of the init message required in your contract. This message will depend on your contract.
To get the contract's address:
You will find the contract address under logs.events.array on the object with key contract_address.
Executing a contract is just as simple, simply use
Where$CONTRACT_ADDRESS
is the address you found above, and $EXEC_INPUT_MSG
is the message containing the handle function you're trying to execute. This message will heavily depend on your contract, but generally the format follows the following pattern:
You can also execute a function on a contract by using the contract's label over the address, like so:
Please note that this is not recommended as its easy for someone to deploy a contract with a similar enough label where you could possibly execute the wrong contract by typoing, but it's much harder for the same thing to happen with an address.
In order to read the output of a transaction, such as the output of a handle function called by compute execute or a contract that has just been instantiated you would run the following
Where $HASH is your transaction hash.
Querying a smart contract is just as easy, you just execute the following:
Where$CONTRACT_ADDRESS
is the address of your contract and $QUERY_INPUT_MSG
is the query you're trying to run. The output will depend on your contract.
Secret Network minting is based on the Comos SDK. For more information on minting follow this link.
You can query for minting/inflation parameters via:
The denomination of the token being minted.
The rate of uscrt inflation changing over-time.
The maximum inflation rate of uscrt tokens over the course of a year.
The minimum inflation rate of uscrt tokens over the course of a year.
The desired % of uscrt tokens bonded from the supply.
The number of minted blocks per year.
To query for current inflation value:
To query for current annual provisions value:
The query
commands allow users to query slashing
state:
The params
command allows users to query genesis parameters for the slashing module.
signed_blocks_window
, alongside min_signed_per_window
is how validator uptime is calculated. With an average block time of 6 seconds, 22500
blocks is roughly 37 hours worth of blocks.
min_signed_per_window
is a percentage. For Secret, that number is 50%. In other words, to become jailed, a validator must miss half of the 22500
blocks (as defined by signed_blocks_window
) in order to become jailed. Given that 22500 blocks takes roughly 37 hours, it'd require missing nearly 18 hours of consecutive blocks to become jailed and incur a downtime slashing event.
downtime_jail_duration
is how many seconds must pass before a validator can become unjailed by running secretd tx slashing unjail --from {wallet}
.
slash_fraction_double_sign
is the percent of all stake on the validator that is burned when a validator is slashed. For most networks including Secret, that value is 5%. Meaning, if 100 SCRT is delegated to the validator regardless of whether it's owned by the operator or delegators, 5 SCRT will be burned and permanently taken out of circulation.
slash_fraction_downtime
is the percent of all stake on the validator that is burned when a validator is slashed. For most networks including Secret, that value is 0.01%. Meaning, if 100 SCRT is delegated to the validator regardless of whether it's owned by the operator or delegators, 0.01 SCRT will be burned and permanently taken out of circulation.
The signing-info
command allows users to query signing-info of the validator using consensus public key.
The signing-infos
command allows users to query signing infos of all validators.
The tx
commands allow users to interact with the slashing
module.
The unjail
command allows users to unjail a validator previously jailed for downtime.
You can query the list of all validators of a specific chain:
If you want to get the information of a single validator you can check it with:
On the Secret Network mainnet, we delegate uscrt
, where 1scrt = 1000000uscrt
. Here's how you can bond tokens to a validator (i.e. delegate):
Example:
<validator-operator-address>
is the operator address of the validator to which you intend to delegate. If you are running a full node, you can find this with:
Where <key-alias>
is the name of the key you specified when you initialized secretd
.
While tokens are bonded, they are pooled with all the other bonded tokens in the network. Validators and delegators obtain a percentage of shares that equal their stake in this pool.
To withdraw the delegator rewards:
Once you've submitted a delegation to a validator, you can see it's information by using the following command:
Example:
Or if you want to check all your current delegations with distinct validators:
There currently is in place a 21 days unbonding rule, during which no rewards are handed out.
If for any reason the validator misbehaves, or you just want to unbond a certain amount of tokens, use this following command:
The unbonding will be automatically completed when the unbonding period passes.
Once you begin an unbonding-delegation, you can see it's information by using the following command:
Or if you want to check all your current unbonding-delegations with distinct validators:
Additionally, you can get all the unbonding-delegations from a particular validator:
A redelegation is a type delegation that allows you to bond illiquid tokens from one validator to another:
Here you can also redelegate a specific shares-amount
or a shares-fraction
with the corresponding flags.
The redelegation will be automatically completed when the unbonding period has passed.
Once you begin an redelegation, you can see it's information by using the following command:
Or if you want to check all your current unbonding-delegations with distinct validators:
Additionally, you can get all the outgoing redelegations from a particular validator:
Parameters define high level settings for staking. You can get the current values by using:
With the above command you will get the values for:
Unbonding time
Maximum numbers of validators
Coin denomination for staking
Example:
All these values will be subject to updates though a governance
process by ParameterChange
proposals.
A staking Pool
defines the dynamic parameters of the current state. You can query them with the following command:
With the pool
command you will get the values for:
Not-bonded and bonded tokens
Token supply
Current annual inflation and the block in which the last inflation was processed
Last recorded bonded shares
You can also query all of the delegations to a particular validator:
Example:
\
A user can query and interact with the slashing
module using the CLI. For more information about how slashing works on the Secret Network go to the page and look for the '' section.
See for the official Cosmos Network module documentation.
On mainnet, you can delegate uscrt
to a validator. These delegators can receive part of the validator's fee revenue. To learn more read about the .
Note: _ ._
As of V1.7 of Secret Network users can enable autocompounding SCRT staking with their respective validators.
when you delegate uscrt
to a validator. These delegators can receive part of the validators fee revenue. To learn more read about the Cosmos Token Model.
The autostake feature will claim rewards for you and automatically delegate them back to the same validator. To receive your liquid rewards you will have to unbond.
The minimum amount of staked SCRT to use this feature is 10 SCRT!
Learn more about the Restake feature here
You can query the restaking situation per delegator and receive a list with validator addresses for which the user has turned this feature on.
On the Secret Network mainnet, we delegate uscrt
, where 1scrt = 1000000uscrt
. Instructions can be found here.
One must be staked before one can activate restaking. The following command can be used to activate restaking for the stake that is with that validator as long more tokens are bonded than restake-threshold
(currently 10000000 uSCRT = 10 SCRT
).
One can query the parameters for Restake using the command below
With the above command you will get the values for all parameters that can be set by Governance including:
minimum_restake_threshold
- # of uSCRT required to enable restake
restake_period
- The autocompouding frequency denominated in the # of blocks
One can also query the restake-threshold
directly. For now one can use a direct LCD CURL to get the information like: https://lcd.secret.express/cosmos/distribution/v1beta1/restake_threshold but a SecretCLI and Secret.JS query is being implemented.
If you are running a full node or a validator node, view the status by typing:
Example output for secretcli status | jq
:
This guide is for Ledger Nano S, S+, and X.
A Ledger device is a hardware wallet that is considered one of the most secure ways to store your digital assets. A Ledger device uses an offline, or "cold storage," method of generating private keys, making it a preferred method for many crypto users. This guide will help you to connect your Ledger device to the Secret Network's CLI and GUI wallets. The wallets enable you to send and receive SCRT as well as stake/delegate SCRT with the Ledger device.
1. This guide assumes you have a verified, genuine Ledger Nano S,S+ or X device.
3. We also advise you to check your Ledger device's genuineness and upgrade your firmware to the newest one available.
1. Open Ledger Live.
2. Now go to Manager and search "secret":
3. Hit "Install" and wait for the process to complete.
Prepare your Linux host to work with Ledger
MacOS
1. Open the tab in the right top corner and click "Import Address."
2. Then, select "Ledger via WebUSB" and confirm with "Next".
3. Pick a name for your wallet and continue with "Next".
4. Lastly, check the displayed address in Ping.pub against the one displayed on your Ledger device, before confirming it on your Ledger device. Only then confirm with "Save" on the website.
1. To display your account, head to the drop down menu in the top right corner and select "Accounts."
2. You can see all of your registered accounts in Ping.pub.
3. To see your account balance and transactions in detail, click on the account to show the details.
Copy the displayed account address in the Ping.pub wallet to receive SCRT. Please make sure that you verified your receiving address on the Ledger device to prevent loss of funds.
To send SCRT, display your account balance. By selecting "Transfer", a window will appear in which you can input the destination address/Recipient and the amount you want to send.
Lastly, hit "Send" to send the transaction to the Ledger device. On your Ledger device, verify the transaction details on the device display, before confirming and signing it.
Note: You can use any number you'd like for your account number. Be sure to remember the number you used, so you can recover if needed. The default for the account number is 0.
secretcli
that already exists on your Ledger deviceYou'll use this when you, say, using a different machine.
Warning: if you run the above command without the --ledger
flag, the CLI will prompt you to enter your BIP39 mnemonic, which is your Ledger device recovery phrase. YOU DO NOT WANT TO DO THIS. This will essentially save your private key locally, which defeats the purpose of using a Ledger device.
The commands below assume that you run them on the same machine where you have a Secret Network node running. If you wish to connect to a remote Secret Network node while you interact with your Ledger device locally, the following command will use SCRT Lab's public node:
Once created, you can now query information of the proposal:
You can query for all available proposals using:
You can query for the proposal depositor using:
You can query for the proposal depositors using:
You can query for the proposal voter using:
To query for the proposer of a given governance proposal use:
To check the current tally of a given proposal you can use the tally
command:
To check the current governance parameters run:
To query subsets of the governance parameters for voting run:
To query subsets of the governance parameters for tallying run:
To query subsets of the deposit governance parameters for voting run:
2. If you don't, or you using your Ledger device for the first time, you should check Ledger's guide.
4. Have a machine with installed.
5. Have the latest version of our latest binaries installed in case you use Secret CLI. You can get it .
Note: To run the commands in Secret CLI or the GUI wallets below, or any command that requires signing with your Ledger device, you need your Ledger device to be opened on the Secret App:
Some users may not have their Ledger device recognized by their Linux host. To fix this issue implement the fix for connection issues on Linux from the
You will need at least MacOS 10.14 Mojave, which introduced the Security feature of allowing Full Disk Access, which Ledger Live needs in order to enable the --ledger
flag in secretcli
. Refer to the MacOS section in the .
The ping.pub GUI wallet provides basic capabilities for Secret such as creating an account, staking and transferring SCRT tokens. Visit the ping.pub site for Secret .
For a more advanced user, it is possible to interface with the CLI utility, SecretCLI with a Ledger device. You can get it . These are some basic examples of commands you can use with your Ledger device. You may notice that most commands stay the same, you just need to add the --ledger
flag.
For support please contact the Secret Support .
Governance is the process of Secret Network users coming to consensus on software upgrades, parameters of the mainnet, or signaling mechanisms through text proposals. This is done through voting on proposals, which will be submitted by SCRT
holders on the mainnet.
Voting is done by bonded SCRT
holders on a 1 bonded SCRT
1 vote basis.
Delegators inherit the vote of their validator if they don't vote.
Votes are tallied at the end of the voting period (1 week on mainnet) where each address can vote multiple times to update its Option
value (paying the transaction fee each time), only the most recently cast vote will count as valid.
Voters can choose between options Yes
, No
, NoWithVeto
and Abstain
.
For more information about the governance process and how it works, please check out the Governance module specification.
To setup governance the secretcli
must be installed. You can get a detailed description of how to install the secretcli here.
If the proposal you previously created didn't meet the MinDeposit
requirement, you can still increase the total amount deposited to activate it.
Note: Proposals not meeting this requirement will be deleted after MaxDepositPeriod
is reached.
Once the minimum deposit is reached, the proposal enters voting period:
Note: The regular flags for the tx command are applicable to gov deposit
(--fees, --gas, --account-number --ledger, --node, etc...)
The only ways deposits won't be returned to their owners is:
If in the voting period the proposal gets 1/3 NoWithVeto
out of all votes, excluding Abstain votes (So NoWithVeto
needs to be 1/3 out of all Yes
, No
& NoWithVeto
).
If in the voting period less than 1/3 of voting power votes (== The proposal won't reach a quorum).
Anyone can deposit for a proposal, even if you have 0 SCRT
tokens staked/delegated/bonded.
Once a new proposal is created, you can query all the deposits submitted to it:
You can also query a deposit submitted by a specific address:
There are several flags to use with secretcli query gov deposit
:
In order to create a governance proposal, you must submit an initial deposit along with a title and description. Currently, in order to enter the voting period, a proposal must accumulate within a week deposits of at least 100 SCRT
.
Note: Please remember through the duration of this guide that the secretcli
counts SCRT in uscrt. 1 SCRT = 1,000,000 uscrt.
Various modules outside of governance may implement their own proposal types and handlers (eg. parameter changes), where the governance module itself supports Text
proposals. Any module outside of governance has it's command mounted on top of submit-proposal
.
To submit a Text
proposal:
You may also provide the proposal directly through the --proposal
flag which points to a JSON file containing the proposal:
Where proposal.json
is:
To submit a parameter change proposal, you must provide a proposal file as its contents are less friendly to secretcli
input:
Where proposal.json
is:
You can see another param-change
example here: enigma-1-proposal-3.json
The subspace
is usually the ModuleName
The key
is usually defined in x/$MODULE_NAME/types/params.go
The value
's type is usually near the key
definition
⚠️ subspace
and key
are case sensitive and value
must be of the correct type and within the allowed bounds.
Proposals with errors on these inputs should not enter voting period (should not get deposits) or be voted on with NoWithVeto
.
⚠️ Currently parameter changes are evaluated but not validated, so it is very important that any value
change is valid (i.e. correct type and within bounds) for its respective parameter, eg. MaxValidators
should be an integer and not a decimal.
⚠️ Proper vetting of a parameter change proposal should prevent this from happening (no deposits should occur during the governance process), but it should be noted regardless.
To read more go to the Cosmos Parameters Wiki.
To submit a community pool spend proposal, you also must provide a proposal file as its contents are less friendly to secretcli
input:
Where proposal.json
is (make sure to change the recipient address to a real address when testing):
The SoftwareUpgrade
is currently not supported as it's not implemented and currently does not differ from the semantics of a Text
proposal.
Everything that you need to setup a validator from picking the right hardware to getting a validator up and running.
This section covers the hardware setup, as well as setting up a node for mainnet or testnet and creating a validator if needed.
This chapter gives you an insight of what you need to run a node in Secret Network. Since Secret Network uses Intel SGX, nodes have to fulfill special requirements.
Subspace | Key | Type | Example |
---|---|---|---|
You can find help in Telegram
Visit the Secret Network Discord and ask in #node-discussion or #node-support for help
CPU compilant with SGX (see )
Motherboard with support for SGX in the BIOS (see )
CPU compilant with SGX (see )
Motherboard with support for SGX in the BIOS (see )
auth
MaxMemoCharacters
string (uint64)
"256"
auth
TxSigLimit
string (uint64)
"7"
auth
TxSizeCostPerByte
string (uint64)
"10"
auth
SigVerifyCostED25519
string (uint64)
"590"
auth
SigVerifyCostSecp256k1
string (uint64)
"1000"
baseapp
BlockParams
object
{"max_bytes":"10000000","max_gas":"10000000"}
baseapp
EvidenceParams
object
{"max_age_num_blocks":"100000","max_age_duration":"172800000000000","max_bytes":"50000"}
baseapp
ValidatorParams
object
{"pub_key_types":["ed25519"]}
bank
sendenabled
bool
true
crisis
ConstantFee
object (coin)
{"denom": "uscrt", "amount": "1000"}
distribution
communitytax
string (dec)
"0.020000000000000000"
distribution
secretfoundationtax
string (dec)
"0.030000000000000000"
distribution
secretfoundationaddress
string
"secret164z7wwzv84h4hwn6rvjjkns6j4ht43jv8u9k0c"
distribution
baseproposerreward
string (dec)
"0.010000000000000000"
distribution
bonusproposerreward
string (dec)
"0.040000000000000000"
distribution
withdrawaddrenabled
bool
true
evidence
MaxEvidenceAge
string (time ns)
"120000000000"
gov
depositparams
object
{"min_deposit": [{"denom": "uscrt", "amount": "10000000"}], "max_deposit_period": "172800000000000"}
gov
votingparams
object
{"voting_period": "172800000000000"}
gov
tallyparams
object
{"quorum": "0.334000000000000000", "threshold": "0.500000000000000000", "veto": "0.334000000000000000"}
mint
MintDenom
string
"uscrt"
mint
InflationRateChange
string (dec)
"0.080000000000000000"
mint
InflationMax
string (dec)
"0.150000000000000000"
mint
InflationMin
string (dec)
"0.070000000000000000"
mint
GoalBonded
string (dec)
"0.670000000000000000"
mint
BlocksPerYear
string (uint64)
"6311520"
slashing
SignedBlocksWindow
string (int64)
"5000"
slashing
MinSignedPerWindow
string (dec)
"0.500000000000000000"
slashing
DowntimeJailDuration
string (time ns)
"600000000000"
slashing
SlashFractionDoubleSign
string (dec)
"0.050000000000000000"
slashing
SlashFractionDowntime
string (dec)
"0.010000000000000000"
staking
UnbondingTime
string (time ns)
"259200000000000"
staking
MaxValidators
uint16
100
staking
KeyMaxEntries
uint16
7
staking
HistoricalEntries
uint16
3
staking
BondDenom
string
"uscrt"
ibc
AllowedClients
object (string[])
["07-tendermint"]
ibc
MaxExpectedTimePerBlock
uint64
"30000000000"
transfer
SendEnabled
bool
true
transfer
ReceiveEnabled
bool
true
Website: leaseweb
Leaseweb has been tested and confirmed working by the Secret Network community.
Rent a Bare metal from them with any of the hardware that shows as working on the Hardware Compliance list.
Ensure that Hyperthreading/Logical Processors & overclocking/undervolting are disabled in the bios.
Continue with the node setup guide starting here.
This is intended to guide you in selecting SGX-compliant VPS options for the Secret Network.
When renting a compliant bare metal machine from a VPS provider, ensure you do not accept any chassis or CPU substitutes they propose, unless those substitutes are on the Hardware Compliance list.
All cost estimates are based on the following recommendations:
Processor: E-series rather than E3 (due to age)
SSD: 512GB+
RAM: 64GB+
Just because a VPS is cheaper it does not make it better.
This is intended to guide you in selecting SGX compliant hardware for Secret Network.
This is not a comprehensive list of compliant hardware, but rather a guide for what has been verified to work. This list is often show as SGX compliant, but it does not discriminate against whether SGX is supported via SPS or Intel ME. Only SGX via SPS is supported.
CPU must support SGX via SPS. CPUs that only support SGX via Intel ME will not work.
The following are confirmed compliant Intel CPUs:
Only Intel processors support SGX. AMD processors are *NOT* supported.
List of Processors that Support Intel® Software Guard Extensions
The distinguishing factor of these motherboards is that they support Intel SGX.
This is not an exhaustive list of supported motherboards. These are simply motherboards proven supported by community members.
Go to their dedicated hosts/ Bare Metal services section and rent a Intel E-2286G Processor (6 cores / 12 threads @ 4.0 GHz)
Using the Boot Connection log into the BIOS and Ensure that Hyperthreading & overclocking/undervolting are disabled in the bios.
Things to note before setting up on Nforce.
Only certain chasis and CPU configuration have SGX enabled.
You need to manually communicate with Nforce to give you the right configuration so that SGX works on the BIOS.
For the purpose of this Guide i selected the HP DL20 G10 Chasis. For the CPU i slected the Intel E2174G (3.8-4.7 Ghz, 4C/8T)
With 32 GB ram, Ubuntu OS 20.04, and 512 GB SSD.
This takes about 1 day, you may need to make sure they have the servers, if they do not make sure you request only the same configuration or the SGX wont be enabled.
The SSC portal is only enabled once you finish the payment. Go to your dedicated servers and select the image. Go to remote management and create a session to log into the BIOS via IPMI. You'll need to make sure Hyper Threading is disabled.
Things to note before setting up on Psychz:
Only certain CPU's are available with setup
You need to manually Open the BIOS and select the configuration.
This takes about 1 day, you may need to make sure they have the servers, if they do not make sure you request only the same configuration or the SGX wont be enabled.
Make sure you request them to install the Latest BIOS for the SGX to work
The Dashboard portal is only enabled once you signup. Go to your device section. Go to IPMI (remote management) and create a session to log into the BIOS, I used the Java to download and connect to the BIOS over the port. You need to make sure Hyper Threading is disabled in the BIOS so that you can get an ok platform message.
VPS Provider | Cost/month | Setup Instructions |
---|---|---|
Brand | Family | Model |
---|---|---|
Brand | Tag | Versions | Link |
---|---|---|---|
Website:
Continue with the node setup guide
Website:
Login with your credentials and proceed with .
Website:
Ensure your hardware meets the requirements.
Login with your credentials and proceed with .
TBD
144
95
89
185
210
144
Hetzner
*NOT SUPPORTED*
160
X1 (Professional Line)
Intel
XEON E-Series
E-2174G
E-2176G
E-2178G
E-2186G
E-2188G
E-2274G
E-2276G
E-2278G
E-2286G
E-2288G
E-2334G
E-2386G
E-2388G
XEON Gold-Series
*NOT SUPPORTED*
AMD
*NOT SUPPORTED*
Supermicro
X11SCM-F
SYS-5019C-M
, SYS-5019C-MR
X11SCW-F
SYS-5019C-WR
X11SCZ-F
X11SSL-F
Dell
Dell R240
BIOS Version 2.14.1
Dell R350
BIOS version 1.7.3
HP
DL20 G10
BIOS version 1.80_07-20-2023
DL20 G10 +
ASUS
ASUS RS100-E10-PI2
BIOS version 5601
Asrock
E3C246D4U2-2T
GIGABYTE
MX33-BS1-V1
BIOS version F06
Websites: Global or United States
Currently, it is advised to exercise caution when considering OVHCloud servers, as there are concerns regarding the inadequate updating of their mainboards.
Please contact the node support in case you got more questions:
The following are examples of Hardware Compliant servers:
Example in the US: https://us.ovhcloud.com/bare-metal/infra/infra-2-le/
Global example: https://www.ovhcloud.com/en/bare-metal/rise/rise-3/
OVHCloud servers can come with either an ASUS or Asrock motherboard. The Asus motherboard does NOT support Intel SPS. If you receive the Asus motherboard, you'll need to create a ticket to have the motherboard replaced with the Asrock motherboard: Asrock E3C246D4U2-2T
Navigate to the server's management page
Under General Information, ensure SGX is enabled
3. Navigate to the IPMI tab. This will be used to disable overclocking and other necessary settings.
4. Enable Remote KVM
5. Create a DEL hotkey
6. Reset the server, and continue executing the DEL hotkey until you enter the BIOS.
7. Disable Intel Speedstep Technology
8. Under Chipset Configuration:
9. Save and Exit the bios
10. Reset the server again
11. Continue from Setting Up a Node
Nodes on Secret Network are required to be fully patched, and compliant with network requirements. While this requirement makes running a node and maintaining it harder, it is a necessary tradeoff that needs to be done if the network is to remain open and permissionless.
Part of the registration process on the network will validate the patch level of your platform (Motherboard + CPU). This requires your to have the necessary updates that mitigate known vulnerabilities that might lead to compromise of data protected by SGX.
Let's start with the different components that need to be updated -
Processor microcode (ucode) - Microcode is a type of low-level computer programming that is used to control the operations of a microprocessor. It is typically stored in the microprocessor itself or in a read-only memory (ROM) chip that is connected to the microprocessor. Microcode is used to define the basic set of instructions that a microprocessor can execute, as well as the operations that it can perform on data. It is usually written in a specialized microcode programming language, and it forms the lowest level of a computer's instruction set architecture.
SGX Platform Software (PSW) - This software package provides a set of tools and libraries to make use of the Intel SGX instruction set
The PSW packages can be updated using your standard operating system install methods. For example, in Linux do this:
While there are a few ways to update the processor microcode, it is important to note that for SGX, the updated microcode must be loaded through the BIOS. That means that upgrading the microcode using early load or late load (installing through the operating system) will not affect the SGX patch level of the platform.
To find out whether the microcode needs to be updated and find the latest version, we must first get the family, model, and stepping of our processor.
To find the stepping, model, and family of your processor, you can use the lscpu
command. This command displays detailed information about the CPU architecture.
Open a terminal window on your system and type the following command:
2. The output of this command will include the stepping, model, and family of your processor, as well as other information about the CPU architecture.
Here is an example of the output you might see:
In this example, the family, model and stepping of the processor are 6, 85, and 3, respectively.
Next, we take these values and translate them to hex and structure them as follows: <family>-<model>-<stepping>. In this example we get: 06-55-03
. This is our microcode file name for our processor.
Pro Tip: These numbers also allow us to get our CPUID, in the following order:
|model 1st digit|family|model 2nd digit|stepping|
. For example, 06-9e-0d -> 906ED
Now that we know what our microcode should be, we can compare it to our current microcode. Get your current version with:
cat /proc/cpuinfo | grep microcode
or dmesg | grep microcode
Note - On Azure machines will always return 0xFFFFFFFF as their microcode version regardless of the actual patch level
If your version does not match the latest one, you will need to update your BIOS. To do that, contact your motherboard vendor, or your cloud service provider and download or request the BIOS version that contains the latest microcode for your CPU.
After we have our microcode file name, we use it to find the latest version of our microcode, which is available here: . Continuing the previous example, the latest version of microcode for 06-55-03
is 0x0100015e
This section will take you through the process of taking a node from fresh machine to full validator on the public testnet pulsar-3.
This section will take you through the process of taking a node from fresh machine to full validator. The general steps are as follows:
Ensure your hardware is Hardware Compliance.
If you're running a local machine and not a cloud-based VM -
Go to your BIOS menu
Enable SGX (Set to "YES", it's not enough to set it to "software controlled")
Disable Secure Boot
Disable Hyperthreading
Note: sgx_linux_x64_driver_2.11.0_2d2b795.bin
is the latest driver as of August 24th, 2021. Please check under https://download.01.org/intel-sgx/sgx-linux/ that this is still the case. If not, please send us a PR or notify us.
If you are a node runner all you must do to install SGX is to save this as a script and run it.
Download the SGX install script.
Execute the script.
secretd init-enclave
See Verify SGX for a guide how to test your setup.
To uninstall the Intel(R) SGX Driver, run:
The above command produces no output when it succeeds. If you want to verify that the driver has been uninstalled, you can run the following, which should print SGX Driver NOT installed
:
To uninstall the SGX SDK, run:
To uninstall the rest of the dependencies, run:
In this section we quickly explain what the verification process for your hardware entails and how it works. Instructions for verification are included in the setup guides!
Attestation Certificate
This is a self-signed X.509 certificate that contains a signed report by Intel, and the SGX enclave. The report contains both a report that the enclave is genuine, a code hash, and a signature of the creator of the enclave.
Seed
this is a parameter that is shared between all enclaves on the network in order to guarantee deterministic calculations. When a node authenticates successfully, the network encrypts the seed and shares it with the node. Protocol internals are described here
This section will explain node registration in the Secret Network. If you just care about installation you can just follow the setup guides and ignore this document. If, however, you want to learn more about what's going on behind the scenes here read on.
In order to verify that each node on the Secret Network is running a valid SGX node, we use a process that we call registration. Essentially, it is the process of authenticating with the network.
The process is unique and bound to the node CPU. It needs to be performed for each node, and you cannot migrate registration parameters between nodes. The process essentially creates a binding between the processor and the blockchain node, so that they can work together.
For this reason, the setup will be slightly more complex than what you might be familiar with from other blockchains in the Cosmos ecosystem.
The registration process is made up of three main steps:
Enclave verification with Intel Attestation Service - this step creates an attestation certificate that we will use to validate the node
On-chain network verification - Broadcast of the attestation certificate to the network. The network will verify that the certificate is signed by Intel, and that the enclave code running is identical to what is currently running on the network. This means that running an enclave that is differs by 1 byte will be impossible.
Querying the network for the encrypted seed and starting the node
At the end of this process (if it is successful) the network will output an encrypted seed (unique to this node), which is required for our node to start. After decryption inside the enclave, the result is a seed that is known to all enclaves on the network, and is the source of determinism between all network nodes.
For a deeper dive into the protocol see the protocol documentation
Registration instructions are included in the Mainnet and Testnet Setup guides!
(or SCRT_ENCLAVE_DIR=/usr/lib secretd init-enclave | grep -Po 'isvEnclaveQuoteStatus":".+?"'
)
An outtput like this should be generated:
(or isvEnclaveQuoteStatus":"SW_HARDENING_NEEDED"
)
Where the important fields are isvEnclaveQuoteStatus and advisoryIDs. This is are fields that mark the trust level of our platform. The acceptable values for the isvEnclaveQuoteStatus
field are:
OK
SW_HARDENING_NEEDED
With the following value accepted for testnet only:
GROUP_OUT_OF_DATE
For the status CONFIGURATION_AND_SW_HARDENING_NEEDED
we perform a deeper inspection of the exact vulnerabilities that remain. The acceptable values for mainnet are:
"INTEL-SA-00334"
"INTEL-SA-00219"
Consult with the Intel API for more on these values.
If you do not see such an output, look for a file called attestation_cert.der
which should have been created in your $HOME
directory. You can then use the command secretd parse <path/to/attestation_cert.der>
to check the result a successful result should be a 64 byte hex string (e.g. 0x9efe0dc689447514d6514c05d1161cea15c461c62e6d72a2efabcc6b85ed953b
.
Running secretd init-enclave
should have created a file called attestation_cert.der
. This file contains the attestation report from above.
Contact us on the proper channels on scrt.network/discord
The details we will need to investigate will include:
Hardware specs
SGX PSW/driver versions
BIOS versions
The file attestation_cert.der
Output is:
Make sure you have the environment variable SCRT_ENCLAVE_DIR=/usr/lib
set before you run secretd
.
Output is:
Make sure the directory ~/.sgx_secrets/
is created. If that still doesn't work, try to create /root/.sgx_secrets
Output is:
Make sure the aesmd-service
is running systemctl status aesmd.service
Output is:
Please disable hyperthreading and overclocking/undervolting (Turboboost) in your BIOS.
I'm seeing CONFIGURATION_AND_SW_HARDENING_NEEDED
in the isvEnclaveQuoteStatus
field, but with more advisories than what is allowed
This could mean a number of different things related to the configuration of the machine. Most common are:
["INTEL-SA-00161", "INTEL-SA-00233"] - Hyper-threading must be disabled in the BIOS
["INTEL-SA-00289"] - Overclocking/undervolting must be disabled by the BIOS (sometimes known as Turboboost)
["INTEL-SA-00219"] - Integrated graphics should be disabled in the BIOS - we recommend performing this step if you can, though it isn't required
If you are still having trouble getting rid of INTEL-SA-00219 and INTEL-SA-00289, here are some possible settings to look for outside of the CPU settings:
Primary Display = 'PCI Express'
IGPU Multi-Monitor = Disabled
Onboard VGA = Disabled
I'm seeing SGX_ERROR_DEVICE_BUSY
Most likely you tried reinstalling the driver and rerunning the enclave - restarting should solve the problem
This document details how to join the Secret Network testnet
as a full node. Once your full node is running, you can turn it into a validator in the optional last step.
Secret Network has strict Hardware Requirements. If your machine does not meet them, it will *NOT* work as a node.
Ubuntu/Debian host (with ZFS or LVM to be able to add more storage easily)
A public IP address
Open ports TCP 26656 & 26657
Note: If you're behind a router or firewall then you'll need to port forward on the network device.
secretd
Choose a moniker for yourself, and replace <MONIKER>
with your moniker below. This moniker will serve as your public nickname in the network.
This will generate the following files in ~/.secretd/config/
genesis.json
node_key.json
priv_validator_key.json
genesis.json
The genesis file is how other nodes on the network know what network you should be on.
Initialize /opt/secret/.sgx_secrets
:
You can choose between two methods, 3a (automatic) or 3b (manual):
WARNING: This method is experimental, and may not work. If it doesn't work, skip to step 3b.
The following commands will create the necessary environment variables and attempt to automatically register the node.
Attestation certificate should have been created by the previous step
Verify the certificate is valid. A 64 character registration key will be printed if it was successful.
secretd
Configure secretd
. Initially you'll be using the bootstrap node, as you'll need to connect to a running node and your own node is not running yet.
If you already have a wallet funded with SCRT
, you can import the wallet by doing the following:
Otherwise, you will need to set up a key. Make sure you back up the mnemonic and the keyring password.
Register your node on-chain
2. Pull & check your node's encrypted seed from the network
3. Get additional network parameters
These are necessary to configure the node before it starts.
From here on, commands must be ran on the full node.
In order to be able to handle NFT minting and other Secret Contract-heavy operations, it's recommended to update your SGX memory enclave cache:
minimum-gas-price
ParameterWe recommend 0.0125uscrt
per gas unit:
Your node will not accept transactions that specify --fees
lower than the minimun-gas-price
you set here.
secret-node
:Note that the secret-node
system file is created when installing sgx.
You are now a now ready to finally sync the full node. 🎉.
secretd tendermint show-node-id
And publish yourself as a node with this ID:
Be sure to point your CLI to your running node instead of the bootstrap node
secretcli config node tcp://localhost:26657
If someone wants to add you as a peer, have them add the above address to their persistent_peers in their ~/.secretd/config/config.toml.
And if someone wants to use your node from their secretcli then have them run:
Unlike other Tendermint/Cosmos based daemons, secretd
cannot be built from source due to the SGX requirement. For other builds other than .deb
, see the .
Reading
RPC address of an already active node. You can use http://bootstrap.pulsar3.scrtlabs.com:26657
, or any other node that exposes RPC services. Alternate RPC nodes available in the
This guide assumes you've already installed the latest version of secretd and SGX. To setup an archive node, you must follow the instructions.
For more information on SGX, see instructions for and . See if you'd like a more comprehensive overview on what's happening in these steps.
If this step was successful, you can skip straight to .
The following steps should use secretd
be ran on the full node itself. To run the steps with secretd
on a local machine, there.
This will output your address, a 45 character-string starting with secret1...
. Copy/paste it to get some test-SCRT from . Continue when you have confirmed your account has some test-SCRT in it.
Also checkout by [ block pane ]
for fine tuning your machine for better uptime.
Go to to continue.
You can skip syncing from scratch or download a snapshot by to the current block.
To turn your full node into a validator, see .
Note: This documentation assumes you have followed the instructions for Running a Full Node for Testnet.
WARNING: This will erase your node database. If you are already running validator, be sure you backed up your config/priv_validator_key.json
and config/node_key.json
prior to running unsafe-reset-all
.
The state-sync configuration in ~/.secretd/config/app.toml
is as follows:
SNAP_RPC
variable to a snapshot RPCSet the state-sync BLOCK_HEIGHT
and fetch the TRUST_HASH
from the snapshot RPC. The BLOCK_HEIGHT
to sync is determined by finding the latest block that's a multiple of snapshot-interval.
WARNING: This will erase your node database. If you are already running validator, be sure you backed up your config/priv_validator_key.json
and config/node_key.json
prior to running unsafe-reset-all
.
It is recommended to copy data/priv_validator_state.json
to a backup and restore it after unsafe-reset-all
to avoid potential double signing.
This generally takes several minutes to complete, but has been known to take up to 24 hours.
Ensure your hardware is Hardware Compliance.
If you're running a local machine and not a cloud-based VM -
Go to your BIOS menu
Enable SGX (Set to "YES", it's not enough to set it to "software controlled")
Disable Secure Boot
Disable Hyperthreading
Make sure the SGX driver is installed. The following devices should appear:
If your kernel version if 5.11 or higher, then you probably already have the SGX driver installed. Otherwise - please update the kernel version. Also make sure that the user under which the node is supposed to run has privileges to access SGX:
First, you need to add the Intel repository to APT:
For Ubuntu 20.04, use this:
For Ubuntu 22.04, use this repository:
Next, install the necessary SGX libraries:
If your system has 5th Gen Intel® Xeon® Scalable Processor(s)
For the DCAP attestation to work, you'll need to register your platform with Intel. This is achieved by the following:
You can check the file /var/log/mpa_registration.log
, to see if the platform is registered successfully.
The Quote Provider library is needed to provide the data for DCAP attestation.The configuration file for it should can be found here:
/etc/sgx_default_qcnl.conf
If you're running a physical machine
The simplest would be to use the PCCS run by SCRTLabs. Modify the following parameters in the file:
You can set those parameters by the following command:
Cloud VPS providers
For cloud VPS providers, the cloud service providers may provide their own PCCS. Please see their documentation for more infomation.
Note: You'll need to restart the AESMD service each time the configuration is changed
Download and run the check-hw tool (included in the Release package). You should see the following:
That would mean all the above steps are ok, and you're good to go.
In case you see some error messages, but at the end the following:
That would mean there's a problem with DCAP attestation.
However the EPID attestation still works. Although you may technically run the node, it's strongly recommended to fix this. The EPID will be phased-out by Intel on April 2025.
To get a more detailed error info, run check-hw --testnet
This section will take you through the process of taking a node from fresh machine to full validator. The general steps are as follows:
`secretcli` is the Secret Network light client, a command-line interface tool for interacting with nodes running on the Secret Network. To install it, follow these instructions:
If you're running a local machine or bare-metal and not a cloud-based VM -
Go to your BIOS menu
Enable SGX (Software controlled is not enough)
Disable Secure Boot
Disable Hyperthreading (recommended)
If you are a node runner all you must do to install SGX is to save this as a script and run it.
Copy of raw script.
secretd init-enclave
To uninstall the Intel(R) SGX Driver, run:
The above command produces no output when it succeeds. If you want to verify that the driver has been uninstalled, you can run the following, which should print SGX Driver NOT installed
:
To uninstall the SGX SDK, run:
To uninstall the rest of the dependencies, run:
In order to become a validator, you node must be fully synced with the network. You can check this by doing:
This is the secret
wallet which you used **** to create your full node, and will use to delegate your funds to you own validator. You must delegate at least 1 SCRT (1000000uscrt) from this wallet to your validator.
If you get the following message, it means that you have no tokens, or your node is not yet synced:
(remember 1 SCRT = 1,000,000 uSCRT, and so the command below stakes 100 SCRT).
You should see your moniker listed.
(remember 1 SCRT = 1,000,000 uSCRT)
In order to stake more tokens beyond those in the initial transaction, run:
Currently deleting a validator is not possible. If you redelegate or unbond your self-delegations then your validator will become offline and all your delegators will start to unbond.
You are currently unable to modify the --commission-max-rate
and --commission-max-change-rate"
parameters.
Modifying the commision-rate can be done using this:
Unjailing
To unjail your jailed validator
Signing Info
To retrieve a validator's signing info:
Query Parameters
You can get the current slashing parameters via:
Query Parameters
You can get the current slashing parameters via:
or the node
If you wish to create an archive node, replace step 3 with .
Get the latest release of secretcli for your OS .
You can find alternate node endpoints in the , or run your own
See more details on how to use the CLI
Ensure your hardware is .
See for a guide how to test your setup.
When the value of catching_up
is false, your node is fully sync'd with the network. You can speed up syncing time by to the current block.
Copy/paste the address to get some test-SCRT from . Continue when you have confirmed your account has some test-SCRT in it.
Unlike other Tendermint/Cosmos based daemons, secretd
cannot be built from source due to the SGX requirement.
For other builds other than .deb
, see the Secret Network Github Releases.
secretd
The most common method for installing secretd
is the Secret Network package installer for Debian/Ubuntu:
This document details how to join the Secret Network secret-4
mainnet as a full node. Once your full node is running and synced to the last block, you can use it
Secret Network has strict Hardware Requirements, see Hardware Compliance. If your machine does not meet them, it will *NOT* work as a node.
Ubuntu/Debian host, recommended is Ubuntu 20.04 LTS or 22.04 LTS.
A public IP address, so that other nodes can connect to you.
Open ports TCP 26656 & 26657
Note: If you're behind a router or firewall then you'll need to port forward on the network device.
RPC address of an already active node. You can use any node that exposes RPC services, please see API Endpoints Mainnet (Secret-4).
secretd
This guide assumes you've already installed the latest version of secretd and SGX.
For more information on how to install SGX, see instructions for Install SGX.
If you need help with installing secretd, please take a look at Install secretd.
Choose a moniker for yourself, and replace <MONIKER>
with whatever name you like (could be some random string, or just how you like to name to node) below. This moniker is your public nickname of the node in the network.
This will generate the following files in ~/.secretd/config/
genesis.json
node_key.json
priv_validator_key.json
genesis.json
Initialize /opt/secret/.sgx_secrets
:
You can choose between two methods, automatic or manual:
WARNING: This method is experimental, and may not work. If it doesn't work, skip to manual registration.
The following commands will create the necessary environment variables and attempt to automatically register the node.
If this step was successful, you can skip straight to Optimization.
The attestation certificate should have been created by the previous step
Verify the certificate is valid. A 64-character registration key will be printed if it was successful.
If registration was NOT succesfull consider checking out the Registration troubleshoot help or contact a fellow validator on our discord.
secretd
The following steps should use secretd
be ran on the full node itself. To run the steps with secretd
on a local machine, set up the CLI there.
Configure secretd
. Initially you'll be using the bootstrap node, as you'll need to connect to a running node and your own node is not running yet.
If you already have a wallet funded with SCRT
, you can import the wallet by doing the following:
Otherwise, you will need to set up a key. Make sure you back up the mnemonic and the keyring password.
This will output your address, a 45 character-string starting with secret1...
.
Register your node on-chain
2. Pull & check your node's encrypted seed from the network
3. Get additional network parameters
These are necessary to configure the node before it starts.
From here on, commands must be ran on the full node.
In order to be able to handle NFT minting and other Secret Contract-heavy operations, it's recommended to update your SGX memory enclave cache:
Also checkout this document by block pane
for fine tuning your machine for better uptime.
minimum-gas-price
ParameterWe recommend 0.1uscrt
per gas unit:
Your node will not accept transactions that specify --fees
lower than the minimun-gas-price
you set here.
IAVL fast node must be disabled, otherwise the daemon will attempt to upgrade the database whil state sync is occuring.
secret-node
:Note that the secret-node
system file is created when installing sgx.
You are now a now ready to finally sync the full node. 🎉.
Go to Statesync or Quicksync / Snapshot to continue.
To sync to head quickly, please see Quicksync / Snapshot.
You can skip syncing from scratch or download a snapshot by Statesync to the current block.
secretd tendermint show-node-id
And publish yourself as a node with this ID:
Be sure to point your CLI to your running node instead of the bootstrap node
secretcli config node tcp://localhost:26657
If someone wants to add you as a peer, have them add the above address to their persistent_peers in their ~/.secretd/config/config.toml.
And if someone wants to use your node from their secretcli then have them run:
To turn your full node into a validator, see Joining Mainnet as a Validator.
After you completed these steps, you can check this by doing:
When the value of catching_up
is false, your node is fully sync'd with the network and ready to go.
This is the secret
wallet which you used **** to create your full node, and will use to delegate your funds to you own validator. You must delegate at least 1 SCRT (1000000uscrt) from this wallet to your validator.
If you get the following message, it means that you have no tokens, or your node is not yet synced:
WARNING: if you don't backup your key and your node goes down, you will lose your validator and have to start a new one.
Remember 1 SCRT = 1,000,000 uSCRT, and so the command below stakes 10 SCRT
You should see your moniker listed.
(remember 1 SCRT = 1,000,000 uSCRT)
In order to stake more tokens beyond those in the initial transaction, run:
Currently deleting a validator is not possible. If you redelegate or unbond your self-delegations then your validator will become offline and all your delegators will start to unbond.
You are currently unable to modify the --commission-max-rate
and --commission-max-change-rate"
parameters.
Modifying the commision-rate can be done using this:
To unjail your jailed validator
To retrieve a validator's signing info:
You can get the current slashing parameters via:
`secretcli` is the Secret Network light client, a command-line interface tool for interacting with nodes running on the Secret Network. To install it, follow these instructions:
Snapshots are compressed folders of the database to reach the current block quickly.
WARNING: This will erase your node database. If you are already running validator, be sure you backed up your priv_validator_key.json
prior to running the command. The command does not wipe the file. However, you should have a backup of it already in a safe location.
All of the above steps can also be done manually if you wish.
Reset your node.
This will ensure you connect to peers quickly.
Statesync is a module built into the Cosmos SDK to allow validators to rapidly join the network by syncing your node with a snapshot enabled RPC from a trusted block height.
This greatly reduces the time required for a node to sync with the network from days to minutes. The limitations of this are that there is not a full transaction history, just the most recent state that the state-sync RPC has stored. An advantage of state-sync is that the database is very small in comparison to a fully synced node, therefore using state-sync to re-sync your node to the network can help keep running costs lower by minimizing storage usage.
By syncing to the network with state-sync, a node can avoid having to go through all the upgrade procedures and can sync with the most recent binary only.
First, adjust the configuration to be compatible with state-sync:
IAVL fast node must be disabled, otherwise the daemon will attempt to upgrade the database whil state sync is occuring.
To ensure that state-sync works on your node, it has to look for the correct snapshots that the snapshot RPC provides.
SNAP_RPC is the RPC node endpoint that is used for statesyncing
Set the state-sync BLOCK_HEIGHT
and fetch the TRUST_HASH
from the snapshot RPC. The BLOCK_HEIGHT
to sync is determined by finding the latest block that's a multiple of snapshot-interval.
The output should be similar to:
This will erase your node database. If you are already running validator, be sure you backed up your config/priv_validator_key.json
prior to running unsafe-reset-all
.
It is recommended to copy the signing state of the node by coping data/priv_validator_state.json
and only running unsafe-reset-all
to avoid potential double signing.
The code below stops the node, resets the temporary directory and resets the node into a fresh state.
When state-sync fails, you can restart the process and try again using the condensed script below. This usually fixes some of the random problems with it:
To safe time, you can use this script to quickly init everything you need for statesync. Please be aware that this might be dangerous if you have a validator.
becoming a validator?
You can find help in Telegram
Visit the Secret Network Discord and ask in #node-discussion or #node-support for help
In order to become an active validator, you must have more stake than the . You may still execute the following steps, but you will not be active and therefore won't receive staking rewards.
In order to become a validator, you node must be fully synced with the network, using either the or .
Before creating your validator,
Get the latest release of secretcli for your OS .
You can find alternate node endpoints in the , or run your own \
See more details on how to use the CLI
You can either chose to use the or do it with the
Quicksync / snapshots are provided by .
using state-sync properly?
You can find help in Telegram
Visit the Secret Network Discord and ask in #node-discussion or #node-support for help
A complete to go command that should fit most needs can be found at . Be aware that this script can also fail or cause problems. In that case please ask for help in the channels above.
This documentation assumes you have followed the instructions for .
using statesync properly?
You can find help in Telegram
Visit the Secret Network Discord and ask in #node-discussion or #node-support for help
This generally takes several minutes to complete, but has been known to take up to 24 hours. To better help the process along, add .
Ensure you backup your validator before you migrate it. Do not forget!
If you don't have the mnemonics saved, you can back it up with:
This prints the private key to stderr
, you can then paste in into the file mykey.backup
.
To check on the new full node if it finished catching-up:
Only continue if catching_up
is false
To prevent double signing, you should stop the validator node before stopping the new full node to ensure the new node is at a greater block height than the validator node.
Please read about the dangers in running a validator.
The validator should start missing blocks at this point. This is the desired behavior!
On the validator node, the file is ~/.secretd/config/priv_validator_key.json
.
You can copy it manually or for example you can copy the file to the new machine using ssh:
After being copied, the key (priv_validator_key.json
) should then be removed from the old node's config
directory to prevent double-signing if the node were to start back up.
The new node should start signing blocks once caught up.
Overview
A coordinated group of validators (maximum: 80) secure the Secret Network. Each validator uses Tendermint, a Byzantine fault-tolerant Delegated Proof-of-Stake (DPoS) consensus engine. Each validator stakes their SCRT coins and coins from delegators to earn rewards by successfully running the protocol, verifying transactions, and proposing blocks. If they fail to maintain a consistent (downtime) and honest node (double-signing), slashing penalties will occur, resulting in coins deducted from their account.
All SCRT holders can become a Secret Network validator or delegator and participate in staking and governance processes.
For information on running a node, delegating, staking, and voting, please see the validator guide below and visit our governance documentation.
Here is a list of Hardware Hardware Compliance for running a validator.
For detailed information on how to set up and run a validator, see the Becoming A Validatorsection.
Slashing for downtime is based on actual block times and NOT theoretical block times, such as SignedBlocksWindow
and MinSignedPerWindow
network parameters. Validators signing less than MinSignedPerWindow blocks out of every SignedBlocksWindow will experience a downtime slash.
Parameters: 11250 blocks out of every 22500-blocks
For a block time of 6.8 seconds, it roughly translates to being up for less than 21.25 hours out of every 42.5-hour window.
For a block time of 6.4 seconds, it roughly translates to being up for less than 20 hours out of every 40-hour window.
Slashing of 0.01% of the validator and its delegators' staked SCRT
Jailing of validators for 10 minutes. Validators do not earn block rewards for the jailing period and must manually unjail their node with:
Slashing for double-signing is when the validator signs the same block twice. This happens most commonly during migration, and the original validator node is not shut off appropriately, and their priv_validator_key.json
is running on two machines at the same time. The best way to avoid double signing is by using a remote signer such as the TenderMint Key Management System (TMKMS) or Horcrux.
A validator signs the same block height twice
Slashing of 5% of the validator and its delegators' staked SCRT
Jailing forever (tombstoned) of the validator node
A tombstoned validator cannot earn block rewards anymore, and its delegators must re-delegate their SCRT to another validator
The Secret Network uses the same slashing penalties as Cosmos. Burning SCRT through slashing validators for downtime and/or double-signing discourages poor practices and dishonesty by protocol-recognized actors. If slashing occurs frequently, a validator may lose their ability to vote on future blocks for some time.
To add basic security to your node, we've provided a guide covering 2 simple tools.
Uncomplicated Firewall (UFW)
Key-based SSH authentication.
Within the #Cosmos, conversations around node security tend to start with whether or not you use backup servers, sentries, and a remote-signing key management solution. This does not see the forest for the trees. While those steps are certainly important, they are *final* security steps. We should instead be discussing the first steps you make when setting up a new Tendermint node; raise the floor of security, rather than the ceiling, if you will.
The following topics will be covered: 1. SSH Key Setup
2. Server Configuration
3. Setting up a Basic Firewall
4. Using Local CLI Machinesbas
When you receive your server, you will be provided a root user login, and a password. You’ll be inclined to log in with that login and password, but we have steps before we do that! We first want to create out ssh key as we’ll be disabling password login shortly.
An SSH (Secure Shell) key is a way to identify yourself as a user without using a password. It has 2 parts: the pubkey and private key. When you create the SSH key, you give your pubkey to a computer you wish to log into. You can then “show” the server your private key and it will admit you automatically. This makes it far more secure than a password, as then only you will have access to the server via your key.
Open Terminal
Generate the SSH key:
3. When you’re prompted to “Enter a file in which to save the key,” press Enter. This accepts the default file location.
Your SSH key is now created, but we have to add it to the agent for it to be usable.
Start the ssh-agent in the background
2. Open your SSH config file
3. Add the following text block to your file
4. Add your SSH key to the ssh-agent
Your SSH key is now set up! This only has to happen once, so you can skip this if you need to refer back to this document.
Start by checking the status of UFW.
2. Enable SSH
3. Enable p2p
This is the default p2p port for Tendermint systems, but if you’ve changed the port, you’ll need to update the ufw setting.
4. Enable UFW
5. Confirm UFW is enabled
Note that at any time you can disable ufw by doing:
Restart the aesmd.service
4. Restart secret-node.service
If you aren't seeing any blocks being produced, that likely means you don't have any active peers. To solve this:
Add seed nodes
2. Restart secret-node
You'll be tempted to add persistent_peers as well, but unless you have control over the peers, DO NOT add them. Peers change frequently and interfere with the built-in network peering protocol.
This is intended to be a very basic guide on Linux security practices. If you want to more in-depth information,
This document assumes you’re using a Mac. If you need instructions for Linux or Windows, see the
Generate SSH key
4. At the prompt, type a secure passphrase. For more information, see .”
Open ~/.ssh/config
Uncomplicated Firewall (UFW) is a program for managing a netfilter firewall designed for easy use. It uses a command-line interface (CLI) with a small number of simple commands and is configured with . UFW is available by default in all Ubuntu installations after 18.04 LTS, and features tools for intrusion prevention which we will cover in this guide.
Check UFW status
Confirm UFW is enabled
If you get this, generally your server has restarted erroneously. In order to fix it and get secret-node running again, you must reinstall sgx and reload the aesm.service. .
SSH keys, similarly to cryptocurrency keys, consist of public and private keys. You should store the private key on a machine you trust. The corresponding public key is what you will add to your server to secure it.
Be sure to securely store a secure backup of your private SSH key.
From your local machine that you plan to SSH from, generate an SSH key. This is likely going to be your laptop or desktop computer. Use the following command if you are using OSX or Linux:
Decide on a name for your key and proceed through the prompts.
Copy the contents of your public key.
Your file name will differ from the command below based on how you named your key.
Give the ssh folder the correct permissions.
Chmod 700 (chmod a+rwx,g-rwx,o-rwx) sets permissions so the user or owner can read, write and execute, and the Group or Others cannot read, write or execute.
Copy the contents of your newly generated public key.
Now log into the server that you want to protect with your new SSH key and create a copy of the pubkey.
Create a file and paste in the public key information you copied from the previous step. Be sure to save the file.
Now add the pubkey to the authorized keys list.
Once you've confirmed that you can login via the new key, you can proceed to lock down the server to only allow access via the key.
Edit sshd_config to disable password-based authentication.
Change PasswordAuthentication yes" to "PasswordAuthentication no" and then save.
Restart ssh process for settings to take effect.
For additional security node operators may choose to secure their SSH connections with FIDO U2F hardware security devices such as YubiKey, SoloKey, or a Nitrokey. A security key ensures that SSH connections will not be possible using the private and public SSH key-pair without the security key present and activated. Even if the private key is compromised, adversaries will not be able to use it to create SSH connections without its associated password and security key.
This tutorial will go over how to set up your SSH connection with FIDO U2F using a YubiKey, but the general process should work with other FIDO U2F security devices.
NOTE: More information on how to get started using a YubiKey can be found HERE. You should have a general understanding of how to use a YubiKey before attempting this ssh guide.
For SSH secured with FIDO U2F to work both the host and server must be running SSH version 8.2 or higher. Check what version of SSH is on your local machine, and your server by running:
It does not matter if there are mismatched versions between the host machine and server; as long as they are both using version 8.2 or higher you will be able to secure your ssh connection using FIDO U2F.
SSH key-pairs with FIDO U2F authentication use 'sk' in addition to the typical commands you would expect to generate SSH key-pairs with and support both ecdsa-sk and ed25519-sk.
YubiKeys require firmware version 5.2.3 or higher to support FIDO U2F using ed25519-sk to generate SSH key-pairs. To check the firmware version of a YubiKey, connect the YubiKey to your host machine and execute the following command:
To allow your host machine to communicate with a FIDO device through USB to verify attestation and assert signatures the libsk-fido2 library must be installed.
Generate an ed25519-sk key-pair with the following command with your YubiKey connected to your host machine (NOTE: you will be prompted to touch your YubiKey to authorize SSH key-pair generation):
You can now use your new ed25519-sk key-pair to secure SSH connections with your servers. Part of the key-pair is from the YubiKey, and is used to secure the SHH connection as part of a challenge-response from the devices.
It is CRUCIAL to backup your validator's private key. It's the only way to restore your validator in an event of a disaster. The validator private key is a Tendermint Key - a unique key used to sign consensus votes.
To backup everything you need to restore your validator, simply do the following
If you are using the software sign (which is the default signing method of tendermint), your Tendermint Key is located in ~/.secretd/config/priv_validator_key.json
.
Backup ~/.secretd/config/priv_validator_key.json
.
Backup ~/.secretd/data/priv_validator_state.json
.
Backup the self-delegator wallet. See the wallet section.
Or you can use hardware to manage your Tendermint Key much more safely, such as YubiHSM2.
Never save your validator’s keys on the remote server. You should be using your local machine and saving your keys on there to broadcast to the remote server.
In order to use a local CLI, you must:
Install the daemon on your local machine by going through the normal installation process
Set the daemon’s config
to the remote server
In this section we will cover:
Logging In
Creating a new user
Disable root login
Disable password login
When you provision a new server, you will be provided a username, password, and ip address. Generally that username will be root. Let’s log in with them now in the form of ssh username@ip
.
Initiate login to server
2. Type Yes
3. Enter password
You are now logged into root. However, we do NOT want this as an option, so let’s fix it.
Since we no longer want to be able to log in as root, we’ll first need to create a new user to log into.
Create a new user
You’re going to want to choose a unique username here, as the more unique, the harder it’ll be for a bad actor to guess. We’re going to use mellamo
.
You will then be prompted to create a password and fill in information. Don’t worry about the information, but make sure your password is complicated!
2. Give them sudo privileges
sudo is the name for “master” privileges, so we need to modify the user to add them to that group.
3. Verify user has sudo access
Disabling root login takes away an easy method for hackers to get in. The easiest way of accessing remote servers or VPSs is via SSH and to block root user login under it, you need to edit the /etc/ssh/sshd_config file.
From the remote server, open /etc/ssh/sshd_config
2. Save and exit sshd_config, then restart the service.
Return to you local machine.
2. Copy your ssh key to the server
3. Confirm you can login with just your SSH key
Done! You can now log in exclusively with your SSH key.
Now that you can log in with just your ssh key, you should now disable password login.
Return to your remote server, and open /etc/ssh/sshd_config again
2. Find ChallengeResponseAuthentication and set to no:
3. Next, find PasswordAuthentication set to no too:
4. Search for UsePAM and set to no, too:
5. Save and exit sshd_config, then restart the service.
Congratulations! You can only login with your ssh key now. Be sure to back it up in case something happens to your machine!
SSH into the server
Logged into root
Create user mellamo
Testing sudo privileges
Set PermitRootLogin to “no”
Log out of server
Copy keys
Log in with SSH key
Monitoring is inmensely important so to ensure the liveness and reliabilty of your infrastructure. If your validator is not signing blocks it will eventually get slashed losing you and your delegators some of their SCRT balance. Same for full nodes it is important they are able to serve queries as if they are down performance of dApps and other applications will be limited.\
Monitoring is best done by a dedicated piece of software that provides both analytics and alerts. Some of those options are laid out below so to help you set them up. Consider relying on more than 1 monitoring solutions and leverage external RPCs so to secure your setup even further.
Prometheus
Grafana
Docker
PagerDuty
Goaccess
Prometheus is a flexible monitoring solution in development since 2012. The software stores all its data in a time series database and offers a multi-dimensional data model and a powerful query language to generate reports of the monitored resources.
This tutorial makes no assumptions about previous knowledge, other than:
You are comfortable with a Linux operating system, specifically Ubuntu 20.04
You are comfortable being able to ssh into your node, as all operations will be done from the command line\
Start by checking the status of UFW.
Then proceed to configure your firewall with the following options, preferably in this order.
The order is important because UFW executes the instructions given to it in the order they are given, so putting the most important and specific rules first is a good security practice. You can insert UFW rules at any position you want to by using the following syntax (do not execute the following command when setting up your node security):
The example command above would be placed in the first position (instead of the last) of the UFW hierarchy and deny a specific IP address from accessing the server.
This sets the default to allow outgoing connections unless specified they should not be allowed.
This sets the default to deny incoming connections unless specified they should be allowed.
This allows SSH connections by the firewall.
This limits SSH login attempts on the machine. The default is to limit SSH connections from a specific IP address if it attempts 6 or more connections within 30 seconds.
Allow 26656 for a p2p networking port to connect with the Tendermint network; unless you manually specified a different port.
Allow 1317 if you are running a public LCD endpoint from this node. Otherwise, you can skip this.
Allow 26657 if you are running a public RPC endpoint from this node. Otherwise, you can skip this.
This enables the firewall you just configured.
At any point in time you can disable your UFW firewall by running the following command.
Uncomplicated Firewall (UFW) is a program for managing a netfilter firewall designed for easy use. It uses a command-line interface (CLI) with a small number of simple commands, and is configured with . UFW is available by default in all Ubuntu installations after 18.04 LTS, and features tools for intrusion prevention which we will cover in this guide.
Prior to using Prometheus, it needs basic configuring. Thus, we need to create a configuration file named prometheus.yml
The configuration file of Prometheus is written in YAML which strictly forbids to use tabs. If your file is incorrectly formatted, Prometheus will not start. Be careful when you edit it.
Open the file prometheus.yml
in a text editor:
Prometheus’ configuration file is divided into three parts: global
, rule_files
, and scrape_configs
.
In the global
part we can find the general configuration of Prometheus: scrape_interval
defines how often Prometheus scrapes targets, evaluation_interval
controls how often the software will evaluate rules. Rules are used to create new time series and for the generation of alerts.
The rule_files
block contains information of the location of any rules we want the Prometheus server to load.
The last block of the configuration file is named scape_configs
and contains the information which resources Prometheus monitors.
Our file should look like this example:
The global scrape_interval
is set to 15 seconds which is enough for most use cases.
We do not have any rule_files
yet, so the lines are commented out and start with a #
.
In the scrape_configs
part we have defined our first exporter. It is Prometheus that monitors itself. As we want to have more precise information about the state of our Prometheus server we reduced the scrape_interval
to 5 seconds for this job. The parameters static_configs
and targets
determine where the exporters are running. In our case it is the same server, so we use localhost
and the port 9090
.
As Prometheus scrapes only exporters that are defined in the scrape_configs
part of the configuration file, we have to add Node Exporter to the file, as we did for Prometheus itself.
We add the following part below the configuration for scraping Prometheus:
Overwrite the global scrape interval again and set it to 5 seconds. As we are scarping the data from the same server as Prometheus is running on, we can use localhost
with the default port of Node Exporter: 9100
.
If you want to scrape data from a remote host, you have to replace localhost
with the IP address of the remote server.
Tip: For all information about the configuration of Prometheus, you may check the configuration documentation.
Set the ownership of the file to our Prometheus
user:
Our Prometheus server is ready to run for the first time.
Start Prometheus directly from the command line with the following command, which executes the binary file as our Prometheus
user:
The server starts displaying multiple status messages and the information that the server has started:
Open your browser and type http://IP.OF.YOUR.SERVER:9090
to access the Prometheus interface. If everything is working, we end the task by pressing on CTRL + C
on our keyboard.
If you get an error message when you start the server, double-
check your configuration file for possible YAML syntax errors. The error message will tell you what to check.
The server is working now, but it cannot yet be launched automatically at boot. To achieve this, we have to create a new systemd
configuration file that will tell your OS which services should it launch automatically during the boot process.
The service file tells systemd
to run Prometheus as prometheus
and specifies the path of the configuration files.
Copy the following information in the file and save it, then exit the editor:
To use the new service, reload systemd
:
We enable the service so that it will be loaded automatically during boot:
Start Prometheus:
Your Prometheus server is ready to be used.
We have now installed Prometheus to monitor your instance. Prometheus provides a basic web server running on http://your.server.ip:9000
that provide access to the data collected by the software.
Download and Unpack Prometheus latest release of Prometheus:
The following two binaries are in the directory:
Prometheus - Prometheus main binary file
Promtool
The following two folders (which contain the web interface, configuration files examples and the license) are in the directory:
Consoles
Console_libraries
Copy the binary files into the /usr/local/bin/
directory:
Set the ownership of these files to the prometheus
user previously created:
Copy the consoles
and console_libraries
directories to /etc/prometheus
:
Set the ownership of the two folders, as well as of all files that they contain, to our prometheus
user:
In our home folder, remove the source files that are not needed anymore:
You will need to create new users for running Prometheus securely. This can be done by doing:
Create the directories for storing the Prometheus binaries and its config files:
Set the ownership of these directories to our prometheus
user, to make sure that Prometheus can access to these folders:
Install Grafana on our instance which queries our Prometheus server.
Enable the automatic start of Grafana by systemd
:
Grafana is running now, and we can connect to it at http://your.server.ip:3000
. The default user and password is admin
/ admin
.
Now you have to create a Prometheus data source: - Click the Grafana logo to open the sidebar. - Click “Data Sources” in the sidebar. - Choose “Add New”. - Select “Prometheus” as the data source. - Set the Prometheus server URL (in our case: http://localhost:9090/) - Click “Add” to test the connection and to save the new data source.
Download the latest version of Node Exporter:
Unpack the downloaded archive. This will create a directory node_exporter-1.2.2.linux-amd64
, containing the executable, a readme and license file:
Copy the binary file into the directory /usr/local/bin
and set the ownership to the user you have created in step previously:
Remove the leftover files of Node Exporter, as they are not needed any longer:
To run Node Exporter automatically on each boot, a Systemd service file is required. Create the following file by opening it in Nano:
Copy the following information in the service file, save it and exit Nano:
Reload Systemd to use the newly defined service:
Run Node Exporter by typing the following command:
Verify that the software has been started successfully:
You will see an output like this, showing you the status active (running)
as well as the main PID of the application:
If everything is working, enable Node Exporter to be started on each boot of the server:
As your Prometheus is only capable of collecting metrics, we want to extend its capabilities by adding Node Exporter, a tool that collects information about the system including and exposes them for scraping.
Collectors are used to gather information about the system. By default a set of collectors is activated. You can see the details about the set in the . If you want to use a specific set of collectors, you can define them in the ExecStart
section of the service. Collectors are enabled by providing a --collector.<name>
flag. Collectors that are enabled by default can be disabled by providing a --no-collector.<name>
flag.
Install Grafana on our instance which queries our Prometheus server.
Enable the automatic start of Grafana by systemd
:
Grafana is running now, and we can connect to it at http://your.server.ip:3000
. The default user and password is admin
/ admin
.
Now you have to create a Prometheus data source:
Click the Grafana logo to open the sidebar.
Click “Data Sources” in the sidebar.
Choose “Add New”.
Select “Prometheus” as the data source
Set the Prometheus server URL (in our case: http://localhost:9090/)
Click “Add” to test the connection and to save the new data source
Finally, we're going to install a basic dashboard for Cosmos SDKs. For further reference in these steps, see: https://github.com/zhangyelong/cosmos-dashboard
After restarting your node, you should be able to access the tendermint metrics(default port is 26660): http://localhost:26660
Append a job
under the scrape_configs
of your prometheus.yml
Copy and paste the Grafana Dashboard ID 11036
OR content of cosmos-dashboard.json, click on Load
to complete importing.
Set chain-id to secret-3
You're done!\
Clone the node_tooling repo and descend into the monitoring folder:
In the Prometheus folder, modify cosmos.yaml, replace NODE_IP
with the IP of your node. (If your node is on the docker host machine, use 172.17.0.1
)
Replace the default Prometheus config with the modified cosmos.yaml
You will need to install docker and docker-compose.
The following instructions assume Ubuntu 20.04 on an x86-64 CPU.
Test the installation:
Apply executable permissions to the binary:
Download the current stable release of Docker Compose:
Test the installation:
Install docker:
Setup the docker stable repository:
Add Docker’s official GPG key:
Update the apt package index and install packages to allow apt to use a repository over HTTPS:
Start the containers deploying the monitoring stack (Grafana + Prometheus + Node Exporter):
Login to Grafana at http://your-ip:3000
with username admin
and password admin
The containers will restart automatically after rebooting unless they are stopped manually.
The dashboard for Cosmos SDK nodes is pre-installed, to use it:
Enable Tendermint metrics in your secret-node
After restarting your node, you should be able to access the Tendermint metrics (default port is 26660): http://localhost:26660
If you did not replace NODE_IP
with the IP of your node in the Prometheus config, do so now. If your node is on the docker host machine, use 172.17.0.1
Login to Grafana and open the Cosmos Dashboard from the Manage Dashboards page.
Set the chain-id to secret-3
From here, you're going to want to set up alerts for if something happens with your node, which will be a follow-up document.
This is largely just a copy of scaleway's setup, but updated and customized for Secret Network.
Docker and Docker Compose will allow you to run the required monitoring applications with a few commands. These instructions will run the following:
Grafana on port 3000
: An open source interactive analytics dashboard.
Prometheus on port 9090
: An open source metric collector.
Node Exporter on port 9100
: An open source hardware metric exporter.
From the node_tooling/monitoring
directory:
Goaccess is a powerful tool when it comes to providing usage statistics for your endpoints.
This tutorial will guide you through configuring Nginx for logging, anonymizing logs, monitoring web traffic with GoAccess, and setting up log rotation for Nginx logs.
This guide is intended for intermediate users who are familiar with Linux, Nginx, and using the command-line interface.
Before configuring Nginx, install GoAccess, a real-time web log analyzer.
Update your package lists:
Install GoAccess:
The docker images expose the following ports:
3000
Grafana. Your main dashboard. Default login is admin\admin.
9090
Prometheus. Access to this port should be restricted.
9100
Node Exporter. Access to this port should be restricted.
Your secret node metrics on port 26660
should also be restricted.
If you followed the basic security guide, these ports are already restricted. You will need to allow the grafana port:
sudo ufw allow 3000
You can also allow access from a specific IP if desired:
sudo ufw allow from 123.123.123.123 to any port 3000
Configure Nginx to format logs and set up a server block.
Open the Nginx configuration file:
Add the following log format into your http group in nginx:
Warning: This logs the users IP address directly. It's not recommended to do it in this fashion, if possible anonymize the address as seen below.
(optional) Instead anonymize IP addresses in logs:
Configure a server block:
Test the new configuration:
Reload Nginx to apply changes:
Log rotation in Nginx is a process for managing log files to prevent them from becoming excessively large and consuming too much disk space. As Nginx continuously logs web requests, these files can grow rapidly. Without rotation, they can lead to performance issues and make log analysis more difficult. The default setting is for log rotation is daily, which means that the logs that goaccess can use for its reporting are also only daily. To increase that timeframe, do the following:
Edit log rotation configuration:
Add the configuration, please change the monthly to daily or weekly if you need daily or weekly rotation of the logs.
Apply the new rotation configuration:
Generate a HTML report:
If you wish to automate this, use crontab to generate recurring reports:
Open crontab for editing (use sudo, otherwise crontab will not access to the log file):
Add the line to automate hourly report generation:
To withdraw the delegator rewards:
Once you've submitted a delegation to a validator, you can see it's information by using the following command:
Example:
Or if you want to check all your current delegations with distinct validators:
On the Secret Network mainnet, we delegate uscrt
, where 1scrt = 1000000uscrt
. Here's how you can bond tokens to a validator (i.e. delegate):
Example:
<validator-operator-address>
is the operator address of the validator to which you intend to delegate. If you are running a full node, you can find this with:
Where <key-alias>
is the name of the key you specified when you initialized secretd
.
While tokens are bonded, they are pooled with all the other bonded tokens in the network. Validators and delegators obtain a percentage of shares that equal their stake in this pool.\
Once you begin an unbonding-delegation, you can see its information by using the following command:
Or if you want to check all your current unbonding-delegations with distinct validators:
Additionally, you can get all the unbonding-delegations from a particular validator:
Parameters define high level settings for staking. You can get the current values by using:
With the above command you will get the values for:
Unbonding time
Maximum numbers of validators
Coin denomination for staking
Example:
All these values will be subject to updates though a governance
process by ParameterChange
proposals.
There currently is in place a 21 days unbonding rule, during which no rewards are handed out.
If for any reason the validator misbehaves, or you just want to unbond a certain amount of tokens, use this following command.
The unbonding will be automatically completed when the unbonding period has passed.
Once you begin a redelegation, you can see its information by using the following command:
Or if you want to check all your current unbonding-delegations with distinct validators:
Additionally, you can get all the outgoing redelegations from a particular validator:
A staking Pool
defines the dynamic parameters of the current state. You can query them with the following command:
With the pool
command you will get the values for:
Not-bonded and bonded tokens
Token supply
Current annual inflation and the block in which the last inflation was processed
Last recorded bonded shares
A redelegation is a type delegation that allows you to bond illiquid tokens from one validator to another:
Here you can also redelegate a specific shares-amount
or a shares-fraction
with the corresponding flags.
The redelegation will be automatically completed when the unbonding period has passed.
You can also query all of the delegations to a particular validator:
Example:
Website: Microsoft Azure
Using Azure is not recommened anymore as of now because of higher pricing than bare-metals and not enough RAM (32GB is possible to use, but not recommended anymore).
When renting a compliant bare metal machine from a VPS provider, ensure you do not accept any chassis or CPU substitutes they propose, unless those substitutes are on the Hardware Compliance list.
Microsoft Azure is tested and confirmed working by the Secret Network Community.
To setup a node on Microsoft Azure do the following.
Visit the Azure Confidential Compute page here and click "Get Started"
Click "Get it now" on the following page and signup for a Microsoft Azure Account.
While provisioning your VPS be sure to have at least 500GB of premium SSD storage available.
After your confidential compute VM is deployed, continue with the node setup guide starting here.
General Overview
This section only covers some of the SecretCLI commands, for all commands please reference the SecretCLI documentation instead.
Website: phoenixNAP
Rent a VPS from them with any of the hardware that shows as working on the Hardware Compliance list.
Ensure that Hyperthreading & overclocking/undervolting are disabled in the bios.
Continue with the node setup guide starting here.
Alternatively, Eddie from FreshSCRTs is helping users expedite the delivery of their VPS as well as giving some upgrades from phoenixnap. You can pursue that by doing the following.
Signup for phoenixnap using this link.
Message Eddie your order number on telegram.