Skip to main content

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.

Regulatory Compliance at Scale#

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.

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.

How to Implement#


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

For a complete list of these deprecated RPCs, review the Syscoin Core 4.4 release notes.

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": "",
"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.

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\":\"\", \"instant_transfers\": 0, \"hd_required\": 1}" {}

Enable Notary via assetupdate

> syscoin-cli assetupdate 1020176632 "Non-custodial KYC/AML-enabled Electronic Cash" "" 127 "tsys1qzy52g933vjc66kw9rnwk2mz25rnymv29q0dr8q" "{\"endpoint\":\"\", \"instant_transfers\": 0, \"hd_required\": 1}" {}