Continuity and recovery

Receivables registered on SPCR are recorded on a public blockchain, not within SPCR. SPCR is an interface for reading and writing that record. If SPCR ceased to operate, every certificate would continue to exist, remain held by the same address, and remain readable by anyone.

The blockchain does not record which certificate corresponds to which loan. A certificate's identifier is a hash and cannot be reversed to a Loan ID; it is computed from the Loan ID and the passkey. Continuity therefore requires you to retain that data.

Data locations

See Data and privacy for a complete description of what is stored and where.

The contract

The details below are read from the live deployment.

The batch functions follow ERC-1155 naming and signatures (mintBatch, safeBatchTransferFrom, with amounts and uris parameters), although the contract is ERC-721. This matches the call format of the custody provider's token template, so the custody service can use this contract without code changes. Each entry in amounts must be 1 and uris must be empty; any other value reverts.

Reading the contract

The contract implements standard ERC-721 and can be read with any block explorer, Ethereum library or public RPC endpoint.

Two events record the full history:

• CertificateRegistered(uint256 indexed tokenId, address indexed holder) on registration.
• The standard ERC-721 Transfer(address indexed from, address indexed to, uint256 indexed tokenId) on every transfer, including the mint.

tokenId is indexed in both events, so the complete history of a receivable can be retrieved with a single filtered log query.

Writing to the contract

The contract defines two roles, neither of which can transfer your certificates:

• MINTER_ROLE registers new certificates. It is held by STOKR's custody vault and operator.
• DEFAULT_ADMIN_ROLE grants and revokes MINTER_ROLE only. The deploying key renounced this role after setup, which can be verified on chain.

Locating receivables without SPCR

1. Retrieve your Loan IDs and the pool passkey from your own records.
2. Compute each identifier. Convert the Loan ID to uppercase, remove surrounding whitespace, append | followed by the passkey, and apply SHA-256. The result is the tokenId as a 32-byte hexadecimal value.
3. Convert to decimal if your tool requires a uint256. Block explorers display the Token ID in decimal, which is why SPCR shows both formats.
4. Call ownerOf with the result against the contract above.

From any shell:

# One receivable's identifier, in hex.
printf '%s|%s' 'YOURCO-2026-P1-L0001' 'your-pool-passkey' | shasum -a 256

The output is the tokenId. The command does not contact SPCR.

Recovering certificates

The ability to transfer your certificates depends on who holds the key to the holding address. The procedure differs for each of the arrangements below.

STOKR custody

Under this arrangement, STOKR provisions your vault within its own custody workspace.

Release process

You can prove what you own at any time without STOKR's involvement: compute your identifiers, call ownerOf, and read the transfer history. STOKR's involvement is required only to sign the transfer.

A release is initiated by a written request from a signatory nominated in advance, and proceeds as follows:

1. Requester verification. STOKR verifies the requester through the contact channel on file, not the channel the request arrived on. Two staff members record the verification independently.
2. Destination verification. The destination is normally the confirmed and whitelisted backup address. A different destination requires a new signature proving control. STOKR does not release to an address supplied only in the request. The destination is read back to you in full.
3. Manifest. STOKR prepares a manifest of every tokenId in your vault, cross-checked against the chain, with the pool each belongs to. The manifest is the basis for approval and is provided to you.
4. Approval. Compliance and a director approve the release, in addition to operations, because a release is irreversible and removes the certificates from STOKR's control.
5. Execution. STOKR executes the release in batches, confirming settlement and re-reading ownerOf after each batch before sending the next, so any partial failure is identified immediately.
6. Evidence pack. You receive every tokenId with its transaction hash, and ownerOf output confirming that your address holds each certificate.

The target completion time is 10 business days from a verified request.

If STOKR ceases to operate

Separate arrangements apply if STOKR is no longer operating:

• The release obligation is set out in your agreement, survives termination and binds a liquidator, so an insolvency practitioner is instructed to act rather than given discretion.
• The material required to recover the custody workspace independently of STOKR is held by a third-party escrow agent. Release conditions include STOKR's insolvency or cessation of business, and failure to respond to a valid release request. Request the name of the escrow agent from STOKR so that the arrangement can be verified independently.

Required preparation

The following cannot be arranged during an incident and should be completed in advance:

1. Set and confirm a backup address. A backup address is requested when you select STOKR custody. Confirm it by signature from Confirm my address in your workspace, then select Set as my backup address on the result. STOKR does not release to an unconfirmed address. Once confirmed, STOKR whitelists it in custody.
2. Confirm your signatories. Nominate two individuals, each with a contact channel, and review them annually. This prevents a forged release request from succeeding.
3. Retain the data package. Pools, passkeys, Loan IDs and identifiers. Without it, certificates cannot be mapped to loans, and it is the only data SPCR holds that cannot be reconstructed from the chain.

Moving to self-custody

If you move to your own custody, the release process no longer applies. Your certificates are held at an address you control, and the procedures below apply.

Your own Fireblocks workspace

You control the vault and the certificates. No part of this procedure depends on SPCR.

1. Confirm the address. Your vault address is the to address on the registration transactions and the current result of ownerOf.
2. Connect to the contract. Use your workspace's contract interaction or dApp connection with the contract address above, on the correct chain. The contract is not currently verified on the public explorer, so supply the ABI. The function signatures on this page are sufficient.
3. Transfer the certificates. Use safeTransferFrom(from, to, tokenId) for a single certificate, or safeBatchTransferFrom(from, to, ids[], amounts[], data) for a pool, with each entry in amounts set to 1.
4. Approve under your policy. The transaction is subject to your workspace's transaction policy.

Other self-custody

Any address you control can be used in the same way, including a self-custodied key, a multisig such as Safe, or a custodian that can sign an arbitrary contract call.

1. Compute your identifiers as above and confirm that ownerOf returns your address.
2. Call transferFrom or safeTransferFrom using your custody tooling. Any tooling that can sign an Ethereum contract call is sufficient.
3. For smart-contract wallets, safeTransferFrom calls the recipient's onERC721Received hook. A transfer to a contract that does not implement it reverts, which prevents certificates being sent to an address from which they cannot be moved. Use transferFrom only where this consequence is understood.