User Diligence

Syscoin Bridge and the Syscoin Token Platform are permissionless and designed to facilitate maximum utility. In consideration of the flexibility they offer developers, users of independently developed bridges should exercise a degree of diligence and application developers are encouraged to include safety checks in the application layer, to verify the token is sufficiently trust-reduced.

It is particularly important to verify that the issuer/owner of an asset spec cannot "bridge ahead" - cannot alter the token supply to mint and allocate new tokens after users have started utilizing the bridge.

Follow these instructions to assess the security of a bridge-enabled Syscoin Platform Token before utilizing the bridge associated with it.

Confirm the SPT specification cannot be altered, and reflects expected attributes

In this example we examine FUNx (asset id: 490411102)

> assetinfo 490411102
{
  "asset_guid": 490411102,
  "symbol": "FUNx",
  "txid": "d1f0910d612654544c5862a5a7d43f067f1f733a43783ab944d5eeaa24d5d5b3",
  "public_value": "{\"description\":\"FunFair Interchain Token\"}",
  "address": "sys1qn5ls49y3lsglzzu2m4dmdprny0zx4s228ewq4n",
  "contract": "0x419d0d8bdd9af5e606ae2232ed285aff190e711b",
  "balance": 0.00000000,
  "total_supply": 9999999999.00000000,
  "max_supply": 9999999999.00000000,
  "update_flags": 7,
  "precision": 8
}

SPTs that are properly secured for use with bridge will generally have the following characteristics:

1. Specification is mostly or completely immutable - underlying attributes of the asset relative to supply cannot be altered.

You can quickly determine if an SPT specification has been properly rendered immutable by checking the value of update_flags in the token spec. This value is a bitmask representing which attributes can be changed. The proper values for an SPT with an active public bridge are:

0 - No part of the token spec can updated. Entire token spec is immutable.
2 - Only public_value (description, aux_fees) can be updated
4 - Only contract can be updated
6 - Only public_value (description, aux_fees) and contract can be updated

The presence of these values indicate the spec owner/issuer cannot issue more tokens with the SPT, and that they cannot re-establish the privileges necessary to alter the token spec beyond those given by the current update_flags value.

If update_flags reflects other values this may indicate the developer of this bridge is not ready to "lock down" the SPT. The token might undergo further configuration and/or its bridge still being test or demonstrated before public use.

2. Specification attributes are as advertised

Verify contract (ERC-20 contract address) is identical to the address provided by developers
Verify max_supply matches what is advertised and is as close as possible to that of the ERC-20

3. Entire supply has been burned

balance should typically equal 0, and a burn transaction should reflect the total supply value.

Check SPT provisioning for proper sequence of events

A more thorough safety check involves reviewing the early transaction history of the SPT including creation, attribute updates, burns, and more. All of this can be viewed at https://sys1.bcfn.ca by executing search with the asset guid.

Developers should enable users to verify proper provisioning by supplying them with the SPT asset_guid, and the transaction hashes associated with each step of the process.

Developers should in most cases provision the SPT using the best-practice order of events:

Create new asset (txtype: assetactivate)
Set SPT spec update_flags value to either 0, 2, 4 or 6 (txtype: assetupdate)
Mint the maximum supply (txtype: assetsend)
Burn the entire supply (txtype: assetallocationburn)

📘
It is possible to accomplish steps 1 & 2 in a single step by creating the new asset (assetnew) with update_flags attribute set to 0, 2, 4, or 6.

📘
Steps 3 & 4 can take place before step 2. This usually indicates developers did not wish to lock the asset until they finished developing other integration dependencies prior to public use.

Users are recommended to inquire with developers of the bridge if:

The order of provisioning does not match typical best-practice
Any provisioning steps remain unfulfilled
Asset allocation transactions (other than burn) transpired prior to locking the asset spec