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...
SCRT Labs regularly updates a Secret Network API Registry containing information required to configure the secretcli.
To check the status of a node use:
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:
\
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:
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...
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.
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...
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:
If you are using an M1 or M3 chip, download MacOS-arm64, otherwise if you have an intel chip use secretcli-macOS. You can see what chip you have by viewing "about this Mac".
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.
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.
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.
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:
Note: To be able to correctly test multisig transactions you will need tokens owned by the multisig wallet. Get testnet tokens using the faucet.
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:
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 here.
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:
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.
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:
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 Node Runners page and look for the 'Slashing For Downtime' section.
See Slashing for the official Cosmos Network module documentation.
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.
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.
sync makes the client return a CheckTx response (default)
async makes the client return immediately
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 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
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 ensure each block is not over consuming resources, and that each block will be finalized on-chain. The cost of gas consumed during execution results in a fee where fees = gas * gas-prices.
If you are running a full node or a validator node, view the status by typing:
Example output for secretcli status | jq:
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.
As of V1.7 of Secret Network users can enable autocompounding SCRT staking with their respective validators.
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!
You can query the restaking situation per delegator and receive a list with validator addresses for which the user has turned this feature on.
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
when you delegate uscrt to a validator. These delegators can receive part of the validators fee revenue. To learn more read about the .
Learn more about the Restake feature
On the Secret Network mainnet, we delegate uscrt, where 1scrt = 1000000uscrt. Instructions can be found .
One can also query the restake-thresholddirectly. For now one can use a direct LCD CURL to get the information like: but a SecretCLI and Secret.JS query is being implemented.
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 Cosmos Token Model.
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:
Note: _ A list of validators on the pulsar-3 Secret Network testnet can be found here._
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:
\
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:
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.
Proposals can be submitted using secretcli tx gov submit-proposal.
Using secretcli tx gov draft-proposal can help prepare a proposal. The tool will create a file containing the specified proposal message and it also helps with populating all the required proposal fields. You can always edit the file after you create it using draft-proposal
To submit a proposal:
metadata example:
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:
Most cosmos-sdk modules allow changing their governance gated parameters using a MsgUpdateParams which is a new way of updating governance parameters. It is important to note that MsgUpdateParams requires all parameters to be specified in the proposal message.
We will use draft-proposal to help us create a proposal file that we will later submit.
After choosing the /cosmos.staking.v1beta1.MsgUpdateParams message, the applet will allow you to set the message fields and some other proposal details. Upon completion, the proposal will be available in the directory where you called the gaiad command inside the draft_proposal.json file.
Here is an example of the draft_proposal.json file:
Finally, we submit the proposal:
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 submit a community pool spend proposal, you also must provide a proposal file as its contents are less friendly to secretcli input:
We can createproposal.json using tx gov draft-proposal
To submit a software upgrade proposal use:
We can createproposal.json using tx gov draft-proposal
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 .
You can see another param-change example here:
distribution.baseproposerreward + distribution.bonusproposerreward < 1. See and for more info.
To read more go to the .
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
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:
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:
