
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.
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.
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.
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
# 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 -
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.
You can work out the current price to buy directly from us while there is stock available by using