Documents

Welcome to documents

You can navigate the range of documents related to specific features of the Causevest Network.

On this page you will find our introductory documents included a guide for new investors, a guide for charities/causes, a guide for potential partners and finally a guide for operators who want to work with the Causevest Network.


Get started

XCV Whitepaper




The Causevest Protocol is a fully functional Layer 1 blockchain with low node costs that uses votes via Causevest Coin to redirect transaction fees and other protocol income to good causes.


The blockchain is secured by Proof of Stake (PoS) and a unique reward mechanism called Proof of Cause (PoC). PoC randomly distributes rewards among users who support the network. This gives users who earn smaller amounts a chance to receive significant amounts of XCV, creating excitement for even small participants in a sustainable way.


To power both PoC and PoS, the protocol relies on self-sustaining revenue flows. A core flow comes from Layer 1 transaction fees, which are sent to a Network Income Pool and redistributed in a way that ensures the protocol can never "go bankrupt." While higher income leads to higher rewards, the system remains stable even if income temporarily decreases.


The Causevest Protocol includes a range of enhanced security features, such as multisig wallets and time-reversible vaults, providing users with additional protection in case of accidental or unauthorized transactions.


To reduce the risk from external threats like exchange hacks, we've added an extra security layer called Proof of Forgiveness (PoF). In emergencies, vault owners can transfer their vault balance to the PoF pool, reveal an encrypted tag to prove ownership, and recover their funds. 




Causevest Coin: A New Idea

 

Causevest Coin (XCV) is a standalone (“layer 1”) cryptocurrency protocol that incentivises good. Causevest is not reliant on any individual business’s success; it does not depend on any other coin’s technology to function and has use cases based around the core ideology of disruptive altruism. 


Causevest builds on the idea of disrupting legacy banking systems and paves the way for a new wave of socially conscious cryptocurrency users around the world.


We want owning XCV to be easy and fun. Our blockchain creates some clear use cases and encourages light competition between users to define which causes should receive the most from our network. The mechanisms within the network enable capital to flow to good causes around the world. As soon as you buy or sell this coin, you have already helped a good cause – it is as simple as that.


There are more than 1000 cryptocurrencies, many of which solve a variety of problems, but the fact remains that much of the technology isn't focused on helping people beyond just making money and speculation. Most tokens are, in essence, socially useless.


The Causevest protocol produces a cryptocurrency you can be proud to own. With it, you can transact anonymously, securely and quickly while effortlessly helping people around the world at the same time. 


It is easy to forget that many early adopters of Bitcoin were altruistic in nature. We believed in the idea of creating a new type of cryptocurrency that could scale globally for the common good. Causevest is a new idea and a new type of money that is in its very nature designed to do good, regardless of the desires of the individuals using the coin.





Causevest Coin (XCV) Technical USPs At A Glance



  • The Causevest Protocol has powerful inbuilt functionality that is both simple, robust, and powerful. We give the user the power to do what they need to do with safety and security.


  • The Causevest Neighborhood system gives XCV transactions scalability, privacy, and lets subsets of the network have their own smart contracts. Within a neighbourhood any contracts are fully compostable. 


  • An independent chain means full control of where the transaction fees go, which allows us to have a bigger impact on causes our network users support. Fund flows are integrated into the very heart of the network.


  • The Causevest Proofs system allows many actions to receive a reward on chain - even those that would be too small to reward normally. The built in RANDAO system make sure randomly distributed proofs rewards are publicly fair and not manipulated.


  • The Causevest Pool Flow system gives detailed public information on the protocol’s fund flows that keeps the system completely transparent while making sure the causes and infrastructure can get the funds they need and react to changing income levels in the Network.


  • Like savings in a bank account, users can generate income in XCV by running nodes or by working to maintain the network in order to earn ‘Proof of Cause’ rewards.





Partners Guide

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam varius non velit a tristique. Suspendisse eu ornare eros. Mauris ac ipsum iaculis, mollis urna a, gravida nunc. Donec lacus quam, porttitor a sollicitudin vel, tempus ut nisi.


PART 01
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam varius non velit a tristique. Suspendisse eu ornare eros. Mauris ac ipsum iaculis, mollis urna a, gravida nunc. Donec lacus quam, porttitor a sollicitudin vel, tempus ut nisi.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam varius non velit a tristique. Suspendisse eu ornare eros. Mauris ac ipsum iaculis, mollis urna a, gravida nunc. Donec lacus quam, porttitor a sollicitudin vel, tempus ut nisi.


PART 02
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam varius non velit a tristique. Suspendisse eu ornare eros. Mauris ac ipsum iaculis, mollis urna a, gravida nunc. Donec lacus quam, porttitor a sollicitudin vel, tempus ut nisi.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam varius non velit a tristique. Suspendisse eu ornare eros. Mauris ac ipsum iaculis, mollis urna a, gravida nunc. Donec lacus quam, porttitor a sollicitudin vel, tempus ut nisi.

Operator Guide

Part 1

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nam varius non velit a tristique. Suspendisse eu ornare eros. Mauris ac ipsum iaculis, mollis urna a, gravida nunc. Donec lacus quam, porttitor a sollicitudin vel, tempus ut nisi.





2024 New Test

This is the title of a test documents page 





here are three primary types of partners:

 

1.    Corporate Partners: Businesses interested in giving to the charitable causes on our network.  These may or may not be businesses that already give to charitable causes.  Regardless, we encourage all corporate partners to foster an interest in charitable giving and donate to charitable causes on our network.

 

2.    Investment Partners: Anyone who we give capital to for reinvestment.  By reinvesting this capital, our investment partners generate additional income for the network.

 

3.    Supporter Operators: People who fundraise directly for charitable causes on the network.  They fundraise directly for the Causevest foundation as well.




I wonder if this will show up on the ICO site ?



Lets add a linkAdd a link






test for colour change



I'd appreciate some additional information about your project, including:


test from paste


CLI Read ME

causes-guide-img

# Causevest Node CLI Access and Account Handler (Keychain) ## Global Flags - Flags must be set before the first on-flag command (e.g. `./keychain -nopass newaccount` not `./keychain newaccount -pass`). - `nopass`: a boolean flag defaulted to `false`. If `nopass` is true, the function will assume the password to be set is the empty slice and will not prompt the user to enter a password. This can be used to execute CLI commands via middleware without having enter a password through `terminal.ReadPassword(int(os.Stdin.Fd()))`. - `pass`: a string flag defaulted to `""`. If `pass` is set to a non-empty string, functions that require a password will use the flag value instead of prompting the user to enter a password. If no password has been set, functions that usually require a password will not ask for or use one and the `pass` value is ignored. - `nonewpass`: a boolean flag defaulted to `false`. Certain functions, such as `changepassword` may require more then one password (`changepassword` requires the current password and the password to be changed to). If the second password is to be empty (not set) then `-nonewpass` should be set. - `newpass`: a string flag defaulted to `""`. If `newpass` is set to a non-empty string, functions that require entering a second password will use the flag value instead of prompting the user to enter a password. - `seed`: a string flag defaulted to `""`. If `seed` is set to a non-empty string then `restoreaccount` and `checkseedwords` will use the `seed` value instead of prompting the user to enter a seed phrase. - `json`: a boolean flag defaulted to `false`. If `json` is set to true, the output any any errors will as a single JSON formatted string output to either `stdout` or `stderr`'. All JSON errors are formatted as the following JSON object: `{"error":"error string"}` ## Account Functions: ### `newaccount` - No arguments - Accepts 3 flags: `nopass`, `pass` and `json` Creates a new account and prompts the user to encrypt the account with a password. Outputs the seed words to terminal. Creates the account bboltdb file in `./accounts/account$num.dat` where `$num` is the account number. The account numbers are increases monotonically starting from 1. Finally, the new account is attached as the current main account. JSON return object names: - `success`: bool, true if there was no issues with creating the account - `seedwords`: string, the list of seed words that generated the account ### `restoreaccount` - No arguments - Accepts 4 flags: `nopass` `pass` `seed` and `json` Prompts the user for their seed phrase if `seed` is not set then a password if `pass` is not set and `nopass` is true. Then uses that seed phrase to create a new account at the next empty account number and encrypts it with the given password, then attaches the account. JSON return object names: - `success`: bool, true if there was no errors restoring the account - `account`: string, hash of account restored ### `getseedwords` - No arguments - Accepts flags: `pass` and `json` Prompts the user for their password if necessary, then outputs their `seedphrase` to the terminal. JSON return object names: - `seedwords`: string, the list of seed words that generated the account ### `checkseed` - No arguments - Accepts flags: `seed` and `json` Prompts the user for a seed phrase, then outputs if the input seed phrase is valid. JSON return object names: - `success`: bool, true if the keychain was able to check the seedphrase successfully. Note that a success here does NOT mean the seed is valid. - `seed_valid`: bool, true if the seedphrase is valid and false otherwise ### `listaccounts` - No arguments - Accepts flag: `json` Lists the available accounts, their number and their tag (first 6 characters of their account hash) along with which account is currently attached JSON return object names: - `accounts`: array, the list of accounts. Each account has: + `number`: int, the account number + `hash`: string, the account hash + `active`: bool, true if this is the active account and false otherwise ### `setactiveaccount` - Takes 1 `integer` argument - the account number - Accepts `json` flag Attempts to set the active attached account to the account number given. Returns error if that account does not exist. JSON return object names: - `success`: bool, true if the account was successfully attached - `number`: int, number of the attached account - `hash`: string, hash of the attached account ### `changepassword` - No arguments - Accepts `nopass` `nonewpass` `pass` `newpass` and `json` flags Prompts the user for the password of the current attached account, if any, and a new password, which may also be empty. The current account is then recreated with the new password and moved into the old account's place. JSON return object names: - `success`: bool, true if the password was successfully changed ## Basic Information Functions: ### `getbalance` - No arguments - Accepts flag: `json` Sends account information to the node and then queries the node for unspent UTXOs that can currently be spent by the current active account. It returns your total XCV balance, your account tag, your currently spendable XCV, and your validator balance. JSON return object names: - `account_hash`: string, the hash of the account - `total_balance`: decimal, the total - `spendable_now`: decimal, the amount in XCV that is currently spendable - `pending_balance`: decimal, the amount in XCV that is unvaulting into this account - `vault_balance`: decimal, the amount in XCV that is currently locked in vaults you can unvault - `validator_balance`: decimal, the amount in XCV that is currently locked in validators ### `getutxos` - No arguments - Accepts flag: `json` Queries the node for unspent UTXOs the node has on any accounts that have queried it. Returns the number of UTXOs, the account tag of each one, what kind of UTXO it is, it's value and it's unique identifier (fingerprint) along with the addresses that can spend it. JSON return object names: - `utxos`: array of UTXO objects, each of which has: + `utxo_fingerprint`: string, the UTXO's unique fingerprint + `account_hash`: string, account hash the UTXO belongs too + `utxo_type`: string, a string labeling the type of UTXO + `utxo_value`: decimal, the amount in XCV that is the value of the UTXO + `addresses_can_spend`: array of strings, the encoded addresses that can spend the UTXO ### `getutxosfull` - No arguments - Accepts flag: `json` Similar to `getutxos` except provides more information for each UTXO: the full account hash, the transaction hash for each UTXO, the output number, the total amount of coins, complete scriptlock, addresses that can spend, and what kind of address can spend it (single key, vault, etc) JSON return object names: - `total_balance`: decimal, total amount in XCV that you own - `utxos`: array of UTXO objects, each of which has: + `utxo_fingerprint`: string, the UTXO's unique fingerprint + `account_hash`: string, account hash the UTXO belongs too + `txn_hash`: string, the hash of the txn that generates this unspent output + `output_num`: int, the output number of the txn + `utxo_value`: decimal, the amount in XCV that is the value of the UTXO + `scriptlock_hex`: string, the hexidecimal encoded output scriptLock + `addresses_can_spend`: array of strings, the encoded addresses that can spend the UTXO + `utxo_type`: string, a string labeling the type of UTXO + `vault_level`: int, the vault level this utxo is unvaulting from. Zero mean it is not unvaulting + `vault_lock_time`: int, the inital vault lock time in blocks this utxo is unvaulting from. Zero mean it is not unvaulting + `unvaulting_time_remaining`: int, the currently remaining vault lock time in blocks before there is no risk of this utxo being reverted ### `getnotifications` - No arguments - Accepts flag: `json` Activates the notification handler and binds it to the node. This process will then remain open and the node can push notifications to the keychain which can then output these notifications as json strings JSON return object names: - `notification`: the notification struct has objects below + `account`: string, the account relavent to the notification. Empty for node-wide notifcations like syncing status + `type`: int, the notification's type integer + `category`: string, a name describing the notification's category + `text`: string, the text of the notification + `time`: int, the Unix timestamp of the notification + `txn_info`: bytes, the json-Marshalled NotifTxnInfo for a txn + `success`: bool, true if the transaction was a success + `hash`: string, the transaction hash + `type`: string, the transaction type string + `sync_info`: bytes, the json-Marshalled syncinfo for a txn + `syncing`: bool, true while the node is in a synicing state of a significant number of blocks + `sync_type`: string, the type of syncing the node is undergoing. Fast and Full are the two options + `sync_progress`: float, the % progress of the syncing ## Basic Transaction Functions: ### `broadcasttxn` - Requires 1 argument: the signed json-marshalled hex encoded transaction string - Accepts flag -json This command takes the hex string generated by transaction generating commands with the -json flag set and broadcasts it to the node. For CLI-interactive commands this happens automatically but when in -json mode the encoded transaction is passed back to the user in order to give space for the user to review the transaction before executing it. JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `simplesend` - Requires 3 arguments: amount `sent`, `fee`, and `address` (bech32 encoded) - Accepts flags: `pass` and `json` This command attempts to build, sign and broadcast a transaction that sends `amount` to address `address` with `fee` as the fee. It intelligently selects unspent UTXOs to send the total amount and creates change if necessary. It prioritizes simple (P2PKH) addresses over vaults and prompts the user if they want to spend a vault address unless `-json` is set. Change addresses are created on the fly if they are needed and if a vault address is used as an input, a vault with the longest unvaulting of vaults used in the input will be used for change. Returns an error if it cannot create the transaction. Note that when using the -json flag, it does not broadcast the transaction automatically, but instead returns the signed transaction hex. The signed hex can be broadcast using the `broadcasttxn` RPC JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `simplesendpool` - Requires 3 arguments: amount `sent`, `fee`, and `poolname` (bech32 encoded) - Accepts flags: `pass` and `json` This command attempts to build, sign and broadcast a transaction that sends `amount` to pool `poolname` with `fee` as the fee. It intelligently selects unspent UTXOs to send the total amount and creates change if necessary. It prioritizes simple (P2PKH) addresses over vaults and prompts the user if they want to spend a vault address unless `-json` is set. Change addresses are created on the fly if they are needed and if a vault address is used as an input, a vault with the longest unvaulting of vaults used in the input will be used for change. Returns an error if it cannot create the transaction. Note that when using the -json flag, it does not broadcast the transaction automatically, but instead returns the signed transaction hex. The signed hex can be broadcast using the `broadcasttxn` RPC JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `getproofs` - No arguments - Accepts flag: `json` This command gets the current proofs for addresses owned by this account JSON return object names: - `proofs`: array of proofs and the addresses associated with them + `address`: string, the bech32 encoded address string + `earned_proofs`: int, the earned proofs (in Clo) this address has + `earned_claimable`: int, the XCV (in Clo) that this address can claim from the earned pool + `height_of_closest_expiry`: int, the block height that earned claims begini expiring + `purchased_proofs`: int, the XCV (in Clo) this address has + `purchased_claimable`: int, the XCV (in Clo) this address can claim from the purchaser pool (purchased proofs never expire) ### `simplebuyproofs` - Requires 3 arguments: amount `sent`, `fee`, and `address` (bech32 encoded) - Accepts flags: `pass` and `json` This command attempts to build, sign and broadcast a transaction that buys `amount` proofs for `address` with `fee` as the fee. It intelligently selects unspent UTXOs to send the total amount and creates change if necessary. It prioritizes simple (P2PKH) addresses over vaults and prompts the user if they want to spend a vault address unless `-json` is set. Change addresses are created on the fly if they are needed and if a vault address is used as an input, a vault with the longest unvaulting of vaults used in the input will be used for change. Returns an error if it cannot create the transaction. Note that when using the -json flag, it does not broadcast the transaction automatically, but instead returns the signed transaction hex. The signed hex can be broadcast using the `broadcasttxn` RPC JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `simpleredeemclaims` - Requires 2 arguments:`fee`, and `address` (bech32 encoded) - Accepts flags: `pass` and `json` This command attempts to build, sign and broadcast a transaction that redeems all of the outstanding claims `address` has in both purchased and earned proofs with `fee` as the fee. Returns an error if it cannot create the transaction. Note that when using the -json flag, it does not broadcast the transaction automatically, but instead returns the signed transaction hex. The signed hex can be broadcast using the `broadcasttxn` RPC JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `specsend` - Requires 4 arguments: a string list of UTXOs fingerprints (see `getutxos` command to get fingerprints) to use as inputs, the amount, the fee, and the receiver address. - Accepts flags: `pass` and `json` This command attempts to build, sign, and broadcast a transaction that sends `amount` to address `address` with `fee` as the fee using the UTXO fingerprints given. It creates change the same way `simplesend` does. Returns an error if it cannot create the transaction. Note that when using the -json flag, it does not broadcast the transaction automatically, but instead returns the signed transaction hex. The signed hex can be broadcast using the `broadcasttxn` RPC JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `poolwithdraw` - Requires 4 arguments: the `poolname` as a string, the `amount` to withdraw, the `fee`, and the receiver `address`. - Accepts flags: `pass` and `json` This command attempts to build, sign, and broadcast a transaction that withdraws `amount` from pool `poolname` to address `address` with `fee` as the fee. Returns an error if it cannot create the transaction. Note that withdrawing from a pool this way is unusual, most accounts cannot do this. Also note that when using the -json flag, it does not broadcast the transaction automatically, but instead returns the signed transaction hex. The signed hex can be broadcast using the `broadcasttxn` RPC JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `listaddrs` - Accepts `json` flag Returns a list of your most recent simple and vault addresses. If called with `json` flag, returns all of your addresses, the same as `listalladdrs` command. JSON return object names: - `simple_addresses`: string array, list of simple addresses - `vault_addresses`: string array, list of vault addresses ### `listalladdrs` - Accepts `json` flag Returns a list of all of your simple and vault addresses. JSON return object names: - `simple_addresses`: string array, list of simple addresses - `vault_addresses`: string array, list of vault addresses ### `newaddr` - Accepts `pass` and `json` flags Creates a new address and returns a list of your most recent addresses (including this one) using `listaddrs`. If `json` is enables, just returns the JSON object. JSON return object names: - `success`: bool, returns true if successful - `address`: string, the new address created ### `checkaddress` - Requires 1 argument: the bech32 encoded `address` - Accepts `json` flags Creates a new address and returns a list of your most recent addresses (including this one) using `listaddrs`. If `json` is enables, just returns the JSON object. JSON return object names: - `address`: string, the address that was checked - `valid`: bool, returns true if the address above was valid and false otherwise ### `stake` - Accepts `pass` and `json` flags Sends the node a message to stake with its known accounts and sends contact information for the location of the block and reward txn signers. If this message goes through successfully, the process then starts the block signer, which listens for incoming blocks. When it receives a block or a reward transaction, it attempts to sign it using a key it has. If this is successful, it sends the block or reward transaction back to the node over RPC to be broadcast to the rest of the network. This function remains active indefinitely, listening for incoming blocks and must remain active to continue generating blocks. Note that the node must be informed of your accounts and balances beforehand by running the `getcoins` or `getutxos` command prior to starting staking. JSON return object names: - `success`: bool, returns true when a new block is successfully generated - `generated_block_header`: block header, returns the json-encoded block header for the newly generated block ### `getstakeinfo` - Accepts `json` flag Queries the node for its current staking information. JSON return object names: - `is_staking`: bool, true if the node current is staking with an account - `staking_account`: string, the hex hash of the staking account - `block_sign_ip_port`: string, the IP and port that is currently being use to sign blocks - `reward_txn_sign_ip_port`: string, the IP and Port that is currently being used to sign the reward transaction for creating a block ### `stopstake` - Accepts `json` flags Sends the node a message to stop staking and sending unsigned blocks. This does not stop any block signing processes that may be active; these need to be terminated separately. JSON return object names: - `success`: bool, returns true if successful ## Vault Transaction Functions: ### `newvaultaddr` - Accepts `json` and `pass` flags - Requires integer 1 argument: the unvaulting time, in blocks, of the vault address to be created. Note that the minimum time is 15, the maximum time is 25,000 and each block is on average 2 minutes apart. JSON return object names: - `success`: bool, returns true if successful - `vault_addr`: string, the newly created vault address ### `importvaultaddr` - Accepts `json` flag - Requires 1 string argument: the full vault address to be added This command adds the given vault address to the internal list of addresses that belong to this accounts. This command does NOT add any keys required to spend the vault address. It only allows the address to show up on your list of known vault addresses and receiving coins into this address without having the revert key as part of this account will not trigger a warning. JSON return object names: - `success`: bool, returns true if successful - `vault_addr`: string, the newly created vault address ### `revertunvault` - Accepts `json` and `pass` flags - Requires 2 arguments: the UTXO fingerprint to be reverted and the fee This command reverts an unvaulting transaction. The vault UTXO is restored to its previous state minus the fee. Once a transaction is reverted, another transaction cannot be sent from that vault using the same key or lower for the next 10 blocks. For example, if an unvaulting transaction is created using the spend key and then reverted, the spend key cannot do another unvaulting transaction for 10 blocks, but the revert key could start an unvaulting immediately. To make an unvaulting transaction using the revert key, use the `revertkeysend` command. Note that when using the -json flag, it does not broadcast the transaction automatically, but instead returns the signed transaction hex. The signed hex can be broadcast using the `broadcasttxn` RPC JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `revertkeysend` - Accepts `json` and `pass` flags - Requires 4 arguments: a vault UTXOs fingerprint (see `getutxos` command to get fingerprints) to use as the input, the amount, the fee, and the receiver address. This command creates an unvaulting transaction for the given vault using the higher level revert key instead of the spend key (which is what `simplesend` and `specsend` use). Using the revert key in this manner prevents the transaction from being reverted using the spendkey, and can be used to move your coins to safety if the spend key has been compromised. The transaction can be reverted as normal using the revert key. Note that when using the -json flag, it does not broadcast the transaction automatically, but instead returns the signed transaction hex. The signed hex can be broadcast using the `broadcasttxn` RPC JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `vaultpurge` - Accepts `json` and `pass` flags - Requires 1 argument: the `address` to purge This command purges all of the coins in the given vault address (any number of UTXOs) into the proof of forgiveness pool. This cannot be reversed. Execute with caution. JSON return object names: - `success`: bool, true if purge was successful ### `tagvault` - Accepts `json` and `pass` flags - Requires 3 argument: the `memo` string, the `fee` amount and the empty vault `address` (bech32 encoded) This command tags the given empty vault `address` with an encrypted form of the `memo` string using the tip `fee`. JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `gettags` - Accepts `json` and `pass` flags - Takes no arguments This command tags the given empty vault `address` with an encrypted form of the `memo` string using the tip `fee`. JSON return object names: - `addresses_with_tags`: array of tagged addresses: + `txn_hash`: string, hex transaction hash + `address`: string, bech32 encoded address + `memo`: string, decrypted memo string ### `maketagproof` - Accepts `json` and `pass` flags - Requires 1 argument: the `address` to make a proof for This command takes a previously tagged vault address and makes a proof that the address was indeed tagged and what the memo was. Since the tag of a vault cannot be changed while it has coins in it, an attacker cannot change the tag and the user can reveal it along with the tag proof to help recover their funds from the Proof of Forgiveness pool. JSON return object names: - `tagged_address`: string, the bech32 encoded address that was tagged - `encoded_proof_of_inclusion`: string, the hex encoded Merkle proof the tag transaction was included in a block ### `verifytagproof` - Accepts `json` and `pass` flags - Requires 1 argument: the hex encoded `tag proof` to make a proof for This command verifies a previously created tag proof to ensure it was included and that its memo is unchanged. JSON return object names: - `proof_verified`: bool, true if the proof was correct - `address_tagged`: string, the address that was tagged - `blockheight_tagged`: int, the block height the tag was applied - `memo`: string, the memo that was storied in the tag ## Cause Functions: ### `createcause` - Accepts `json` and `pass` flags - Requires 3 arguments: the bech32 encoded address to be tagged as a cause address, an integer >0 and < 255 for the cause category and an integer for the donation limit for the cause. This command takes a given address and tags it as a cause address. This requires paying the create cause fee. If `json` is not set, the user will be required to confirm that they do want to pay the create cause fee and make a new cause. Each address can only be turned into a cause address once. The node will not accept the transaction if it is already a cause. Note that when using the -json flag, it does not broadcast the transaction automatically, but instead returns the signed transaction hex. The signed hex can be broadcast using the `broadcasttxn` RPC JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `getmycauses` - Accepts `json` flag - Takes no arguments This command returns a list of cause addresses you can spend. JSON return object names: - `causes`: an array of cause info containing: + `cause_hash`: string, the cause's hash + `category_byte`: byte, the cause's category byte + `cause_address`: string, the cause's address + `cause_donations`: string, causes's total donations received in XCV + `cause_donation_target`: string, the cause's donation target in XCV + `cause_donors`: string, the cause's number of donors + `cause_votes`: string, the total votes the cause is receiving + `cause_claims`: string, the total amount of unclaimed XCV the cause is entitled to. + `cause_start_height`: int, the cause's start height in block + `cause_end_height`: int, the cause's end height. Zero implies the end height has not been set yet. ### `getnetworkcauses` - Accepts `json` flag - Takes no arguments This command returns a list of all of the causes in the network with information about them, such as category, liveness, donations and JSON return object names: - `causes`: an array of cause info containing: + `cause_hash`: string, the cause's hash + `category_byte`: byte, the cause's category byte + `cause_address`: string, the cause's address + `cause_donations`: string, causes's total donations received in XCV + `cause_donation_target`: string, the cause's donation target in XCV + `cause_donors`: string, the cause's number of donors + `cause_votes`: string, the total votes the cause is receiving + `cause_claims`: string, the total amount of unclaimed XCV the cause is entitled to. + `cause_start_height`: int, the cause's start height in block + `cause_end_height`: int, the cause's end height. Zero implies the end height has not been set yet. ### `removecause` - Accepts `json` and `pass` flags - Takes two arguments, the causehash to remove and the transaction fee This command attempts to make a removecause transaction for the given causehash if possible. The given causehash must be saved to the account so run scancauses to make sure you have the cause first. Once the cause is removed, scancauses must be run to purge the removed cause from the account database once the transaction is confirmed and the cause is removed from the chain. Note that removing a cause and registering the same cause can yield vote loss. Note that when using the -json flag, it does not broadcast the transaction automatically, but instead returns the signed transaction hex. The signed hex can be broadcast using the `broadcasttxn` RPC JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string ### `getcategorylist` - Accepts `json` flag - Takes no arguments This command returns the mapping of cause category numbers to cause category names so that the number can be given its name. This is a lookup table of categories JSON return object names: - `current_category_list`: array of category info + `category_name`: string, the category name + `category_number`: int, the number of the category with that name ### `getdatashare` - Accepts `json` flag - Takes one argument: the comma separated list of cause or nominee hashes to get Pulls SupplimentalInfo from the node for each cause or nominee hash given. If one is not found, returns an empty SupplimentalInfo in its place. JSON return object names: - `cause_info_data`: array, the cause's info: + `cause_hash`: string, the hash of the cause + `cause_info`: cause info: + `title`: string, the title of the cause + `contact_info`: string, the cause's contact info + `description`: string, the description of the cause - `nominee_info_data`: array, the nominee's info: + `nominee_hash`: string, the nominee's hash + `nominee_info`: nominee's info: + `nominee_name`: string, the nominee's name + `contact_info`: string, the nominee's contact info + `avatar_int`: int, the nominee's avatar integer + `focus_catagories`: int array, the nominee's focus categories + `nominee_description`: string, the nominee's description ### `getremotedatashare` - Accepts `json` flag - Takes one argument: the comma separated list of cause hashes to get Requests the node ask its peers for any updated SupplimentalInfo for the given cause hashes. Only returns data that has been updated from peers, not data that the node already had, use `getcausesdata` to query the node's current storage. JSON return object names: - `cause_info_data`: array, the cause's info: + `cause_hash`: string, the hash of the cause + `cause_info`: cause info: + `title`: string, the title of the cause + `contact_info`: string, the cause's contact info + `description`: string, the description of the cause - `nominee_info_data`: array, the nominee's info: + `nominee_hash`: string, the nominee's hash + `nominee_info`: nominee's info: + `nominee_name`: string, the nominee's name + `contact_info`: string, the nominee's contact info + `avatar_int`: int, the nominee's avatar integer + `focus_catagories`: int array, the nominee's focus categories + `nominee_description`: string, the nominee's description ### `savecausedata` - Accepts `json` and `pass` flags - Takes two arguments, the causeHash and a string of the cause data to save This command saves supplemental cause data to the non-consensus data share. JSON return object names: - `success`: bool, returns true if the datashare was accepted by the node ### `savenomineedata` - Accepts `json` and `pass` flags - Takes two arguments, the nominee hash and a string of the nominee data to save This command saves supplemental cause data to the non-consensus data share. JSON return object names: - `success`: bool, returns true if the datashare was accepted by the node ### `getvotes` - Accepts `json` flag - Takes no arguments This command returns your total spent votes, the targets of your active votes and how much unspent voting power you have. JSON return object names: - `total_vote_amount`: decimal, the amount in XCV you own that is currently voting - `unused_voting_power`: decimal, the amount in XCV you own that is currently NOT voting - `votes`: array, the votes you are making + `nominee_hash`: string, the hex encoded nominee hash string. This is the nominee you are voting as. Empty string if the vote is not being done as a nominee + `target_hash`: string, the hex encoded vote target. Either a nominee hash or a cause hash + `vote_power_amount`: decimal, the amount in XCV that is voting for this target ### `getvoteutxos` - Accepts `json` flag - Takes no arguments This command returns a list of your voting UTXOs along with a list of UTXOs you have that have not yet voted. JSON return object names: - `voting_utxos`: array, the UTXOs you have that are voting + `utxo_fingerprint`: string, the fingerprint of the UTXO + `account_hash`: string, the hex encoded account hash the utxo belongs too + `utxo_type`: string, a typestring for the UTXO that describes it + `utxo_value`: decimal, the value, in XCV, of the UTXO + `vote_type`: string, the vote type string + `addresses_can_spend`: string array, the list of bech32 encoded xcv addresses that can spend this UTXO + `utxo_votes`: array of votes + `nominee_hash`: string, the hex encoded nominee hash string. This is the nominee you are voting as. Empty string if the vote is not being done as a nominee + `target_hash`: string, the hex encoded vote target. Either a nominee hash or a cause hash + `vote_power_amount`: decimal, the amount in XCV that is voting for this target - `non_voting_utxos`: array of UTXOs that are not voting + `utxo_fingerprint`: string, the UTXO's unique fingerprint + `account_hash`: string, account hash the UTXO belongs too + `utxo_type`: string, a string labeling the type of UTXO + `utxo_value`: decimal, the amount in XCV that is the value of the UTXO + `addresses_can_spend`: array of strings, the encoded addresses that can spend the UTXO ### `simplevote` - Accepts `json` flag - Takes 3 arguments, the vote amount, the fee amount and the cause hash you are voting for. This command attempts to build, sign and broadcast a transaction that directs `amount` voting power to cause address `address` with `fee` as the fee. It intelligently selects non-voting or partially voted UTXOs to send the total amount. Returns an error if it cannot create the transaction. JSON return object names: - `txn_hashes`: string array, hex encoded hashes of vote transactions generated - `raw_txns_hex`: string array, the raw hex-encoded signed transaction. Use broadcasttxn RPC with this hex to complete the transaction - `txn_label`: string, the transaction label string, to be shown to the user before broadcasting for final confirmation ## Validators Functions: ### `createvalidator` - Requires 3 arguments: a UTXO fingerprint of sufficient size, the fee amount, and a bech32 vault address - Accepts flags: `pass` and `json` This command takes a UTXO large enough to become a validator and begins the process of integrating it into the finality generation process. JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string. Send to broadcasttxn RPC to finish sending the transaction ### `getvalidators` - Requires no arguments - Accepts `json` flag This command gets all of the validators associated with this account and returns their information. JSON return object names: - `account_validators`: array of validator infos associated with this account + `transaction_hash`: string, the current active validator txn hash + `last_vote_epoch`: int, the last stake vote epoch the validator voted in + `last_dynasty_voted`: int, the last vote dynasty the validator voted in + `pubkey`: string, the validator's hex-encoded pubkey + `start_dynasty`: int, the validator's start dynasty + `end_dynasty`: int, the validator's end dynasty + `stake`: int, the validator's current stake in Clo + `pending_reward`: int, the validator's current pending reward in Clo + `pending_penalty`: int, the validator's current pending penalty in Clo ### `getnetworkvalidators` - Requires no arguments - Accepts `json` flag This command gets all of the current active validators on the network and returns their information. JSON return object names: - `validators_in_current_set`: int, number of validator infos in the current validator set - `validators`: array of validator infos + `transaction_hash`: string, the current active validator txn hash + `last_vote_epoch`: int, the last stake vote epoch the validator voted in + `last_dynasty_voted`: int, the last vote dynasty the validator voted in + `pubkey`: string, the validator's hex-encoded pubkey + `start_dynasty`: int, the validator's start dynasty + `end_dynasty`: int, the validator's end dynasty + `stake`: int, the validator's current stake in Clo + `pending_reward`: int, the validator's current pending reward in Clo + `pending_penalty`: int, the validator's current pending penalty in Clo ### `removevalidator` - Requires 1 argument: the UTXO fingerprint for the validator to remove - Accepts flags: `pass` and `json` This command takes an active validator and begins the withdrawal process to remove that validator from the active validator set. For more information see the Finality Generation Guide (TODO). JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string. Send to broadcasttxn RPC to finish sending the transaction ### `startvalidator` - This is a special command that starts the inbuilt keychain validator and generates finality. it doesn't have any commands or interaction, but must be kept running as a process like the `stake` RPC. ### `getfinalityproofs` - Requires no arguments - Accepts `json` flag Gets all finality proofs for the current network. These are used for fast syncing JSON return object names: - `success`: bool, returns true if command was successful -


  • `finality_proofs`: array of finality proofs ### `getstateleafs` - Requires no arguments - Accepts `json` flag Gets all of the current state leaf hashes for the current chain state JSON return object names: - `success`: bool, returns true if command was successful - `state_leaf_hashes`: string array of hex encoded leaf hashes ## Nominee Functions: ### `createnominee` - Requires 1 argument: the `fee` - Accepts flags `pass` and `json` This command picks an unspent UTXO and registers a new nominee. It automatically chooses the UTXOs needed to pay the fee. JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string. Send to broadcasttxn RPC to finish sending the transaction ### `removenominee` - Requires 2 arguments: the nominee `hash` and the `fee` - Accepts flags `pass` and `json` This command makes a removenominee transaction and broadcasts it unless -json was enabled. In that case it will return the signed transaction hex. JSON return object names: - `txn_hash`: string, the transaction's hash - `txn_label`: string, the label that describes the effect of the transaction and what fees it pays - `txn_hex`: string, the final signed transaction encoded into a hexadecimal string. Send to broadcasttxn RPC to finish sending the transaction ### `simplenomineevote` - Requires 3 arguments: the `amount` the `fee` and the `hash` of the address to vote for - Accepts flags `pass` and `json` This command automatically picks UTXOs and sends `amount` voting power to `hash` target using your nominee key. These votes count as nominee votes for the purposes of delegated power redistribution. JSON return object names: - `txn_hashes`: string array, hex encoded hashes of vote transactions generated - `raw_txns_hex`: string array, the raw hex-encoded signed transaction. Use broadcasttxn RPC with this hex to complete the transaction - `txn_label`: string, the transaction label string, to be shown to the user before broadcasting for final confirmation ### `getmynominees` - Requires no arguments - Accepts `json` flag This command returns information on all active nominees associated with the account. In particular, each nominee's account tag, hash, pubkey, current delegated power and list of current active votes. JSON return object names: - `successs`: bool, true if getmynominees was successful - `nominees`: array of nomineeInfos related to your nominees + `nominee_hash`: string, hex encoded hash of the nominee + `nominee_pubkey`: string, hex encoded nominee pubkey + `nominee_address`: string, bech32 encoded nominee address + `nominee_vote_power`: decimal, amount in XCV of nominee's vote power + `nominee_proofs_power`: decimal, amount in proofs of nominee's proof power + `nominee_proofs_passthrough`: decimal, amount in proofs nominee passes through to its targets + `nominee_votes`: array of nominee votes currently active for this nominee + `vote_target_hash`: string, hex encoded vote target hash + `vote_raw_amt`: decimal, raw amount in XCV of this nominee vote + `vote_total_amt`: decimal, total amount in XCV of the vote power, raw power + delegated fraction + `vote_proofs_amt`: decimal, total amount, in proofs passed to the vote's target, raw proofs + pass-through fraction + `vote_percentage`: string, the precentage of the nominee's total votes that this vote accounts for. Nominees redistribute votes proportanally ### `getnetworknominees` - Requires no arguments - Accepts `json` flag This command returns information on all active nominees on the network. In particular, each nominee's account tag, hash, pubkey, current delegated power and list of current active votes. JSON return object names: - `successs`: bool, true if getnetworknominees was successful - `nominees`: array of total active nominees in the network + `nominee_hash`: string, hex encoded hash of the nominee + `nominee_pubkey`: string, hex encoded nominee pubkey + `nominee_address`: string, bech32 encoded nominee address + `nominee_vote_power`: decimal, amount in XCV of nominee's vote power + `nominee_proofs_power`: decimal, amount in proofs of nominee's proof power + `nominee_proofs_passthrough`: decimal, amount in proofs nominee passes through to its targets + `nominee_votes`: array of nominee votes currently active for this nominee + `vote_target_hash`: string, hex encoded vote target hash + `vote_raw_amt`: decimal, raw amount in XCV of this nominee vote + `vote_total_amt`: decimal, total amount in XCV of the vote power, raw power + delegated fraction + `vote_proofs_amt`: decimal, total amount, in proofs passed to the vote's target, raw proofs + pass-through fraction + `vote_percentage`: string, the precentage of the nominee's total votes that this vote accounts for. Nominees redistribute votes proportanally ### `getnomineehistory` - Requires 1 argument: the nominee's `hash` - Accepts flag `json` Returns all of the vote history for the given nominee. The nominee does not have to be yours and you do not have to synchistory with the chain to get the nominee's history JSON return object names: - `nominee_hash`: string, the hash of the nominee - `cumulative_nom_vote_totals`: array of cumulative votes the nominee made in the given epoch + `vote_target_hash`: string, hex target hash + `votes_sent_in_epoch`: decimal, amount in XCV votes total that was sent + `epoch_number`: int, the epoch number - `nominee_vote_update_info`: dicts that maps the target hash string to a list of vote updates the nominee made to that target + `target_hash`: string, the vote target hash + `target_height`: int, the blockheight the vote txn was confirmed + `target_time`: int, the unix time the vote txn was confirmed + `target_time`: decimal, the amount in XCV the vote amount changed in this update + `current_vote_total`: decimal, the nominee's current vote total, in XCV, for that target at that time - `nominee_vote_distributions`: array of nominee vote distribution updates when the nominee has made votes for a target + `height`: int, blockheight the vote was confirmed + `nominee_votes`: dict mapping target hex hash to nominee votes for target at the given height + `nominee_denominator`: decimal, the total amount the nominee is voting for. the nominee vote divided by the nominee denominator gives the fraction of delegated power that is redirected to the target - `delegated_power_vs_block_height`: an array of the nominee's delegated power at a given block height updates + `value`: int, the amount in Clo the nominee was delegated during this time period + `start_height`: int, the blockheight the nominee got the above value + `start_time`: int, the Unix time the nominee got the value + `end_height`: int, the blockheight the nominee's delegated value was changed + `end_time`: int, the Unix time the nominee's delegated value was changed ## History Functions: ### `getrecentunvaults` - Requires no arguments - Accepts `json` flag This command filters through recent unvaulting spends to see if they can still be reverted. If they can it returns the fingerprint to revert along with basic information on where the coins went. A spent is not removed if the transaction is reverted. JSON return object names: - `successs`: bool, true if successful - `revertable_txns`: array of revertible transactions for this account + `fingerprint`: string, revertable txn fingerprint + `unvaulting_time_remaining`: int, unvaulting time, in block, remaining before irreversiblity + `receiving_addresses`: string array, the addresses receiving the unvault txn + `coins_received`: decimal array, the amount of coins being sent to each receiving address ### `getnetworkunvaults` - Requires no arguments - Accepts `json` flag This command gets all recent unvaults for all accounts network wide. You can only revert transactions from vaults you own. JSON return object names: - `unvault_info`: array of unvault info in the current chain state ### `synchistory` - Requires no arguments - Accepts `json` and `pass` flag This command tells the node to sync the history of the current active account, starting at the genesis block (TODO: allow configurable start points). This will completely rebuild the account's history, but may take a significant amount of time if the chain is large. This command then queries the node for the account depth and vault addresses it has for the attached account hash. If the node has greater depth, the keychain attempts to make up the difference by creating new addresses to match. Vault addresses from the node are added to the keychain and saved. JSON return object names: - `success`: bool, true if the synchistory command was successfully sent - `starting_block`: int, the block the node will start syncing history on. This should be a block before this account was created. Default: 1 ### `syncaccountaddrs` - Requires no arguments - Accepts no flags This command tells the keychain and node to make sure the account depths are consistent between them. It has no output ### `gethistory` - Requires no arguments - Accepts `json` flag Returns a list of previous spent UTXOs and blocks generated. JSON return object names: - `success`: bool, true if history request was successful - `historical_txns`: array of historical transactions for this account + `txn_hash`: string, the hex encoded transaction hash + `inclusion_block_hash`: string, the hex-encoded block hash this txn was included in + `inclusion_block_height`: int, the height in blocks this transaction was confirmed + `inclusion_block_time`: int, the unix timestamp this block was generated + `txn_number_in_block`: int, the transaction's position in the block + `staking_block_reward`: decimal, if this transaction is a block reward txn, this is the block reward amount in XCV. This is zero for non reward transactions + `address_sent_from`: label array, an array of coinlabels this transaction sent from + `address`: string, the address being sent from + `coin_amount`: decimal, the amount in XCV of this txn input + `vaulted_time`: int, the time in blocks that this input must remain vaulted for + `addresses_sent_to`: label array, an array of labels this transaction sent too + `address`: string, the address being sent too + `coin_amount`: decimal, the amount in XCV of this txn output + `vaulted_time`: int, the time in blocks that this output must remain vaulted for + `txn_type_string`: string, the txn typestring, ment to be user friendly + `txn_type`: string, the raw txn type + `txn_base_fee`: int, the total amount in Clo of the transaction's base fee + `txn_tip_fee`: int, the total amount in Clo of the transaction's tip fee + `txn_hash_been_reverted`: bool, true if this transaction has been reverted by a revert txn + `spending_txn_hash`: string, the hash of the first txn that spends 1 or more outputs from this txn. Empty string means no txn has done this. + `proofs_buy_address`: string, if this is a proofs buying transaction, this is the address that the proofs will be sent too + `txn_proofs_earned`: int, if this transaction generates earned proofs, this is the amount in Clo-proofs that it earned + `earned_proofs_label`: string, if this transaction earned proofs, this is the user-friendly label explaining what this txn did to earn them + `vaulted_time_remaining`: int, the number of blocks before this unvault transaction becomes irreversible + `revert_lockout_time`: int, if this is a revert txn, this is the amount of lockout time before the revert output can be spent + `txn_confirmations`: int, the current number of confirmations that this transaction has + `txn_is_finalized`: bool, true if this transaction is below the highest finalized checkpoint and false otherwise ### `getvotehistory` - Requires no arguments - Accepts `json` flag Returns the current account's voting history. Each voting transaction creates a vote window that starts when the voting transaction is confirmed and ends when it is spent. During this time, all voting power distributed by that transaction is recorded in that vote epoch. JSON return object names: - `most_recent_vote_updates`: dictionary that maps the hex encoded target hash with the most recent vote update this account made + `vote_target_hash`: string, vote target hash + `last_change_time`: int, unix timestamp of the last change + `last_change_height`: int, blockheight the last change transaction was confirmed + `last_change_amt`: decimal, amount in XCV that the vote changed by - `cumulative_vote_totals`: array of cumulative epoch votes + `vote_target_hash`: string, hex encoded vote target hash + `votes_sent_in_epoch`: decimal, total cumulative votes for the target in XCV this epoch + `epoch_number`: int, the number that represents this current epoch - `vote_update_info`: dictionary that maps vote target to array of all votes this account made for that target + `target_hash`: string, vote target hex hash + `target_height`: int, block height vote txn was confirmed + `target_time`: int, unix time vote txn was confirmed + `update_votes_change`: decimal, amount in XCV the vote change for this target + `current_vote_total`: decimal, amount in XCV for the vote total for that target at that time ### `getnetworkcausehistory` - Requires no arguments - Accepts `json` flag Returns the cause history for each cause in the network. JSON return object names: `TODO` ### `getstakerewards` - Requires 1 argument, the number of months to get the total stake rewards from (starting now) - Accepts `json` flag Gets the total stake rewards for this account for the past number of months starting with the current month JSON return object names: - `month`: string, the name of the month - `reward`: decimal, the amount in XCV that was earned that month ### `clearhistory` - Requires no arguments - Accepts `json` flag Has the node delete all transaction history for the current attached account, for privacy or other reasons. The account histroy can be rebuilt using the `synchistory` command. JSON return object names: - `account_hash`: string, hex string of the account hash - `node_response`: string, node response string ## Information Functions: ### `getchaininfo` - Requires no arguments - Accepts `json` flag Returns current block chain information from the node JSON return object names: - `total_blockchain_height`: int, total block chain height - `chain_tip_hash`: string, the hash of the current chain tip - `assumed_best_chain_weight`: int, the weight of the current best chain including blocks that have not been validated yet - `validated_best_chain_weight`: int, the weight of the current best validated chain - `validated_best_chain_height`: int, the height of the current best validated chain - `number_of_valid_chainfrags`: int, the current number of valid chain fragments - `highest_checkpoint_height`: int, the height of the highest checkpoint - `highest_checkpoint_hash`: string, hex hash of the current highest checkpoint - `current_dynasty`: int, the current finality dynasty number - `highest_justified_checkpoint_height`: int, the height of the current highest justified checkpoint - `hightest_justified_checkpoint_hash`: string, the hex hash of the highest justified checkpoint - `highest_finalized_checkpoint_height`: int, the height of the current highest finalized checkpoint - `heightest_finalized_checkpoint_hash`: string, the hex hash of the highest finalized checkpoint - `create_cause_fee`: decimal, the additional fee in XCV to create a cause - `create_nominee_fee`: decimal, the additional fee in XCV to create a nominee - `current_dust_limit`: decimal, the current dust limit in XCV. An output or send cannot be smaller then this value - `base_fee_rate`: decimal, the current base fee rate in XCV - `suggested_tip`: decimal, the current suggested tip in XCV - `current_vote_epoch`: int, the number of the current vote epoch - `minutes_to_next_vote_epoch`: int, the time in minutes to the next vote epoch - `proof_of_cause_pool_balance`: int, the current balance in Clo of the Proof of Cause pool - `purchaser_pool_balance`: int, the current balance in Clo in the Purchaser pool ### `getnetworkcauseinfo` - Requires no arguments - Accepts `json` flag Returns the current mapping of cause category integers to category names and the character limits on the various supplimental info fields JSON return object names: - `categories`: array of category types. A category type is: + `number`: int, the category number + `category`: string, the category string + `supinfo_max_titlesize`: int, the max number of characters in a cause or nominee title field + `supinfo_max_contactsize`: int, the max number of characters in a cause or nominee contact field + `supinfo_max_descriptionsize`: int, the max number of characters in a cause or nominee description field ### `getnetworkstats` - Requires no arguments - Accepts `json` flag Returns current information on various network information. JSON return object names: - `active_causes`: int, the number of active causes on the network - `network_donations`: int, the total number of network donations - `total_donors`: int, the total number of network donors - `total_cause_votes`: int, the total votes for causes - `total_network_nominees`: int, the total number of network nominees - `total_network_nominee_power`: int, the total amount of nominee not vote power ### `getrandinfo` - Requires no arguments - Accepts `json` flag Returns information on the internal RANDAO state JSON return object names: - `TODO` ### `getrandinfo` - Requires no arguments - Accepts `json` flag Returns information on the current active account depths JSON return object names: - `TODO` ### `getpeerinfo` - Requires no arguments - Accepts `json` flag Returns the list of currently live peers the node is connected to. JSON return object names: - `peers`: the array of currently connected peers: + `peer_IPv4_address`: string, the peer's IPv4 address + `peer_pubkey`: string, the peer's pubkey hex + `protocol_version_major`: int, protocol version major index eg. X.0.0 + `protocol_version_minor`: int, protocol version minor index eg. 0.X.0 + `protocol_version_patch`: int, protocol version patch index eg 0.0.X + `peers_best_block_height`: int, peer's best block height + `peer_is_currently_connected`: bool, true if peer is currently connected + `last_node_info_attempt`: time, time of last peerdata request + `last_node_info_success`: time, time last peerdata request was successful + `last_connection_attempt_failure`: time, last time peer had a connection failure ### `getpeermap` - Requires no arguments - Accepts `json` flag Returns the list of all peers the node has ever discovered. JSON return object names: - `peers`: the array of currently connected peers: + `peer_IPv4_address`: string, the peer's IPv4 address + `peer_pubkey`: string, the peer's pubkey hex + `protocol_version_major`: int, protocol version major index eg. X.0.0 + `protocol_version_minor`: int, protocol version minor index eg. 0.X.0 + `protocol_version_patch`: int, protocol version patch index eg 0.0.X + `peers_best_block_height`: int, peer's best block height + `peer_is_currently_connected`: bool, true if peer is currently connected + `last_node_info_attempt`: time, time of last peerdata request + `last_node_info_success`: time, time last peerdata request was successful + `last_connection_attempt_failure`: time, last time peer had a connection failure ### `getblock` - Requires one arguments: the `blockhash` as a hex string - Accepts `json` flag Returns as much information as possible about block header with `blockhash` given. JSON return object names: - `TODO` ### `getheight` - Requires one argument: the `blockheight` - Accepts `json` flag Attempts to get the block at given `blockheight`. Returns block header and body data if possible. JSON return object names: - `TODO` ### `gettxn` - Requires one argument: the list of transaction hashes to get, separated by commas (eg: 'txnhash1, txnhash2...') - Accepts `json` flag Attempts to get the transactions with given hash. Right now only checks transactions in confirmed blocks, to see transactions in the mempool, use dumpmempool. JSON return object names: - `TODO` ### `getreceipt` - Requires one argument: the list of receipt heights to get, separated by commas (eg: 'blockheight1, blockheight2...') - Accepts `json` flag Attempts to get state receipts for the given block heights JSON return object names: - `TODO` ### `getpendingtxns` - Requires one argument: a list of transaction hashes `,...` - Accepts `json` flag Queries the node's mempool for a list of the given transaction hashes. If any of them are found, they are returned in order. If one is not found, it is skipped. JSON return object names: - `TODO` ### `getnetworkvotedist` - Requires 1 argument: the vote epoch that you want the distribution for - Accepts `json` flag Get's the requested vote epoch's current (not normalized) vote distribution. This is used in redistribution of network funds. The current vote epoch's values will change as time passes, previous epoch's values are historical and immutable. JSON return object names: - `vote_epoch`: int, the vote epoch number - `vote_distribution`: dict that maps the hex target hash with the total amount of XCV in decimals it has received this vote epoch ### `getnetworkvoteinfo` - Requires no arguments - Accepts `json` flag Returns internal state information related to voting. JSON return object names: - `vote_index_scriptlocks`: dict, maps the scriptlock hash string with the vote index amount in Clo - `vote_index_causes`: dict, maps the causeHash with the vote cause index amount in Clo - `cause_index`: dict, maps the causeHash to the cause internal state infohash - `nominee_index`: dict, maps the nominee hash to the nominee internal state infohash ## Infodump functions ### `dumpmempool` - Requires no arguments - Accepts `json` flag Returns the complete contents of the current mempool JSON return object names: - `TODO` ### `dumpallheaders` - Requires no arguments - Accepts `json` flag Returns all of the headers the node has in full. Also outputs all valid chain fragments. Warning, this might be very large output JSON return object names: - `TODO` ### `dumplinks` - Requires no arguments - Accepts `json` flag Returns info on all current finality vote links JSON return object names: - `TODO` ### `dumpvalidators` - Requires no arguments - Accepts `json` flag Returns a list of all validator and finalization info. JSON return object names: - `TODO` ## NodeOp functions ### `nodestacktrace` - Requires no arguments - Accepts no flags Sends a panic signal to the node which should cause it to immediately panic and generate a stack trace. ### `nodeshutdown` - Requires no arguments - Accepts `json` flag Sends the attached node a shutdown signal if possible and prints the result. JSON return object: - `shudown_success`: bool, true if shutdown signal was successfully received.

2025 Test

causes-guide-img

Sometimes you just want to test to see what things look like


Sorry for the spamdssssssssssssssssssssssssssssssssssssssss orem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse vestibulum, sem cursus lobortis pulvinar, est felis cursus lacus, quis auctor lectus tortor in justo. Nam feugiat quam sit amet dolor volutpat tincidunt. Pellentesque eget augue nec purus feugiat congue. Quisque ligula est, placerat at nibh ac, hendrerit sagittis nulla. Fusce erat augue, tincidunt et sapien vitae, semper congue purus. In non dignissim dolor. Ut egestas egestas efficitur. Aenean faucibus iaculis velit tristique malesuada. Nunc neque erat, auctor ut tristique ac, congue vel elit. Curabitur eu mollis nulla, dignissim tincidunt ex. Fusce varius lorem in leo venenatis sagittis.



Donec venenatis faucibus sem sit amet euismod. Nullam neque sem, rhoncus eget sollicitudin eu, vestibulum imperdiet enim. In suscipit ipsum felis. Nulla nec laoreet purus, et tincidunt nulla. Etiam semper cursus ante, non congue libero tincidunt eu. Sed mauris mauris, blandit a ultricies eget, interdum vitae arcu. Phasellus sed efficitur quam, et pharetra arcu.



Ut quis rutrum est. Aenean eu tempus enim, in molestie leo. Maecenas tincidunt, massa at hendrerit venenatis, dolor justo tristique arcu, sed consectetur sapien ante at elit. Nulla ligula tortor, aliquam eu nisl nec, faucibus fringilla erat. Aenean suscipit vehicula ante, vel malesuada ipsum molestie quis. Suspendisse potenti. Nulla ultricies tortor quis massa interdum convallis. Suspendisse ac fringilla arcu. Integer vel vestibulum risus, a feugiat sem. Nunc imperdiet lacus nec lectus ultrices porttitor. Aenean sem eros, porttitor sodales semper et, rhoncus et magna. Nunc ac interdum magna. Morbi massa mi, vestibulum a hendrerit quis, imperdiet et diam.

Etiam ornare elit dolor. Etiam sit amet finibus orci. Quisque sodales est vel quam gravida, ac bibendum ipsum blandit. Praesent at blandit enim. Fusce eu turpis quis neque scelerisque feugiat eget eget justo. Donec sed augue aliquet, congue felis nec, pulvinar dui. Aliquam eget erat nisl. Suspendisse et dolor in dui posuere eleifend eget sed augue. Suspendisse potenti.

Aliquam id pretium magna, eget lobortis sapien. Donec pulvinar vehicula arcu eu tincidunt. Sed vehicula nisi a commodo ultricies. Fusce cursus nisl libero, in porta eros vehicula et. Aliquam in odio non arcu efficitur gravida. Nullam id nisl dolor. Fusce ligula justo, congue eget scelerisque ut, luctus at nisi. Ut non tristique sem.


Join our Community

Spread the word and earn 1 XCV for every friend you invite

You can work out the current price to buy directly from us while there is stock available by using