diff --git a/docs/dev-resources/nevm/tooling.mdx b/docs/dev-resources/nevm/tooling.mdx index 6f9609ed..b08ee363 100644 --- a/docs/dev-resources/nevm/tooling.mdx +++ b/docs/dev-resources/nevm/tooling.mdx @@ -18,12 +18,6 @@ For a guide on how to deploy smart contracts with Foundry on Syscoin NEVM, click Truffle has been discontinued. We recommend using [Hardhat](./hardhat) or [Foundry](./foundry) for developing and deploying smart contracts on Syscoin NEVM. -:::info Further reading -[Truffle is sunsetting — here’s how to migrate to Hardhat, Foundry, and thirdweb](https://blog.thirdweb.com/guides/truffle-alternative-ethereum/) -::: - - - **Remix IDE** [Remix](https://remix.ethereum.org/) is an in-browser IDE that enables the writing, deploying and testing of smart contracts. It gives developers the ability to connect to any network they like through the use of browser extensions like MetaMask. diff --git a/docs/dev-resources/nevm/truffle.mdx b/docs/dev-resources/nevm/truffle.mdx index a9985bb6..504ec933 100644 --- a/docs/dev-resources/nevm/truffle.mdx +++ b/docs/dev-resources/nevm/truffle.mdx @@ -1,5 +1,3 @@ # Deploying Smart Contracts with Truffle (Discontinued) **Truffle has been discontinued.** We recommend using [Hardhat](./hardhat) or [Foundry](./foundry) for developing and deploying smart contracts on Syscoin NEVM. - -For a guide on migrating from Truffle to Hardhat, you can refer to this article: [Truffle is sunsetting — here’s how to migrate to Hardhat, Foundry, and thirdweb](https://blog.thirdweb.com/guides/truffle-alternative-ethereum/) diff --git a/docs/dev-resources/sys/asset-index.mdx b/docs/dev-resources/sys/asset-index.mdx deleted file mode 100644 index f7f69c31..00000000 --- a/docs/dev-resources/sys/asset-index.mdx +++ /dev/null @@ -1,126 +0,0 @@ -# SPT Asset Index Technical Description - -**Introduction** - -Asset index is a high performance blockchain re-organization aware flag that allows users to be able to query historical information related to Syscoin Assets. - -The asset index was created as a way for exchanges and other services to be able to manage Syscoin assets via viewing transactional history without requiring third party tools. This index is useful for viewing information only. The current set of RPCs to create transactions for managing assets are created in a way that are not dependent on a wallet and thus are compatible with signing tools such as hardware wallets. This is a reference implementation and of course third party tools in some contexts make sense. However as a fallback we created a reference implementation for those requiring all information to be available from within Syscoin Core itself without the need for custom modifications. You do not need to enable txindex and it is pruning compatible. There are two RPCs exposed for the use of asset index. - -1. listassetindex - This will let you filter all assets + asset allocations via an asset GUID and/or an address. You can leave the address field empty to scan through the entire asset. -2. listassetindexassets - Takes in an address and returns any asset GUIDs that are owned by the address as allocations. - -There are two configuration variables to use when dealing with an asset index. -assetindex and -blockindex. Blockindex allows once to view the block related to an asset transaction. It is re-org aware. This means that every transaction is associated with a blockhash and on a disconnect of a block the blockindex is updated to remove the blockhash associated with the disconnected transactions in the block(s) rolled back. The blockhash is output in the `listassetindex` command as the block_hash field. This makes the assetindex re-org aware by extension as one would be able to rely on the block_hash field of the returned entries to know if a transaction was confirmed or potentially not part of the longest chain on a node. - -You somtimes do not want to have to index all assets in Syscoin and just want to index the ones you care about and thus there are configurations for those cases you can read about below. - -**Use Cases** - -The main usecases of using such an index are as follows: - -Use case #1: enter an asset GUID and address and get back a list of transactions (sends/receives) related to that asset/address tuple. - -Use case #2: enter an address and view all assets connected to an address. - -Use case #3: enter an asset GUID and view all transactions (sends/receives/updates) related to an asset. - -**Motivation** - -We needed high performance to avoid large delays as transactional volume increased. The requirement for this index in the design phase was to have O(1) time complexity and <= O(N) space complexity. We solved this by using a Key-Value storage database and using a tuple of information as Key to reduce lookup complexity yet remain flexible to be able to walk through the historical information with intuition. We require the Key to have a page number to create this efficiency and thus consuming clients would work under a paged view mechanism. The default page size is 25 results per page. - -```text -// Configuration Parameters (in syscoin.conf or passed into the binary when running Syscoin Core): - -Assetindex - true if we want to index asset history, false to skip. Default is false. Set to true if consuming client is a block explorer, asset wallet, crypto-currency exchange or any other client that needs history of assets. - -Assetindexguids - comma seperated list of asset guids to index, empty for all if Assetindex is true. - -Assetindexpagesize - if Assetindex is true set this to a page size based on how the consuming client will render results. Default is 10. - -Blockindex - true if you want block_hash information for every asset transaction result from listassetindex RPC -``` - -Note that `Assetindexpagesize` is dynamic and set upon configuration, if changed you need to reindex the blockchain from start. - -Database Structure: - -```cplusplus -Collection for TXIDs for each allocation, Get/Set -
= vector (size of vector is based on page size); - -Current highest page number, Get/Set - = int; - -Collection for JSON outputs for TXID, Get/Set - = JSON output of transaction; - -Assets per address, Get/Set -
= vector; - -TXIDs of asset update/send/receive, Get/Set - = vector; -// In Memory structure: -Get/Set - Set of TXID’s (lets call it confirmedTXIDs); -``` - -Pseudocode for Connect Block logic: - -```cplusplus -Set TXID to confirmedTXIDs; - -Get page number as pageNum; - -Get vector based on
; - -If vector size if >= 10 increase pageNum and create new vector; - -Set JSON output of transaction to vector collection of JSON outputs per TXID; - -Set vector based on
to TXID collection for asset allocation; - -Set pageNum to highest page number collection; -``` - -Pseudocode for Disconnect Block logic: - -```cplusplus -For every transaction: - Remove TXID from confirmedTXIDs; -``` - -Pseudocode for listassetindex RPC function: - -```text -/*Scan an asset/address tuple for a page of transaction. Consuming clients should page results based on page size set in configuration to the core. Will return all tx’s regardless if they were re-orged or not. A confirmed parameter will indicate if the transaction is part of the blockchain and confirmed. - Parameters: - Asset guid - asset guid number specific to each asset - Address - a sender or receiver address that owns an asset. If empty then assume you want all tx’s based on asset. - Page number - return specific page number of transactions. 0 by default*/ - -If Address is empty: - Get vector based on ; -Else: - Get vector based on
; - -For each txid in vector: - Get JSON output based on txid; - Get blockhash of txid from blockindex (if exist otherwise set to empty); - Add blockhash of txid to JSON output as block_hash; - -Return JSON output to caller -``` - -Pseudocode for listassetindexassets RPC function: - -```cplusplus -/*Assets per Address: -Returns all asset guids related to an address at any time in blockchain history. - Parameters: - Address - a sender or receiver address that potentially owns an asset*/ - -Get vector based on
; - -Return JSON of all assets found to caller; -``` - -**Q&A** - -What does re-org protected mean? -It means that if the blockchain tip is disconnected for whatever reason (longer chain is found) then you have to rollback transactions, we wouldn't want our asset view to incorrectly show transactions as confirmed when they have been rolled back. - -What does asset indexing mean? -It means that we need a way to show all transactions related to an asset+address tuple. You need to be able to as a wallet or explorer view pertaining transactions for your asset allocation as a sender or receiver. \ No newline at end of file diff --git a/docs/dev-resources/sys/exchange-integration.mdx b/docs/dev-resources/sys/exchange-integration.mdx index eafa53d1..4bac9bc6 100644 --- a/docs/dev-resources/sys/exchange-integration.mdx +++ b/docs/dev-resources/sys/exchange-integration.mdx @@ -1,211 +1,21 @@ # SPT Exchange Integration -:::info -**UPDATE:** The Syscoin Core RPCs used in the example below, and other SPT-oriented RPCs, have been deprecated and removed as of Syscoin Core 4.4. -Now **[syscoinjs-lib](https://github.com/syscoin/syscoinjs-lib)** and **[syscointx-js](https://github.com/syscoin/syscointx-js)** are used to create/manage digital assets, auxfees, and notaries on the UTXO chain. - -Examples are available at **[https://github.com/syscoin/syscoinjs-lib-examples](https://github.com/syscoin/syscoinjs-lib-examples)**. - -For a complete list of these deprecated RPCs, review the **[Syscoin Core 4.4 release notes](https://github.com/syscoin/syscoin/blob/master/doc/release-notes/release-notes-4.4.0.md)**. +:::warning Outdated workflow removed +This page previously documented exchange integration via the legacy `assetallocationsend` / `assetallocationsendmany` / `listunspentasset` Core RPCs. Those RPCs were **removed in the Nexus upgrade (Syscoin Core 5.0)** — see the [5.0.0 release notes §9](https://github.com/syscoin/syscoin/blob/master/doc/release-notes/release-notes-5.0.0.md#9-removal-of-deprecated-syscoin-4x-asset-rpcs). ::: -**This guide is a primer to help exchanges integrate Syscoin Platform Tokens (SPT's).** - -The Syscoin platform provides a UTXO-based token issuance system embedded in the Syscoin blockchain. Transactions of SPT's consume network fees paid in SYS and can provide token recipients an accompanying default "pass-forward" amount of SYS dust to enable them to transact the SPT without having to acquire or own SYS beforehand. - -An SPT has several noteworthy properties. Most important is the `asset_guid`, the deterministically-assigned unique identifier of the token on the Syscoin blockchain. Similar to Ethereum, anyone can create a token and make its symbol "AGX" but there can only ever be one official AGX token with the `asset_guid` of 367794646. Several popular SPT's and their associated identifiers can be found in the table below. - -| SPT Symbol | SPT Description | SPT Asset Guid | Website | -| :--------- | :---------------------------------- | :------------- | :------ | -| AGX | AGX Silver Token | 367794646 | | -| AUX | Official Interfix Gold backed Token | 1358717298 | | -| BTZC | BeatzCoin SPT | 315501466 | | - -There are two paths for integrating SPT assets. - -- Interact with a syscoin daemon (syscoind) instance directly via RPC (you can optionally use [syscoin-js](https://github.com/syscoin/syscoin-js) for this) -- Interact with Syscoin via a Web 3.0 approach by using [syscoinjs-lib](https://github.com/syscoin/syscoinjs-lib) which interacts with a running [Syscoin Blockbook](https://github.com/syscoin/blockbook) instance or a gateway of load-balanced Blockbook instances. - -## Set up for Interacting with Syscoin Directly via RPC - -This walk-through assumes you are using the OS console. - -1. Ensure the following line is in your syscoin.conf (default path `~/.syscoin/syscoin.conf`) - -```text -assetindex=1 -``` - -1. Launch syscoind - -> ### 📘Reindexing to build local asset index -> -> If you previously launched syscoind without `assetindex=1` in syscoin.conf, use -reindex, e.g. `syscoind -reindex` - -```text -$ syscoind -``` - -1. Create a wallet - -> ### 📘Note -> -> We strongly suggest creating two separate wallets, one strictly for SYS, and the other for SPT's with a smaller amount of SYS for transaction fees. This eliminates confusion and headaches related to coin control with SPT's. - -```text -$ syscoin-cli createwallet "walletname" -``` - -From here on, all syscoin-cli calls will need to add the `-rpcwallet "walletname"` argument. -If using http-rpc, the https url should be in the form of `http://[ip]:[port]/wallet/[walletname]` - -You can also launch syscoind in a way that connects with a specific wallet by using the `-wallet` argument with the path to the directory containing the wallet.dat file. - -## Commonly Used RPC Functions for Exchange Integration - -For RPC documentation, please see https://syscoincore.org/en/doc/4.2.0/ - -You can also use use `help ` for a full description of the RPC and its options and arguments - -| Function | SYS | SPT | -| :------------------------------------------------- | :---------------------------------- | :--------------------------------------- | -| Query address balances | `addressbalance` | `assetallocationbalance` | -| Obtain the block height or other chain status info | `getblockchaininfo` | `getblockchaininfo` | -| Obtain wallet transaction list | `listtransactions` or `listunspent` | `listtransactions` or `listunspentasset` | -| Get transaction details | `gettransaction` | `gettransaction` | -| Asset transfer | `sendtoaddress` | `assetallocationsend` | -| Asset transfer (batch) | `sendmany` | `assetallocationsendmany` | - -**Query asset balances** -`assetallocationbalance "[\"
\"]" ` - -You can query the sum balance of multiple addresses by listing more than one address, e.g.: -`assetallocationbalance "[\"
\",\"
\"]" ` - -Output: -"amount": SYS gas balance supplied for this asset -"asset_amount": SPT balance - -```text -$ syscoin-cli assetallocationbalance 530240372620954 "[\"tsys1qedy7ukgnj9e96axgarw79e2au98ff9g4ffh829\"]" 10 - -{ - "amount": 0.00001960, - "asset_amount": 3.55000000 -} -``` - -**Obtain the blockheight or other chain status info** - -```text -$ syscoin-cli getblockchaininfo - -{ - "chain": "test", - "blocks": 575809, - "headers": 575809, - "bestblockhash": "0000006727f5114eee02624b08d3f1d0f62ff7850bf85c612400ce668b174908", - "difficulty": 0.006962848657727248, - "mediantime": 1616709431, - "verificationprogress": 0.9999993714602142, - "initialblockdownload": false, - "chainwork": "0000000000000000000000000000000000000000000000000000064f2f44f6c8", - "size_on_disk": 341575106, - "pruned": false, - "geth_sync_status": "waiting to sync...", - "geth_total_blocks": 0, - "geth_current_block": 0, - "softforks": { - "bip34": { - "type": "buried", - "active": true, - "height": 1 - }, - "bip66": { - "type": "buried", - "active": true, - "height": 1 - }, - "bip65": { - "type": "buried", - "active": true, - "height": 1 - }, - "csv": { - "type": "buried", - "active": true, - "height": 1 - }, - "segwit": { - "type": "buried", - "active": true, - "height": 0 - }, - "testdummy": { - "type": "bip9", - "bip9": { - "status": "active", - "start_time": 0, - "timeout": 999999999999, - "since": 550368 - }, - "height": 550368, - "active": true - }, - "taproot": { - "type": "bip9", - "bip9": { - "status": "active", - "start_time": -1, - "timeout": 9223372036854775807, - "since": 0 - }, - "height": 0, - "active": true - } - }, - "warnings": "" -} -``` - -**Obtain wallet transaction list for assets** -`listtransactions` is general purpose. It covers all transaction types and its output is verbose. -`listunspentasset ` is more specific. - -```text -$ syscoin-cli listunspentasset 530240372620954 10 -[ - { - "txid": "ac74df7b065bf501db991153920db3462780c8d238ef6fc5562ee7e4b2db565d", - "vout": 0, - "address": "tsys1qqzrxzg8cmyrl8xss353zkvty5qwlfga4r9tq4r", - "label": "Another address", - "scriptPubKey": "001400866120f8d907f39a108d222b3164a01df4a3b5", - "amount": 0.00500000, - "asset_guid": "530240372620954", - "asset_amount": 0.00000200, - "confirmations": 9771, - "spendable": true, - "solvable": true, - "desc": "wpkh([1712892e/0'/0'/1']02aec158d644eb2744479c7a0410e30b91d6278a1091ff7a4cd7caf6c132b1b820)#u0azeyff", - "safe": true - } -] -``` - -**Get transaction details** - -```text -$ syscoin-cli gettransaction fa4ee19861d5f9c0aa46d20f332458e559921255cf98c0873afc2462849588ba -``` +For Syscoin 5.x, exchanges integrating SPTs should use the following stack: -## Setup for using Blockbook API and syscoinjs-lib +- **[syscoinjs-lib](https://github.com/syscoin/syscoinjs-lib)** — JavaScript SDK for constructing and broadcasting UTXO-side SPT transfers. Examples at [syscoinjs-lib-examples](https://github.com/syscoin/syscoinjs-lib-examples). +- **[Blockbook](https://blockbook.syscoin.org)** — the Foundation-operated UTXO indexer used by syscoinjs-lib for address state, UTXO listing, and transaction broadcast. Mainnet at `blockbook.syscoin.org`, testnet at `blockbook-dev.syscoin.org`. +- **NEVM bridge** — SPT issuance, redemption, and cross-chain movement happen through the [SyscoinVaultManager](https://explorer.syscoin.org/address/0x7904299b3D3dC1b03d1DdEb45E9fDF3576aCBd5f) contract on the Syscoin NEVM. Exchanges that already support ERC-20 deposits can treat the NEVM side as a standard EVM chain (chain ID 57). -Syscoin Blockbook uses its own syscoind instance as the backend, and indexes the blockchain data and tracks XPUB-based account balances to serve the API. +## Z-DAG for fast SPT settlement -Please follow the readme in https://www.github.com/syscoin/blockbook if you want to implement your own Blockbook server instance. -syscoinjs-lib is used to communicate with blockbook server and the documentation is located at https://www.github.com/syscoin/syscoinjs-lib +Z-DAG status checks via `assetallocationverifyzdag` remain available in Core 5.x — see the [Z-DAG developer guide](/docs/dev-resources/sys/z-dag). -Examples for using syscoinjs-lib are located at https://www.github.com/syscoin/syscoinjs-lib-examples +## Useful pointers -A public Blockbook server instance for Syscoin is located at [https://sys1.bcfn.ca](https://sys1.bcfn.ca/) \ No newline at end of file +- syscoinjs-lib examples: https://github.com/syscoin/syscoinjs-lib-examples +- Blockbook source / self-hosting: https://github.com/syscoin/blockbook +- SyscoinVaultManager source: https://github.com/syscoin/sysethereum-contracts diff --git a/docs/dev-resources/sys/z-dag.mdx b/docs/dev-resources/sys/z-dag.mdx index d95b94a4..82ef5026 100644 --- a/docs/dev-resources/sys/z-dag.mdx +++ b/docs/dev-resources/sys/z-dag.mdx @@ -1,6 +1,6 @@ # Z-DAG Developer Guide -Z-DAG is a patent-pending transaction technology implemented on the Syscoin blockchain that enables near-instant, low-cost transactions that are highly scalable. Z-DAGs transactional throughput has been audited by third party blockchain auditing firm [Whiteblock](https://whiteblock.io/), you can [view their report here](https://syscoin.org/whitepaper#tps). For more technical information on Z-DAG refer to the [Z-DAG Syscoin Community page](https://syscoin.community/features/z-dag) or the [Syscoin Z-DAG Whitepaper](https://syscoin.org/zdag_syscoin_whitepaper.pdf). +Z-DAG is a patent-pending transaction technology implemented on the Syscoin blockchain that enables near-instant, low-cost transactions that are highly scalable. Z-DAGs transactional throughput has been audited by third party blockchain auditing firm [Whiteblock](https://whiteblock.io/), you can [view their report here](https://syscoin.org/whitepaper#tps). For more technical information on Z-DAG refer to the [Z-DAG technical overview](/docs/tech/z-dag) or the [Syscoin Z-DAG Whitepaper](https://syscoin.org/zdag_syscoin_whitepaper.pdf). ## Z-DAG Basics @@ -32,4 +32,6 @@ Z-DAG status is retrieved by the command `assetallocationverifyzdag`. The output ## Using Z-DAG Balances -The available balance while use Z-DAG can be determined by calling `assetallocationbalance`. If `balance` and `zdag_balance` are the same, then display `balance`. If the balances differ that is an indication that Z-DAG is active for this transaction and it has not yet been confirmed by Proof of Work. In this scenario the `zdag_balance` should be used to indicate to the user their available balance. +In the legacy 4.x SPT model the per-asset `assetallocationbalance` RPC reported a `zdag_balance` separate from the confirmed `balance`. That RPC was removed in Syscoin Core 5.0 along with the rest of the 4.x asset RPC family. + +In the current 5.x model, Z-DAG status is a property of individual transactions rather than aggregated balances: poll `assetallocationverifyzdag` for each unconfirmed transfer of interest, and treat any input still in a non-zero Z-DAG state as not yet safely re-spendable. diff --git a/docs/guides/mining_setup.mdx b/docs/guides/mining_setup.mdx index 0a62e449..a9d19c05 100644 --- a/docs/guides/mining_setup.mdx +++ b/docs/guides/mining_setup.mdx @@ -68,7 +68,7 @@ Finding a Bitcoin or Syscoin block is harder when mining solo (on your own). Usi -- **[Mining-Dutch](https://www.mining-dutch.nl/pools/syscoin.php?page=dashboard)** +- **[Mining-Dutch](https://www.mining-dutch.nl/index.php?page=gettingstarted)** - **[ViaBTC](https://support.viabtc.com/hc/en-us/articles/900001530543)** - **[F2Pool](https://www.f2pool.com/)** (merged mining internally, they keep the altcoins) @@ -140,7 +140,7 @@ Code at [auxpow.h](https://github.com/syscoin/syscoin/blob/v4.3.0/src/auxpow.h) -You can also take a look at [src/tests/auxpow_tests.cpp](https://github.com/syscoin/syscoin/blob/v4.3.0/src/tests/auxpow_tests.cpp). Take a look at [test/functional/auxpow_mining.py](https://github.com/syscoin/syscoin/blob/v4.3.0/test/functional/auxpow_mining.py) for example code that constructs and mines (with regtest difficulty) an AuxPoW block. +You can also take a look at [src/test/auxpow_tests.cpp](https://github.com/syscoin/syscoin/blob/master/src/test/auxpow_tests.cpp). Take a look at [test/functional/auxpow_mining.py](https://github.com/syscoin/syscoin/blob/master/test/functional/auxpow_mining.py) for example code that constructs and mines (with regtest difficulty) an AuxPoW block. *NOTE: The commands above can be reproduced quickly by running syscoind in regtest mode. For testnet and mainnet it is required to fully sync the Syscoin node.* diff --git a/docs/guides/overview.mdx b/docs/guides/overview.mdx index 87a113ba..8435141f 100644 --- a/docs/guides/overview.mdx +++ b/docs/guides/overview.mdx @@ -19,12 +19,6 @@ There are a number of guides available for users of Syscoin. Check the list belo - [Setting up MetaMask to use Rollux](/docs/guides/rollux/metamask) - [About Rollux](/docs/tech/rollux) -## Syscoin Platform Token (SPT) Guides - -- [Creating and issuing SPTs](/docs/guides/spts/create-issue-tokens) -- [Utilizing notary and business rulesets for SPTs](/docs/guides/spts/notary-business-rulesets) -- [Using SPTs with the QT wallet](/docs/guides/spts/use-tokens) - ## Sentry Nodes Guides - [Setting up a Sentry Node](/docs/guides/sentrynode_setup) diff --git a/docs/guides/rollux/metamask.mdx b/docs/guides/rollux/metamask.mdx index 1077085f..a5a94eb0 100644 --- a/docs/guides/rollux/metamask.mdx +++ b/docs/guides/rollux/metamask.mdx @@ -6,5 +6,5 @@ Looking for simple instructions to connect to Rollux? Head to the **[Rollux Help Once you're connected you can... - Move your SYS to Rollux using the [Rollux Portal](https://bridge.rollux.com), Rollux's canonical bridge. -- Use a Rollux [faucet](https://rollux.id/faucet?chainId=570) to get a small amount of SYS to cover a fee or two on Rollux. +- Use a Rollux [faucet](https://faucet.rollux.com) to get a small amount of SYS to cover a fee or two on Rollux. - Get going with some dapps on Rollux such as [Pegasys](https://app.pegasys.fi) DEX, [Luxy](https://luxy.io) NFT Marketplace, or any other live dapps in the [Rollux ecosystem](https://rollux.com/ecosystem)! diff --git a/docs/guides/sentrynode_setup.mdx b/docs/guides/sentrynode_setup.mdx index 97a0d593..c0ae2845 100644 --- a/docs/guides/sentrynode_setup.mdx +++ b/docs/guides/sentrynode_setup.mdx @@ -111,12 +111,12 @@ Finally we are ready to work on your server. Connect to your VPS as root via SSH bash <(curl -sL https://raw.githubusercontent.com/Syscoin/Masternode-install-script/master/script.sh) ``` -> **Please also check the latest releases - if it is not 4.3.0, you will need to enter in the latest release tag for for Syscoin Core Github Branch. So if the latest release is 4.3.1, you would enter 4.3.1 and then press enter. You can check that here; [Releases · syscoin/syscoin · GitHub](https://github.com/syscoin/syscoin/releases)** +> **Check the [latest releases](https://github.com/syscoin/syscoin/releases) and enter the latest stable release tag for the Syscoin Core Github Branch (for example, `v5.1.0`).** Default values are found in brackets and pressing enter will selected the [default] value. For entries with a [Y/n] the capital letter is the default. Enter [Y] to choose “yes” or [N] to choose “no”. Likely the only value you will need to enter is the latest release tag and Sentry Node BLS Secret key. ``` -Syscoin Core Github Branch [master]: enter latest release tag here. For eg. 4.3.0 +Syscoin Core Github Branch [master]: enter latest release tag here. For eg. v5.1.0 External IP Address [123.123.123.123]: Masternode Port [8369]: Masternode BLS Secret Key []: 1a8f477d2b02650b7d159efe315940f05252334eb292376309386cc99b0c4ec7 @@ -135,7 +135,7 @@ To check on sync status type; `syscli mnsync status` A pair of BLS keys for the operator were already generated above, and the secret key was entered on the Sentry Node. The public key is used in this transaction as the operatorPubKey -First, we need to get a new, unused address from the wallet to serve as the owner key address ownerKeyAddr. This is not the same as the collateral address holding 100,000 Syscoin. This address must be different for each MN. +First, we need to get a new, unused address from the wallet to serve as the owner key address ownerAddress. This is not the same as the collateral address holding 100,000 Syscoin. This address must be different for each MN. Generate a new address as follows: @@ -143,7 +143,7 @@ Generate a new address as follows: getnewaddress mn1-owner ``` -This address can also be used as the voting key address **votingKeyAddr**. Alternatively, you can specify an address provided to you by your chosen voting delegate, or simply generate a new voting key address as follows: +This address can also be used as the voting key address **votingAddress**. Alternatively, you can specify an address provided to you by your chosen voting delegate, or simply generate a new voting key address as follows: ``` getnewaddress mn1-voting @@ -155,11 +155,11 @@ Then either generate or choose an existing address to receive the owner’s Sent getnewaddress payouts ``` -You can also optionally generate and fund another address as the transaction fee source **feeSourceAddress**. If you selected an external payout address, you must specify a fee source address. +You can also optionally generate and fund another address as the transaction fee source **fundAddress**. If you selected an external payout address, you must specify a fund address. -> Either the payout address or fee source address must have enough balance to pay the transaction fee, or the register_prepare transaction will fail. +> Either the payout address or fund address must have enough balance to pay the transaction fee, or the register_prepare transaction will fail. -The private keys to the owner and fee source addresses must exist in the wallet submitting the transaction to the network. If your wallet is protected by a password, it must now be unlocked to perform the following commands. Unlock your wallet for 5 minutes: +The private keys to the owner and fund addresses must exist in the wallet submitting the transaction to the network. If your wallet is protected by a password, it must now be unlocked to perform the following commands. Unlock your wallet for 5 minutes: ``` walletpassphrase yourSecretPassword 300 @@ -176,7 +176,7 @@ We will now prepare an unsigned ProRegTx special transaction using the protx_reg This command has the following syntax: ``` -protx_register_prepare collateralHash collateralIndex ipAndPort ownerKeyAddr operatorPubKey votingKeyAddr operatorReward payoutAddress (feeSourceAddress) +protx_register_prepare collateralHash collateralIndex ipAndPort ownerAddress operatorPubKey votingAddress operatorReward payoutAddress (fundAddress) (legacy) ``` Open a text editor such as notepad ++ to prepare this command or head to [SysHub Sentry Node Registration](https://syshub-dev.web.app/masternodes/masternode-registration). @@ -186,18 +186,19 @@ Replace each argument to the command as follows: - collateralHash: The txid of the 100000 Syscoin collateral funding transaction - collateralIndex: The output index of the 100000 Syscoin funding transaction - ipAndPort: Sentry Node IP address and port, in the format x.x.x.x:yyyy -- ownerKeyAddr: The Syscoin address generated above for the owner address +- ownerAddress: The Syscoin address generated above for the owner address - operatorPubKey: The BLS public key generated above (or provided by your hosting service) -- votingKeyAddr: The Syscoin address generated above, or the address of a delegate, used for proposal voting +- votingAddress: The Syscoin address generated above, or the address of a delegate, used for proposal voting - operatorReward: The percentage of the block reward allocated to the operator as payment, 0 for no reward - this is if you want to pay someone else a % of your rewards. **This is the part where if you would like to donate to the Syscoin Foundation.** - payoutAddress: A Syscoin address to receive the owner’s Sentry Node rewards. -- feeSourceAddress: An (optional) address used to fund ProTx fee. payoutAddress will be used if not specified. +- fundAddress: An (optional) address used to fund ProTx fee. payoutAddress will be used if not specified. +- legacy: An (optional) boolean. If `true`, signs using the legacy BLS scheme. Defaults to `false` (basic BLS, the post-Nexus standard). > Note that the operator is responsible for specifying their own reward address in a separate update_service transaction if you specify a non-zero operatorReward. The owner of the Sentry Node collateral does not specify the operator’s payout address. -Either the **feeSourceAddress** or **payoutAddress** must hold a small balance since a standard transaction fee is involved. Example (remove line breaks if copying): +Either the **fundAddress** or **payoutAddress** must hold a small balance since a standard transaction fee is involved. Example (remove line breaks if copying): -Note in this example I will use the same address for owner and voting and i will have sent a small amount of Sys to the payoutAddress for fees as i am not using feeSourceAddress. +Note in this example I will use the same address for owner and voting and i will have sent a small amount of Sys to the payoutAddress for fees as i am not using fundAddress. **(Remember to lock your collateral if using a seniority address)** @@ -219,20 +220,20 @@ We will now sign the content of the signMessage (returned above) field using the The command takes the following syntax: ``` -signmessagebech32 collateralAddress signMessage +signmessage collateralAddress signMessage ``` Example: (excluding “ ”) ``` -signmessagebech32 TB59KQk6WsMaJxkc8UB3hudjtGMqfeQWSG tsys1quuu4ach5npjp3vpmaezzctc9r33405p39khz67|0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|00def144051468bdb1a855f01bf9f022091c4c0ebc745d1ecc28ac418c9af2e0 +signmessage TB59KQk6WsMaJxkc8UB3hudjtGMqfeQWSG tsys1quuu4ach5npjp3vpmaezzctc9r33405p39khz67|0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|tsys1q9aejtrvkrlnqsfeqanr5zh2wh676mvmekj4hj0|00def144051468bdb1a855f01bf9f022091c4c0ebc745d1ecc28ac418c9af2e0 ``` Output: `IGj1ORdk3yv/uAMKG+DZrBA/GTHX4dW8zn/rmMfGzOzCIaxqmyUbNveYtnqh9wLVECENMjyuyeR2VmB3ccNlRLw=` ## Submit the signed message -We will now submit the ProRegTx special transaction to the blockchain to register the Sentry Node. This command must be sent from the wallet holding a balance on either the feeSourceAddress or payoutAddress, since a standard transaction fee is involved. +We will now submit the ProRegTx special transaction to the blockchain to register the Sentry Node. This command must be sent from the wallet holding a balance on either the fundAddress or payoutAddress, since a standard transaction fee is involved. The command takes the following syntax: @@ -240,7 +241,7 @@ The command takes the following syntax: protx_register_submit tx sig ``` -Where: tx: The serialized transaction previously returned in the tx output field from the protx_register_prepare command sig: The message returned from the signmessagebech32 command. +Where: tx: The serialized transaction previously returned in the tx output field from the protx_register_prepare command sig: The message returned from the signmessage command. Example: (excluding “ ”) @@ -265,7 +266,7 @@ You can view this list on the Sentry Nodes tab in QT, or in the console using th You only need to do this if you input a value greater than 0 when completing the ProRegTx for operatorReward. ``` -protx_update_service proTxHash ipAndPort operatorKey (operatorPayoutAddress feeSourceAddress) +protx_update_service proTxHash ipAndPort operatorKey nevmAddress (operatorPayoutAddress) (feeSourceAddress) (legacy) ``` Where: @@ -273,13 +274,15 @@ Where: - proTxHash: The hash of the initial ProRegTx - ipAndPort: IP and port in the form “ip:port” - operatorKey: The operator BLS private key associated with the registered operator public key -- operatorPayoutAddress: The address used for operator reward payments. +- nevmAddress: A NEVM (EVM-format `0x...`) address to register against this Sentry Node in the on-chain NEVM Registry. Required as of Syscoin Core 5.0 (Nexus). Pass an empty string `""` to clear any previously registered address. +- operatorPayoutAddress (optional): The address used for operator reward payments. Only allowed when the ProRegTx had a non-zero operatorReward value. - feeSourceAddress (optional): An address used to fund ProTx fee. operatorPayoutAddress will be used if not specified. +- legacy (optional): If `true`, signs using the legacy BLS scheme. Defaults to `false`. Example: ``` -protx update_service 285fba6277586401f8efaf55d4eef7acfa6d690a30c0db7f213a0bb2c6194bd1 161.97.140.65:8369 1a8f477d2b02650b7d159efe315940f05252334eb292376309386cc99b0c4ec7 sys1q6u9ey7qjh3fmnz5gsghcmpnjlh2akem4xm38sw +protx_update_service 285fba6277586401f8efaf55d4eef7acfa6d690a30c0db7f213a0bb2c6194bd1 161.97.140.65:8369 1a8f477d2b02650b7d159efe315940f05252334eb292376309386cc99b0c4ec7 0xYourNEVMAddress sys1q6u9ey7qjh3fmnz5gsghcmpnjlh2akem4xm38sw ``` ## SENTRY NODE COMMANDS diff --git a/docs/guides/spts/_category_.json b/docs/guides/spts/_category_.json deleted file mode 100644 index bccac024..00000000 --- a/docs/guides/spts/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Syscoin Platform Tokens (SPTs)", - "position": 3 -} diff --git a/docs/guides/spts/aux-fees.mdx b/docs/guides/spts/aux-fees.mdx deleted file mode 100644 index 0048f19c..00000000 --- a/docs/guides/spts/aux-fees.mdx +++ /dev/null @@ -1,45 +0,0 @@ -# Auxiliary Fees - -:::info -**UPDATE:** The Syscoin Core RPCs used in the example below, and other SPT-oriented RPCs, have been deprecated and removed as of Syscoin Core 4.4. -Now **[syscoinjs-lib](https://github.com/syscoin/syscoinjs-lib)** and **[syscointx-js](https://github.com/syscoin/syscointx-js)** are used to create/manage digital assets, auxfees, and notaries on the UTXO chain. - -Examples are available at **[https://github.com/syscoin/syscoinjs-lib-examples](https://github.com/syscoin/syscoinjs-lib-examples)**. - -For a complete list of these deprecated RPCs, review the **[Syscoin Core 4.4 release notes](https://github.com/syscoin/syscoin/blob/master/doc/release-notes/release-notes-4.4.0.md)**. -::: - -Auxiliary Fees lets you define a custom fee structure for your token. These transaction fees are calculated according to the specified structure and paid to the designated Syscoin address in the form of the transacted Syscoin Platform Token (SPT). Standard network fees paid in SYS still apply. - -## Understanding auxfee_details - -Example auxfee_details: - -```text -'{"auxfee_address": "tsys1qgklj8wcyss87q2wgr84ypfj0fxtahe60788tad", "fee_struct": [[0,0.01],[10,0.004],[250,0.002],[2500,0.0007],[25000,0.00007],[250000,0.000007]]}' -``` - -**`auxfee_address`**: where transaction fees will be sent. -**`fee_struct`**: the first integer represents a range boundary pertaining to amount. The second is the fee percentage multiplier for that range. Multiple ranges can be defined in order from least to greatest boundary integer. - -**Calculation** is cumulative across the amount boundaries. - -For example, the auxiliary fee for a transaction of 251 tokens with the above fee structure would be calculated as follows: - -``` -(10 * 0.01) + (240 * 0.004) + (1 * 0.002) = 1.062 total tokens -``` - -## Implementation - -The auxfee_details structure can be defined within the RPC parameters of `assetnew` and `assetupdate`. - -Auxfee_details defined in assetnew parameter: - -```text -$syscoin-cli assetnew 100 "AUXF" "auxFee Test Token" "" 8 1000000 127 "" {} '{"auxfee_address": "tsys1qgklj8wcyss87q2wgr84ypfj0fxtahe60788tad", "fee_struct": [[0,0.01],[10,0.004],[250,0.002],[2500,0.0007],[25000,0.00007],[250000,0.000007]]}' -``` - -> ### 📘auxfee_details structure is stored in the `auxfee` field -> -> and corresponds to updatecapability_flags bitmask value 32 \ No newline at end of file diff --git a/docs/guides/spts/create-issue-tokens.mdx b/docs/guides/spts/create-issue-tokens.mdx deleted file mode 100644 index 2154b7ec..00000000 --- a/docs/guides/spts/create-issue-tokens.mdx +++ /dev/null @@ -1,332 +0,0 @@ -# Create/Issue Tokens - -:::info -**UPDATE:** The Syscoin Core RPCs used in the example below, and other SPT-oriented RPCs, have been deprecated and removed as of Syscoin Core 4.4. -Now **[syscoinjs-lib](https://github.com/syscoin/syscoinjs-lib)** and **[syscointx-js](https://github.com/syscoin/syscointx-js)** are used to create/manage digital assets, auxfees, and notaries on the UTXO chain. - -Examples are available at **[https://github.com/syscoin/syscoinjs-lib-examples](https://github.com/syscoin/syscoinjs-lib-examples)**. - -For a complete list of these deprecated RPCs, review the **[Syscoin Core 4.4 release notes](https://github.com/syscoin/syscoin/blob/master/doc/release-notes/release-notes-4.4.0.md)**. -::: - -This guide helps you create and issue a Syscoin Platform Token (SPT) using Syscoin Core 4.3. - -> ### 🚧Changes to the Syscoin Token Platform since Syscoin Core 3 -> - -> - Non-Fungible Tokens (NFT), both fractional and non-fractional, are now supported ->- All tokens are now UTXO-based (like Bitcoin) for greater efficiency instead of Account-based (like Ethereum) -> - Tokens can now be used with Syscoin Bridge when Agent nodes are active -> - Token creation fee is 1 SYS instead of 500 SYS -> - New option: notary_address, notary_details ([learn more](notary-business-rulesets)) -> - New option: auxfee_details ([learn more](aux-fees)) -> - New option: contract (the contract of the token on the NEVM chain) -> - `asset_guid` is the unique identifier of a token -> - Tokens are now address-only. On-chain aliases have been removed for greater scalability. -> - P2PWKH and P2WSH are the current supported witness programs. Future witness programs may be included in Bitcoin Core and Syscoin Core enhancements to extend functionality. - -## 1. Ensure your wallet has over 1 SYS to fund asset creation and other operations - -The token creation fee is currently 1 SYS. You'll also need extra to serve as a gas fund for the token, and for future transactions such as updating your token spec. - -If you need to send 1 or more SYS to your wallet, wait until your transaction has at least one confirmation, then proceed. - -## 2. Define and create your token - -We will now define then create the SPT using the `assetnew` command. This command will sign and broadcast the transaction to the network, and return the transaction ID. - -In this example we will create a very basic SPT without using the `contract`, `aux_fees` and `notary` options. - -```text -$ syscoin-cli help assetnew - -assetnew funding_amount "symbol" "description" "contract" precision max_supply ( updatecapability_flags "notary_address" {"endpoint":"str","instant_transfers":bool,"hd_required":bool} {"auxfee_address":"str","fee_struct":[,,...]} ) - -Create a new asset - -Arguments: -1. funding_amount (numeric or string, required) Fund resulting UTXO owning the asset by this much SYS for gas. -2. symbol (string, required) Asset symbol (1-8 characters) -3. description (string, required) Public description of the token. -4. contract (string, required) Ethereum token contract for SyscoinX bridge. Must be in hex and not include the '0x' format tag. For example contract '0xb060ddb93707d2bc2f8bcc39451a5a28852f8d1d' should be set as 'b060ddb93707d2bc2f8bcc39451a5a28852f8d1d'. Leave empty for no smart contract bridge. -5. precision (numeric, required) Precision of balances. Must be between 0 and 8. The lower it is the higher possible max_supply is available since the supply is represented as a 64 bit integer. With a precision of 8 the max supply is 10 billion. -6. max_supply (numeric or string, required) Maximum supply of this asset. Depends on the precision value that is set, the lower the precision the higher max_supply can be. -7. updatecapability_flags (numeric) Ability to update certain fields. Must be decimal value which is a bitmask for certain rights to update. The bitmask 1 represents the ability to update public data field, 2 for updating the smart contract field, 4 for updating supply, 8 for updating notary address, 16 for updating notary details, 32 for updating auxfee details, 64 for ability to update the capability flags (this field). 127 for all. 0 for none (not updatable). -8. notary_address (string) Notary address -9. notary_details (json object) Notary details structure (if notary_address is set) - { - "endpoint": "str", (string, required) Notary API endpoint (if applicable) - "instant_transfers": bool, (boolean, required) Enforced double-spend prevention on Notary for Instant Transfers - "hd_required": bool, (boolean, required) If Notary requires HD Wallet approval (for sender approval specifically applicable to change address schemes), usually in the form of account XPUB or Verifiable Credential of account XPUB using DID - } -10. auxfee_details (json object) Auxiliary fee structure (may be enforced if notary is set) - { - "auxfee_address": "str", (string, required) AuxFee address - "fee_struct": [ (json array, required) Auxiliary fee structure - , (numeric or string, required) Bound (in amount) for for the fee level based on total transaction amount - , (numeric, required) The percentage in %% to share with the operator. The value must be - between 0.00(0%%) and 0.65535(65.535%%). - ... - ], - } - -Result: -{ (json object) - "txid" : "hex", (string) The transaction id - "asset_guid" : n (numeric) The unique identifier of the new asset -} - -Examples: -> syscoin-cli assetnew 1 "CAT" "publicvalue" "contractaddr" 8 1000 127 "notary_address" {} {} -> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "assetnew", "params": [1, "CAT", "publicvalue", "contractaddr", 8, 1000, 127, "notary_address", {}, {}]}' -H 'content-type: text/plain;' http://127.0.0.1:8370/ -``` - -> ### 📘aux_fees -> -> The aux_fees parameter is used to specify a custom fee structure for your token. [Learn about aux_fees and how to use them](aux-fees). - -Summary of `assetnew` arguments: - -``` -assetnew "" "" "" "" {} {} -``` - -**A standard fungible token** looks as follows: - -```text -$ syscoin-cli assetnew 100 "MYASSET" "This is my asset, a very good asset" "" 8 10000 127 "" {} {} - -{ - "txid": "67bbbeb8635bf6894c460bfda4cda0ced2a69e3e9ebe01dd9bba54e878d043ad", - "asset_guid": 3942786440 -} -``` - -**A non-fractional (indivisible), non-fungible token** can be created as follows with precision set to zero and max supply 1.0: - -```text -$ syscoin-cli assetnew 100 "ANDYSELF" "Self-Portrait, Andy Warhol, Original (1963)" "" 0 1.0 127 "" {} {} -``` - -**A fractional (divisible) non-fungible token** is created when a token is issued via `assetsend` with a NFTID specified. See section 4b(i) below. - -Record the assigned asset GUID for future use. - -Wait for this transaction to receive at least one confirmation, then proceed. - -## 3. Check the token specification - -Review your token specification as it exists on the Syscoin blockchain by executing this command: `assetinfo ` - -It should look similar to this and reflect the attributes you have most recently set: - -```text -$ syscoin-cli assetinfo 3942786440 - -{ - "asset_guid": 3942786440, - "symbol": "MYASSET", - "public_value": { - "desc": "This is my asset, a very good asset" - }, - "contract": "", - "notary_address": "", - "total_supply": 0.00000000, - "max_supply": 10000.00000000, - "updatecapability_flags": 127, - "precision": 8 -} -``` - -The total supply will remain "0" until you use `assetsend` to issue some of the tokens. - -> ### 📘A note on issuance: The difference between `assetsend` and `assetallocationsend` -> -> `assetsend` is not for sending existing tokens from one address to another (asset allocation), it is strictly for issuance of tokens by the owner of the token specification. -> -> Token users can learn how to perform basic asset allocations with `assetallocationsend` [here](use-tokens). - -## 4. Issue Fungible Tokens - -This step covers how to issue a quantity of fungible tokens into circulation. - -`assetsend` will issue and allocate a designated quantity of tokens to an address. It also signs and broadcasts the transaction to the network, and returns the transaction ID. - -```text -$ help assetsend - -assetsend asset_guid "address" amount ( sys_amount NFTID ) - -Send an asset you own to another address. - -Arguments: -1. asset_guid (numeric, required) The asset guid. -2. address (string, required) The address to send the asset to (creates an asset allocation). -3. amount (numeric or string, required) Amount of asset to send. -4. sys_amount (numeric or string) Amount of syscoin to send. -5. NFTID (numeric) Optional NFT ID to send - -Result: -{ (json object) - "txid" : "hex" (string) The transaction id -} - -Examples: -> syscoin-cli assetsend "asset_guid" "address" "amount" "sys_amount" "NFTID" -> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "assetsend", "params": ["asset_guid", "address", "amount", "sys_amount", "NFTID"]}' -H 'content-type: text/plain;' http://127.0.0.1:8370/ -``` - -Summary of `assetsend` arguments: - -``` -assetsend "" -``` - -In this simple example we will not specify an NFTID - leave this blank. The issuance is handled as fungible when NFTID **is not** used. We will include a small amount of SYS for gas. - -Our command for issuing a fungible portion of 425 tokens is as follows: - -```text -$ syscoin-cli assetsend 3942786440 "tsys1q7mn0aymk3cwv0uf3udegn68l3u5equz0x02jev" 425 0.0000098 - -{ - "txid": "fcdb5d1793cc40c7f266e3f8fd8f8b74ffdf8f8f1e9c5e8b2c1c3aea9e36a4e9", - "assets_issued_count": 1, - "assets_issued": [ - { - "asset_guid": 3942786440, - "amount": 425.00000000, - "sys_amount": 0.00000980 - } - ] -} -``` - -## 4b. Issue Non-Fungible Tokens - -This step covers how to issue and transfer a non-fungible token to its first owner. **To issue fungible tokens, go to subsection 4a.** - -Syscoin 4.2 enables issuers to **optionally** assign a unique identifier to an issuance, which effectively makes it an NFT. Using `assetsend` with NFTID will issue and allocate a non-fungible token to an address. It also signs and broadcasts the transaction to the network, and returns the transaction ID. - -Further, **Divisible and Non-Divisible NFTs can be issued.** This article covers how to do both. - -> ### 📘NFT Data -> -> The issuer-assigned ID of an NFT is stored on the Syscoin blockchain (NFTID). Beyond the unique identifier, storage of any detailed-oriented data associated with the asset is the responsibility of the issuer, and isn't stored on the Syscoin blockchain. This is part of what keeps the Syscoin blockchain and its NFT functionality efficient and scalable. -> -> The issuer-assigned NFTID is a 4 byte unsigned integer with a max value of 4294967295. Syscoin Core also assigns a unique identifier of the same byte-length and type to ensure global uniqueness on the blockchain. The total footprint of an NFT is only 8 bytes greater than a standard fungible token. - -## 4b(i). How to Issue and Transfer a Fractional (Divisible) Non-Fungible Token - -In this example we will work with a testnet asset representing an inventory of up to 1,000 serialized 100oz gold bars, 6 of which have already been issued to owners. - -```text -$ syscoin-cli assetinfo 2433418946 - -{ - "asset_guid": 2433418946, - "symbol": "AU100", - "public_value": { - "desc": "XYZ Vaulting Co. - 100oz AU bar - Royal Canadian Mint - Serialized" - }, - "contract": "", - "notary_address": "", - "total_supply": 6.000000, - "max_supply": 1000.000000, - "updatecapability_flags": 127, - "precision": 6 -} -``` - -**1.** issue another entire bar (1 new token) and identify it with the serial number stamped on the physical asset by the Royal Canadian Mint (13077), and send to a designated recipient address - in this case an address for which you hold the key. Send a small amount of SYS for gas to be used in the future, too. - -```text -$ syscoin-cli assetsend 2433418946 "tsys1qs5wd5gftn22dtf7d00gvfkhjvdkdvlufpk86wj" 1 0.0000098 13077 - -{ - "txid": "4946da4260cb5b8eed4f6be95673fd2aa48d349df2ed81921faed04eef4fb01b", - "assets_issued_count": 1, - "assets_issued": [ - { - "asset_guid": 56167720748738, - "base_asset_guid": 2433418946, - "NFTID": 13077, - "amount": 1.00000000, - "sys_amount": 0.00000980 - } - ] -} -``` - -**2.** Transfer 12.7251% ownership of the bar (56167720748738) to another address by using `assetallocationsend`. We will also send the address a small amount of SYS for gas to be used in the future. We'll make the transaction use Z-DAG by specifying to be `false`. - -```text -$ syscoin-cli assetallocationsend 56167720748738 tsys1qcycfg3uhw4x706nvqtaz0e6lu74zwsc2qvy4vs 0.127251 0.0000098 false - -{ - "txid": "737abcbfa2d42e2188966343b169442c8067c82d133a39d27ad56015076376cf", - "assetallocations_sent_count": 1, - "assetallocations_sent": [ - { - "asset_guid": 56167720748738, - "base_asset_guid": 2433418946, - "NFTID": 13077, - "amount": 0.12725100, - "sys_amount": 0.00000980 - } - ] -} -``` - -## 4b(ii). How to Issue and Transfer a Non-Fractional Non-Fungible Token - -In this example we will start with a testnet asset representing the inventory of an art vault. - -```text -$ syscoin-cli assetinfo 389115219 - -{ - "asset_guid": 389115219, - "symbol": "VAULT9", - "public_value": { - "desc": "Fitzstephen Co. Art Vault #9" - }, - "contract": "", - "notary_address": "", - "total_supply": 0.00000000, - "max_supply": 288.0, - "updatecapability_flags": 127, - "precision": 0 -} -``` - -**This asset was defined with a precision of 0 and a max supply of 288, because there are 288 art pieces held in the vault, and ownership of each of these will be transferred to one owner as a non-divisible token representing the entirety of the piece** - -> ### 📘Note -> -> You can also create an asset with precision 0 and max supply 1, effectively making the primary asset itself a non-divisble NFT. However, it's often more intuitive to issue multiple unique non-divisible tokens from a single parent asset (the inventory). This is more cost effective as you pay the asset creation fee only once (1 SYS) and are able to issue a quantity of unique child NFT's up to the max supply of the parent asset, only paying the comparatively small fee associated with `assetsend` for each new NFT. -> -> Children assets inherit the attributes of the parent and are unique only by their NFTID and deterministic child assetGUID. If you want each NFT you issue to use a different Notary API, on-chain description, etc, you would use `assetnew` and pay the asset creation fee for each of them. - -Issue one of the art pieces into the new owner's possession with `assetsend` in the amount of 1 token, and assign the NFTID (your own numeric identifier representing the art piece), in this case 14, your inventory number for Andy Warhol's original Self Portrait. We'll also send the new owner a small amount of SYS for gas to be used in the future (0.000098). - -```text -$ syscoin-cli assetsend 389115219 "tsys1qktelej8knjvc5nfpka2evnwyfsw6ltqnhd9k2f" 1.0 0.0000098 14 - -{ - "txid": "4ef2b4f0a807f2542567cc79201ddf8b22aadb0156ac54313cd0e186ef210296", - "assets_issued_count": 1, - "assets_issued": [ - { - "asset_guid": 4684082515, - "base_asset_guid": 389115219, - "NFTID": 14, - "amount": 1.0, - "sys_amount": 0.00000980 - } - ] -} -``` - -The new owner can now transfer ownership using `assetallocationsend` with 4684082515 - diff --git a/docs/guides/spts/notary-business-rulesets.mdx b/docs/guides/spts/notary-business-rulesets.mdx deleted file mode 100644 index 9b3f58bf..00000000 --- a/docs/guides/spts/notary-business-rulesets.mdx +++ /dev/null @@ -1,122 +0,0 @@ -# Notary and Business Rulesets - -:::info -**UPDATE:** The Syscoin Core RPCs used in the example below, and other SPT-oriented RPCs, have been deprecated and removed as of Syscoin Core 4.4. -Now **[syscoinjs-lib](https://github.com/syscoin/syscoinjs-lib)** and **[syscointx-js](https://github.com/syscoin/syscointx-js)** are used to create/manage digital assets, auxfees, and notaries on the UTXO chain. - -Examples are available at **[https://github.com/syscoin/syscoinjs-lib-examples](https://github.com/syscoin/syscoinjs-lib-examples)**. - -For a complete list of these deprecated RPCs, review the **[Syscoin Core 4.4 release notes](https://github.com/syscoin/syscoin/blob/master/doc/release-notes/release-notes-4.4.0.md)**. -::: - -You can require that allocations of your asset meet rules you define in order to be notarized and allowed to settle on-chain. With a Notary endpoint, any allocation of the asset must pass the endpoint's checks to be granted a notary signature and be accepted into a block. - -This general-purpose feature is particularly useful for ensuring asset transactions are compliant with regulations prior to receiving approval. It can also be used to add an optional trust-based security domain for expedited service. - -You can read more about the design and philosophy behind this capability [here](https://github.com/syscoin/sips/blob/master/sip-0002.mediawiki). - -To begin, let's look at an asset notary example; Asset GUID `1815902629`. - -```text -> syscoin-cli assetinfo 1815902629 - -{ - "asset_guid": "1815902629", - "symbol": "FANCY", - "public_value": { - "desc": "NFT with auxfees and notary" - }, - "contract": "", - "notary_address": "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q", - "notary_details": { - "endpoint": "https://116.203.116.18:8081/notarize", - "instant_transfers": 1, - "hd_required": 0 - }, - "auxfee": { - "auxfee_address": "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q", - "fee_struct": [ - { - "bound": 0.00000000, - "percentage": 0.01 - }, - { - "bound": 10.00000000, - "percentage": 0.004 - }, - { - "bound": 250.00000000, - "percentage": 0.002 - }, - { - "bound": 2500.00000000, - "percentage": 0.0007 - }, - { - "bound": 25000.00000000, - "percentage": 6e-05 - }, - { - "bound": 250000.00000000, - "percentage": 0 - } - ] - }, - "total_supply": 10.00000000, - "max_supply": 9999.00000000, - "updatecapability_flags": 127, - "precision": 8 -} -``` - -## Relevant Fields - -### notary_address (string) - -Public key of the endpoint's notary signer. Typically an address chosen by the issuer for which the Notary holds the private key. If specified, the private key associated with this address must sign any transaction of this asset in order for the network to accept it into a block. - -### notary_details.endpoint (string) - -API endpoint URL. - -When a client executes `assetallocationsend`, an HTTP `POST` is sent to the endpoint specified here and the client awaits a response. Response timeout is 15 seconds. - -The client's `POST` provides the endpoint a raw transaction hex which the notary then decodes, parses, then logically processes. - -The endpoint URL can point to any application or script of any language that can receive and process POST requests and provide an appropriate JSON response. The endpoint must return details of a successfully notarized (signed) transaction broadcasted to the network or the client's request is considered failed or rejected. - -Endpoint programs can interact with Syscoin by making RPC calls directly to a Syscoin Core instance (see [syscoin-js](https://github.com/syscoin/syscoin-js)), or through a Web3 approach by using a combination of [syscoinjs-lib](https://github.com/syscoin/syscoinjs-lib) and [Syscoin Blockbook](https://github.com/syscoin/blockbook). - -A rudimentary example of a notary endpoint script is available [here](https://github.com/syscoin/notary-endpoint/). - -### notary_details.instant_transfers (boolean) - -This flag indicates whether the notary is offering a guarantee of extra security in prevention of double spends. Recipients can instantly redeem/spend notarized inputs if they fully trust the notary's security. - -This security path theoretically can provide payment service even faster than Z-DAG's decentralized relay and is based on an optional trust trade-off. - -Endpoints can ensure protection against double spends by tracking spend requests of an input and responding to them based on the existence (or lack) of prior spend attempts. - -If `0`, the notary is not guaranteeing any supplementary security measures and transactors of the asset should rely exclusively upon Z-DAG and/or Syscoin Core consensus. - -### notary_details.hd_required (boolean) - -This flag indicates the notary requires HD wallet approval (for sender approval specifically applicable to change address schemes), usually in the form of the account XPUB or verifiable credential of the account XPUB using decentralized identity - - - -## How to Enable Notary - -An issuer can enable Notary on an asset by setting parameters in `assetnew` (upon asset creation), or `assetupdate` (updating the asset spec, if the asset's current `update_capabilityflags` value permits this). - -Enable Notary via `assetnew`: - -```text -> syscoin-cli assetnew 100 "ECASH" "Non-custodial KYC/AML-enabled Electronic Cash" "" 8 888000000 127 "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q" "{\"endpoint\":\"https://116.203.116.18:8081/notarize\", \"instant_transfers\": 0, \"hd_required\": 1}" {} -``` - -Enable Notary via `assetupdate`: - -```text -> syscoin-cli assetupdate 1020176632 "Non-custodial KYC/AML-enabled Electronic Cash" "" 127 "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q" "{\"endpoint\":\"https://116.203.116.18:8081/notarize\", \"instant_transfers\": 0, \"hd_required\": 1}" {} -``` \ No newline at end of file diff --git a/docs/guides/spts/use-tokens.mdx b/docs/guides/spts/use-tokens.mdx deleted file mode 100644 index 799bd8bc..00000000 --- a/docs/guides/spts/use-tokens.mdx +++ /dev/null @@ -1,178 +0,0 @@ -# Use Syscoin 4.2 Tokens - -:::info -**UPDATE:** The Syscoin Core RPCs used in the example below, and other SPT-oriented RPCs, have been deprecated and removed as of Syscoin Core 4.4. -Now **[syscoinjs-lib](https://github.com/syscoin/syscoinjs-lib)** and **[syscointx-js](https://github.com/syscoin/syscointx-js)** are used to create/manage digital assets, auxfees, and notaries on the UTXO chain. - -Examples are available at **[https://github.com/syscoin/syscoinjs-lib-examples](https://github.com/syscoin/syscoinjs-lib-examples)**. - -For a complete list of these deprecated RPCs, review the **[Syscoin Core 4.4 release notes](https://github.com/syscoin/syscoin/blob/master/doc/release-notes/release-notes-4.4.0.md)**. -::: - -Syscoin 4.2 introduced changes to the process of using tokens. - -## Before Trading a Syscoin Asset/Token - -**Obtain the correct Asset GUID.** - -An asset has several noteworthy properties. The most important is `asset_guid` which is the unique identifier of the token. For example, the asset_guid of the official testnet SYSX token is 1965866356. Anyone can create a token and name it "SYSX" but there will only be one SYSX with `asset_guid` of 1965866356. We can inspect the asset information using `assetinfo`. We will be using this asset as an example for the rest of the guide. - -```text -$ syscoin-cli assetinfo 1965866356 -{ - "asset_guid": 1965866356, - "symbol": "SYSX", - "public_value": { - "desc": "Official Testnet SYSX SPT" - }, - "contract": "", - "notary_address": "", - "total_supply": 1009467.75000000, - "max_supply": 888000000.00000000, - "updatecapability_flags": 127, - "precision": 8 -} -``` - -## Querying Syscoin Assets - -Use `assetallocationbalance` to check an asset balance. This function allows you to see the balance of an asset across your entire wallet by default or for specific addresses. - -**To check the asset balance of the wallet, use:** -`assetallocationbalance ` - -```text -$ syscoin-cli assetallocationbalance 1965866356 - -{ - "amount": 0.00000980, - "asset_amount": 19.00000000 -} -``` - -**To check the asset balance of specific addresses, use:** -`assetallocationbalance "[\"
\",\"
\"]"` - -```text -$ syscoin-cli assetallocationbalance 1965866356 "[\"tsys1qedy7ukgnj9e96axgarw79e2au98ff9g4ffh829\",\"tsys1qecwhh7lckpamavny534xcgrq4z9nm4ckajj9gm\"]" - -{ - "amount": 0.00001960, - "asset_amount": 3.55000000 -} -``` - -## Sending Syscoin Assets - -The process commonly thought of as "sending" is called asset allocation. A quantity of a token can be allocated to one or more addresses. The Syscoin token platform uses the UTXO model like Bitcoin. This means asset allocations are inputs of an asset sent to an address which can then output them to another address. Most asset owners and exchanges work with asset allocations rather than the asset specification itself. - -**Use `assetallocationsend` to allocate a quantity of a token to a single recipient address. This command will sign and broadcast the transaction to the network and return the transaction ID.** - -> ### 📘Asset Input Selection -> -> Asset inputs are selected automatically when using `assetallocationsend` with the Syscoin QT wallet. If you want direct control over asset input selection you can use tools such as the [syscoinjs-lib](https://github.com/syscoin/syscoinjs-lib) SDK or the syscoin-tx binary to build your transaction. - -```text -assetallocationsend asset_guid "address" amount ( replaceable ) - -Send an asset allocation you own to another address. - -Arguments: -1. asset_guid (numeric, required) The asset guid -2. address (string, required) The address to send the allocation to -3. amount (numeric or string, required) Amount of asset to send -4. sys_amount (numeric or string) Amount of syscoin to send -5. replaceable (boolean, optional, default=wallet default) Allow this transaction to be replaced by a transaction with higher fees via BIP 125. ZDAG is only possible if RBF is disabled. - -Result: -{ (json object) - "txid" : "hex" (string) The transaction id -} - -Examples: -> syscoin-cli assetallocationsend "asset_guid" "address" "amount" "sys_amount" "false" -> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "assetallocationsend", "params": ["asset_guid", "address", "amount", "sys_amount", "false"]}' -H 'content-type: text/plain;' http://127.0.0.1:8370/ -``` - -`assetallocationsend ` -Set argument `replaceable` to `false` in order to use Z-DAG. - -Allocate an asset to a single address: - -```text -$ syscoin-cli assetallocationsend 1965866356 "tsys1qecwhh7lckpamavny534xcgrq4z9nm4ckajj9gm" 2 0.0000098 false - -{ - "txid": "93cce1d891e4ce5bfc30131ab15faf356000772c1abd92dc47698abaeb022588", - "assetallocations_sent_count": 1, - "assetallocations_sent": [ - { - "asset_guid": 1965866356, - "amount": 2.00000000, - "sys_amount": 0.00000980 - } - ] -} -``` - -**Use `assetallocationsendmany` to allocate quantities of tokens to multiple addresses all within a single transaction. This command allows you to separately specify the asset and the quantity to be allocated to each individual recipient address, as well as the amount of SYS to send them for gas to be used in the future. This command will sign and broadcast the transaction to the network and return the transaction ID.** - -**The maximum number of recipients in a single asset transaction is 250.* - -```text -assetallocationsendmany [assetallocationsend object]... ( replaceable "comment" conf_target "estimate_mode" ) - -Send an asset allocation you own to another address. Maximum recipients is 250. - -Arguments: -1. amounts (json array, required) Array of assetallocationsend objects - [ - { (json object) The assetallocationsend object - "asset_guid": n, (numeric, required) Asset guid - "address": "str", (string, required) Address to transfer to - "amount": amount, (numeric or string, required) Amount of asset to send - "sys_amount": amount, (numeric or string) Amount of Syscoin to send - }, - ... - ] -2. replaceable (boolean, optional, default=wallet default) Allow this transaction to be replaced by a transaction with higher fees via BIP 125. ZDAG is only possible if RBF is disabled. -3. comment (string, optional) A comment -4. conf_target (numeric, optional, default=wallet default) Confirmation target (in blocks) -5. estimate_mode (string, optional, default=UNSET) The fee estimate mode, must be one of: - "UNSET" - "ECONOMICAL" - "CONSERVATIVE" - -Result: -{ (json object) - "txid" : "hex" (string) The transaction id -} - -Examples: -> syscoin-cli assetallocationsendmany '[{"asset_guid":1045909988,"address":"sysaddress1","amount":100},{"asset_guid":1045909988,"address":"sysaddress2","amount":200}]' "false" -> syscoin-cli assetallocationsendmany "[{\"asset_guid\":1045909988,\"address\":\"sysaddress1\",\"amount\":100},{\"asset_guid\":1045909988,\"address\":\"sysaddress2\",\"amount\":200}]" "true" -> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "assetallocationsendmany", "params": ['[{"asset_guid":1045909988,"address":"sysaddress1","amount":100},{"asset_guid":1045909988,"address":"sysaddress2","amount":200}]',"false"]}' -H 'content-type: text/plain;' http://127.0.0.1:8370/ -> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "assetallocationsendmany", "params": ["[{\"asset_guid\":1045909988,\"address\":\"sysaddress1\",\"amount\":100},{\"asset_guid\":1045909988,\"address\":\"sysaddress2\",\"amount\":200}]","true"]}' -H 'content-type: text/plain;' http://127.0.0.1:8370/' -H 'content-type: text/plain;' http://127.0.0.1:8370/ -> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id": "curltest", "method": "assetallocationsendmany", "params": ["[{\"asset_guid\":1045909988,\"address\":\"sysaddress1\",\"amount\":100},{\"asset_guid\":1045909988,\"address\":\"sysaddress2\",\"amount\":200}]","true"]}' -H 'content-type: text/plain;' http://127.0.0.1:8370/ -assetallocationsendmany '[{"asset_guid": , "address": ,"amount": , "sys_amount": },{"asset_guid": , "address": ,"amount": , "sys_amount": }]' -``` - -Set argument `replaceable` to `false` in order to use Z-DAG. - -Allocate one or more assets to multiple addresses: - -```text -$ syscoin-cli assetallocationsendmany '[{"asset_guid": 1965866356,"address":"tsys1qecwhh7lckpamavny534xcgrq4z9nm4ckajj9gm","amount":1.55,"sys_amount":0.0000098},{"asset_guid":1965866356,"address":"tsys1ql8h9gknschcwqmehz4hhaykdn6wju8cemj9met","amount":2.75, "sys_amount":0.0000098}]' false - -{ - "txid": "d6964154f1b11954f86b74953d24e2c79efe6266f9a6e954fdce8d3861b62de2", - "assetallocations_sent_count": 1, - "assetallocations_sent": [ - { - "asset_guid": 1965866356, - "amount": 4.30000000, - "sys_amount": 0.00001960 - } - ] -} -``` \ No newline at end of file diff --git a/docs/tech/notary.mdx b/docs/tech/notary.mdx index 6e99690d..c7e2dde7 100644 --- a/docs/tech/notary.mdx +++ b/docs/tech/notary.mdx @@ -1,127 +1,12 @@ # Notary and Business Rulesets -On Syscoin's native UTXO chain, an asset issuer can opt to introduce a permissioned layer in the form of a notary for their specific token, such that simple value transfers of that asset must meet rules defined by the issuer in order to be notarized and allowed to settle on-chain. With a Notary endpoint, any allocation of the asset must pass the endpoint's checks to be granted the notary's signature and be accepted into a block. +In Syscoin's pre-Nexus (4.x) SPT design, an asset issuer could attach a **notary** to an SPT — a permissioned endpoint that had to sign every transfer of that asset for it to settle on-chain. This let issuers enforce arbitrary off-chain rules (KYC/AML checks, sanctions screening, business rules) on a public chain without taking custody of the asset themselves. -## Regulatory Compliance at Scale +The design rationale is documented in [SIP-0002](https://github.com/syscoin/sips/blob/master/sip-0002.mediawiki). -This feature is particularly useful for stablecoin redemption, ensuring asset transactions are compliant with regulations prior to receiving approval. It enables asset issuers to attain pre-compliance on a public blockchain without requiring a third-party to take custody of the asset, while providing for issuers to adapt their rulesets to ever-changing industry regulations. +## Status in Syscoin Core 5.x -## General Purpose - -This feature can also be tied to any set of business rules the token issuer wishes to trigger and/or enforce. This can also be used to add an optional trust-based security domain for expedited service. - -You can read more about the design and philosophy behind this capability in [SIP-0002](https://github.com/syscoin/sips/blob/master/sip-0002.mediawiki). - -## How to Implement - -:::info -**UPDATE:** The Syscoin Core RPCs used in the example below, and other SPT-oriented RPCs, have been deprecated and removed as of Syscoin Core 4.4. -Now **[syscoinjs-lib](https://github.com/syscoin/syscoinjs-lib)** and **[syscointx-js](https://github.com/syscoin/syscointx-js)** are used to create/manage digital assets, auxfees, and notaries on the UTXO chain. - -Examples are available at **[https://github.com/syscoin/syscoinjs-lib-examples](https://github.com/syscoin/syscoinjs-lib-examples)**. - -For a complete list of these deprecated RPCs, review the **[Syscoin Core 4.4 release notes](https://github.com/syscoin/syscoin/blob/master/doc/release-notes/release-notes-4.4.0.md)**. -::: - -To begin, let's look at an asset notary example within a Syscoin Core console. - - - -``` -> syscoin-cli assetinfo 1815902629 - -{ - "asset_guid": "1815902629", - "symbol": "FANCY", - "public_value": { - "desc": "NFT with auxfees and notary" - }, - "contract": "", - "notary_address": "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q", - "notary_details": { - "endpoint": "https://111.111.111.111:8081/notarize", - "instant_transfers": 1, - "hd_required": 0 - }, - "auxfee": { - "auxfee_address": "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q", - "fee_struct": [ - { - "bound": 0.00000000, - "percentage": 0.01 - }, - { - "bound": 10.00000000, - "percentage": 0.004 - }, - { - "bound": 250.00000000, - "percentage": 0.002 - }, - { - "bound": 2500.00000000, - "percentage": 0.0007 - }, - { - "bound": 25000.00000000, - "percentage": 6e-05 - }, - { - "bound": 250000.00000000, - "percentage": 0 - } - ] - }, - "total_supply": 10.00000000, - "max_supply": 9999.00000000, - "updatecapability_flags": 127, - "precision": 8 -} -``` - - -### Relevant Fields -**notary_address (string)** -Public key of the endpoint's notary signer. Typically an address chosen by the issuer for which the Notary holds the private key. If specified, the private key associated with this address must sign any transaction of this asset in order for the network to accept it into a block. - -**notary_details.endpoint (string)** -API endpoint URL. - -When a client executes assetallocationsend, an HTTP POST is sent to the endpoint specified here and the client awaits a response. Response timeout is 15 seconds. - -The client's POST provides the endpoint a raw transaction hex which the notary then decodes, parses, then logically processes. - -The endpoint URL can point to any application or script of any language that can receive and process POST requests and provide an appropriate JSON response. The endpoint must return details of a successfully notarized (signed) transaction broadcasted to the network or the client's request is considered failed or rejected. - -Endpoint programs can interact with Syscoin by making RPC calls directly to a Syscoin Core instance (see syscoin-js), or through a Web3 approach by using a combination of syscoinjs-lib and Syscoin Blockbook. - -A rudimentary example of a notary endpoint is available [here](https://github.com/syscoin/notary-endpoint/). - -**notary_details.instant_transfers (boolean)** -This flag indicates whether the notary is offering a guarantee of extra security in prevention of double spends. Recipients can instantly redeem/spend notarized inputs if they fully trust the notary's security. - -This security path theoretically can provide payment service even faster than Z-DAG's decentralized relay and is based on an optional trust trade-off. - -Endpoints can ensure protection against double spends by tracking spend requests of an input and responding to them based on the existence (or lack) of prior spend attempts. - -If 0, the notary is not guaranteeing any supplementary security measures and transactors of the asset should rely exclusively upon Z-DAG and/or Syscoin Core consensus. - -**notary_details.hd_required (boolean)** -This flag indicates the notary requires HD wallet approval (for sender approval specifically applicable to change address schemes), usually in the form of the account XPUB or verifiable credential of the account XPUB using decentralized identity - -### How to Activate Notary - -An issuer can enable Notary on an asset by setting parameters in assetnew (upon asset creation), or assetupdate (updating the asset spec, if the asset's current update_capabilityflags value permits this). - -Enable Notary via `assetnew` -``` -> syscoin-cli assetnew 100 "ECASH" "Non-custodial KYC/AML-enabled Electronic Cash" "" 8 888000000 127 "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q" "{\"endpoint\":\"https://111.111.111.111:8081/notarize\", \"instant_transfers\": 0, \"hd_required\": 1}" {} -``` - -Enable Notary via `assetupdate` -``` -> syscoin-cli assetupdate 1020176632 "Non-custodial KYC/AML-enabled Electronic Cash" "" 127 "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q" "{\"endpoint\":\"https://111.111.111.111:8081/notarize\", \"instant_transfers\": 0, \"hd_required\": 1}" {} -``` - +The 4.x notary mechanism was tied to the legacy SPT RPCs (`assetnew`, `assetupdate`, `assetallocationsend`), all of which were **removed in the Nexus upgrade (Syscoin Core 5.0)**. SPT issuance now flows through the NEVM bridge (see [SPTs](/docs/tech/tokens)), so equivalent compliance overlays are expected to be built at the NEVM contract layer (e.g. as transfer hooks on the underlying ERC-20 / ERC-721) rather than as a Core-level notary. +There is currently no first-party Syscoin Core 5.x equivalent of the 4.x notary feature. Issuers needing this functionality should implement it on the NEVM side of the bridge before tokens are minted across to the UTXO chain. diff --git a/docs/tech/rollux.mdx b/docs/tech/rollux.mdx index 77d41bb0..98a63973 100644 --- a/docs/tech/rollux.mdx +++ b/docs/tech/rollux.mdx @@ -122,7 +122,7 @@ A. Refer to our **[RPC documentation](https://sys-labs.github.io/community-hub/d **Q. Can you provide sample transactions of Rollux settling a batch on Syscoin NEVM and using PoDA on Syscoin Native (UTXO), and further info?** A. Yes. These are testnet transactions. NEVM: **** -PoDA: **** +PoDA: **** Note: The Blockbook explorer does not currently parse the PoDA hash, but it is visible in the raw transaction data as scriptPubKey.asm: `OP_RETURN 207f262f3352669030f480dd881bc6b3fad68abfcffe81d8e98c7f3e88871ed3a4` diff --git a/docs/tech/tokens.mdx b/docs/tech/tokens.mdx index 8d4ae2df..0f42e1ad 100644 --- a/docs/tech/tokens.mdx +++ b/docs/tech/tokens.mdx @@ -1,10 +1,18 @@ # Syscoin Platform Tokens (SPTs) +Syscoin Platform Tokens (SPTs) are tokens that live on the Syscoin native (UTXO) chain rather than on the NEVM (EVM) side. Because they are UTXO-based, SPT transactions inherit the efficiency, privacy, and composability of Bitcoin-style transfers — and can take advantage of Syscoin's [Z-DAG](/docs/tech/z-dag) for fast settlement. +## How SPTs work today (Syscoin Core 5.x / post-Nexus) -Syscoin Platform Tokens, or SPTs for short, are tokens that reside on the Syscoin Native (UTXO) blockchain, rather than the Syscoin NEVM blockchain that runs alongside it and supports ERC-20 tokens. SPTs are UTXO-based tokens (so transactions operate like Bitcoin transactions), rather than account-based (like Ethereum), this offers greater efficiency and allows SPTs to support any current or new innovations that are made available on Bitcoin, such as Lightning Network or Taproot. SPTs can also take advantage of Syscoin's [Z-DAG](/docs/tech/z-dag) technology, for blisteringly fast token payments. Find out how to create your own SPTs [here](/docs/guides/spts/create-issue-tokens). +The SPT design was redesigned in the [Nexus upgrade (Syscoin Core 5.0)](https://github.com/syscoin/syscoin/blob/master/doc/release-notes/release-notes-5.0.0.md). Issuance and management no longer go through dedicated UTXO-side RPCs; instead, SPTs are minted and redeemed through the **NEVM bridge**: +- Tokens originate on the NEVM side (typically as ERC-20 / ERC-721 / ERC-1155 contracts). +- The [SyscoinVaultManager](https://explorer.syscoin.org/address/0x7904299b3D3dC1b03d1DdEb45E9fDF3576aCBd5f) contract on NEVM locks tokens and triggers minting of the corresponding SPT on the UTXO side. +- Once on the UTXO side, SPTs can be transferred natively (with Z-DAG support) and bridged back through the same vault. +The legacy `assetnew`, `assetupdate`, `assetallocationsend`, and related RPCs were removed in 5.0; client code should use [syscoinjs-lib](https://github.com/syscoin/syscoinjs-lib) for UTXO-side SPT transfers and the bridge for issuance. -Another useful aspect of SPTs is the possibility to create Non-Fungible Tokens (NFTs). These are very lightweight; compared to a standard, fungible token they use only 4 extra bytes on the blockchain. If you are interested in checking them out you can download [Pali Wallet](https://paliwallet.com/), a browser extension wallet that supports Syscoin and SPTs, and mint some NFTs on [SysMint](https://sysmint.paliwallet.com/). +## NFTs + +SPTs also support non-fungible tokens. As with fungible SPTs, NFTs in 5.x are bridged from NEVM (ERC-721 / ERC-1155) rather than created via Core RPCs directly. The browser-extension wallet [Pali Wallet](https://paliwallet.com/) supports viewing and transferring SPT-side balances. diff --git a/docs/tech/z-dag.mdx b/docs/tech/z-dag.mdx index 82d84c15..6717c375 100644 --- a/docs/tech/z-dag.mdx +++ b/docs/tech/z-dag.mdx @@ -54,7 +54,7 @@ Z-DAG is proprietary to Syscoin's native UTXO chain. It is not designed to func **These represent some of the most positive throughput statistics in the industry** for a decentralized ledger network. We plan to perform even more thorough testing once sufficient optimizations have been introduced. Substantial resources would be required to even approach pushing Z-DAG to its limit on the live mainnet. -Whiteblock's report on Z-DAG is public: [Full Report](https://www.whiteblock.io/wp-content/uploads/2019/07/ZDAG-Analysis.pdf), [Summary Report](https://whiteblock.io/wp-content/uploads/2019/12/ZDAG-Case-Study.pdf) +Whiteblock's 2019 report on Z-DAG is no longer hosted at its original URL; a summary of the audit results is preserved in the [Syscoin whitepaper](https://syscoin.org/whitepaper#tps). ### Scaling to Global Population Demand diff --git a/package.json b/package.json index 63cea498..b0bc1384 100644 --- a/package.json +++ b/package.json @@ -43,6 +43,12 @@ "url": "^0.11.3", "url-loader": "^4.1.1" }, + "resolutions": { + "webpack": "5.75.0" + }, + "overrides": { + "webpack": "5.75.0" + }, "browserslist": { "production": [ ">0.5%",