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 and 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.
For a complete list of these deprecated RPCs, review the Syscoin Core 4.4 release notes.
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.
To begin, let's look at an asset notary example; Asset GUID 1815902629.
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 script is available here.
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:
Enable Notary via assetupdate: