Veriscope
Veriscope is one of Covalent's Travel Rule providers. It carries transfers as attestations on the Shyft Network blockchain.
On this platform Veriscope receives transfers from peers and keeps its settings, but sending transfers through it is not available yet: an attempt through Veriscope fails, and the transfer goes to the next enabled provider, if there is one.
Provider Config
Section titled “Provider Config”| Field | Value |
|---|---|
| Name | veriscope |
| Display name | Veriscope |
| Protocol | veriscope |
| Active | true |
| Discovery | Attestation-based async discovery |
| Transport | Shyft Network blockchain |
Required Provider Fields
Section titled “Required Provider Fields”| Field | Description |
|---|---|
taAccount |
Trust Anchor account |
privateKey |
Ethereum private key |
network |
Veriscope network selector |
Supported network values:
| Value | Meaning |
|---|---|
veriscope_testnet |
Testnet |
fed_mainnet |
Mainnet |
Capabilities
Section titled “Capabilities”| Capability | Value |
|---|---|
| Beneficiary address | Required |
| Originator address | Optional |
| Beneficiary VASP | Not required upfront |
| Destination memo | Supported |
| Wallet proof type | veriscope_poac |
Transfer Flow
Section titled “Transfer Flow”- The transfer worker selects Veriscope from provider eligibility.
- Veriscope sync must be running before the adapter can process transfers.
- The adapter creates a blockchain attestation using the beneficiary wallet address.
- The beneficiary VASP discovers the transfer by recognizing that wallet.
- The adapter returns protocol state
NEW_ATTESTATION. - Later accept and reject actions call backend attestation methods.
Discovery Model
Section titled “Discovery Model”Veriscope does not require the caller to know the beneficiary VASP before transfer creation. The initial VASP state is pending_discovery; discovery happens through attestation recognition.
Public API Relationship
Section titled “Public API Relationship”Callers do not call Veriscope endpoints directly. They create transfers through:
POST /api/v2/transfersCovalent handles provider routing and protocol-specific transformation internally. Until sending through Veriscope is available, do not send "preferredProtocol": "veriscope".
Save Veriscope's credentials for each environment with PUT /api/v2/providers/veriscope, or in the dashboard. Peers reach your company on POST /api/system/trp/veriscope/<environment>/<providerId>/incoming, listed in the provider's callbackPaths once it has been saved. See Providers and Integrations.
Status Codes
Section titled “Status Codes”Veriscope direct mode uses a local KYC template to track the on-chain attestation, trust-anchor proof exchange, encrypted IVMS exchange, and final accept/reject state.
The public API does not expose these as standalone endpoints. They appear as provider state, protocol state, transfer messages, and transfer lifecycle updates.
Template Status
Section titled “Template Status”status is the main Veriscope KYC-template state.
| State | Meaning |
|---|---|
START |
Template created before proof exchange. |
BE_TA_PUBLIC_KEY |
Beneficiary trust-anchor public key captured. |
BE_TA_SIGNATURE |
Beneficiary trust-anchor signature captured. |
BE_USER_PUBLIC_KEY |
Beneficiary user public key captured. |
BE_USER_SIGNATURE |
Beneficiary user signature captured. |
BE_CRYPTO_PROOF_VERIFIED |
Beneficiary wallet proof verified. |
BE_CRYPTO_PROOF_NOT_INSTALLED |
Beneficiary proof contract or proof path not installed. |
BE_CRYPTO_PROOF_NOT_PROVIDED |
Beneficiary proof was not provided. |
BE_TA_URLS |
Beneficiary trust-anchor URLs captured. |
BE_TA_VERIFIED |
Beneficiary trust anchor verified. |
OR_TA_PUBLIC_KEY |
Originator trust-anchor public key captured. |
OR_TA_SIGNATURE |
Originator trust-anchor signature captured. |
OR_USER_PUBLIC_KEY |
Originator user public key captured. |
OR_USER_SIGNATURE |
Originator user signature captured. |
OR_TA_URLS |
Originator trust-anchor URLs captured. |
OR_TA_VERIFIED |
Originator trust anchor verified. |
BE_KYC_UPDATE |
Beneficiary KYC/IVMS update is ready to send. |
OR_KYC_UPDATE |
Originator KYC/IVMS update is ready to send. |
BE_KYC_ACCEPTED |
Beneficiary-side KYC accepted. |
BE_KYC_REJECTED |
Beneficiary-side KYC rejected. |
OR_KYC_ACCEPTED |
Originator-side KYC accepted. |
OR_KYC_REJECTED |
Originator-side KYC rejected. |
Rejected states are terminal for the local template.
High-Level Status Flow
Section titled “High-Level Status Flow”START -> beneficiary proof states -> BE_TA_VERIFIED -> originator proof states -> OR_TA_VERIFIED -> BE_KYC_UPDATE or OR_KYC_UPDATE -> accepted or rejectedAfter OR_TA_VERIFIED, either side can update KYC/IVMS data. The exchange can move between beneficiary and originator KYC update states until one side accepts or rejects.
Webhook Status
Section titled “Webhook Status”webhookStatus tracks peer communication attempts.
| State | Meaning |
|---|---|
START |
No peer communication recorded. |
BE_DATA_SENT |
Beneficiary data webhook sent. |
BE_DATA_FAILED |
Beneficiary data webhook failed and may retry. |
BE_DATA_RECEIVED |
Beneficiary data acknowledged. |
BE_KYC_REQ_SENT |
Beneficiary KYC request sent. |
BE_KYC_REQ_FAILED |
Beneficiary KYC request failed and may retry. |
BE_KYC_REQ_RECEIVED |
Beneficiary KYC request acknowledged. |
BE_KYC_SENT |
Beneficiary KYC payload sent. |
BE_KYC_FAILED |
Beneficiary KYC payload failed and may retry. |
BE_KYC_RECEIVED |
Beneficiary KYC payload acknowledged. |
OR_DATA_REQ_SENT |
Originator data request sent. |
OR_DATA_REQ_FAILED |
Originator data request failed and may retry. |
OR_DATA_REQ_RECEIVED |
Originator data request acknowledged. |
OR_DATA_SENT |
Originator data sent. |
OR_DATA_FAILED |
Originator data failed and may retry. |
OR_DATA_RECEIVED |
Originator data acknowledged. |
OR_KYC_REQ_SENT |
Originator KYC request sent. |
OR_KYC_REQ_FAILED |
Originator KYC request failed and may retry. |
OR_KYC_REQ_RECEIVED |
Originator KYC request acknowledged. |
OR_KYC_SENT |
Originator KYC payload sent. |
OR_KYC_FAILED |
Originator KYC payload failed and may retry. |
OR_KYC_RECEIVED |
Originator KYC payload acknowledged. |
Failed states transition back to their corresponding sent states during retry.
IVMS Status
Section titled “IVMS Status”ivmsStatus tracks encrypted IVMS payload exchange.
| State | Meaning |
|---|---|
START |
No encrypted IVMS payload has been exchanged. |
BE_ENC_SENT |
Beneficiary encrypted IVMS sent. |
BE_ENC_FAILED |
Beneficiary encrypted IVMS failed and may retry. |
BE_ENC_RECEIVED |
Beneficiary encrypted IVMS acknowledged. |
OR_ENC_SENT |
Originator encrypted IVMS sent. |
OR_ENC_FAILED |
Originator encrypted IVMS failed and may retry. |
OR_ENC_RECEIVED |
Originator encrypted IVMS acknowledged. |
IVMS State Codes
Section titled “IVMS State Codes”| Code | Meaning |
|---|---|
0202 |
Accepted. |
0308 |
Rejected. |
When a template reaches a rejected state, the local engine locks it so later transitions cannot overwrite the rejection.
Transition Hooks
Section titled “Transition Hooks”Entering specific template states triggers protocol work:
| Entering State | Hook Actions |
|---|---|
BE_TA_VERIFIED |
Send beneficiary data and request originator data. |
OR_TA_VERIFIED |
Request beneficiary KYC and send originator data. |
BE_KYC_UPDATE |
Send beneficiary KYC and beneficiary encrypted IVMS. |
OR_KYC_UPDATE |
Send originator KYC and originator encrypted IVMS. |
BE_KYC_ACCEPTED, OR_KYC_ACCEPTED |
Dispatch accepted status code 0202. |
BE_KYC_REJECTED, OR_KYC_REJECTED |
Dispatch rejected status code 0308. |