Levels of access
There are three ways to use SPCR, and you can start at the first without talking to anybody.
1. Read-only, no account
Anyone can open a demo workspace, originator1.spcr.io or funder1.spcr.io, and look through it. Real screens, real data, real records on the test network.
You can see pools, registered receivables, holdings, history, transaction links, and the register and transfer screens themselves. What you cannot do is act: registering receivables, selling a pool and revealing a pool passkey all need an account. The workspace says so on arrival and the final button on each of those flows asks you to sign in rather than failing after you have done the work.
Public verification at spcr.io needs no account either, and never will.
2. Signed in
Create an account with any email address and the demo workspaces become fully usable: register receivables, create pools, sell a pool to a funder, reveal a passkey. Everything runs on the test network, so you can exercise the real flows without real consequences.
Your own workspace, when you have one, is restricted to the email addresses or domains it was set up for. A workspace onboarded for one named person admits that person only. See Questions we get asked.
Why a passkey needs an account even to read. A pool passkey is half of every certificate's verification secret in that pool. Anyone holding it can look up every receivable in the pool. So it is not something an anonymous visitor can be handed, even though reading it changes nothing.
3. API, no interface
Under development: if you need to sell a pool or run a query, you should not be blocked on our interface being up. Documentation will appear here when it is ready, covering authentication, registration, transfer and querying holdings.
If this is the tier you care about, tell us what you would call first. That is how we are prioritising it.
Confirming an address
Available at Confirm my address inside a workspace.
The registry shows which address holds a receivable but never whose address it is. So when a funder buys from another funder, the buyer is left asking whether the address holding the pool is really the party across the table.
The holder answers it by using the key. They sign a challenge with that address, either in their own wallet or by approving a request in their custody app, and send the buyer a link. The page the buyer opens shows the address, who confirmed it, when, and re-checks the chain to say whether that address still holds the pool.
Three things it does not prove, and the page states all three:
- Control is not ownership. It shows who controls an address, not what that address still holds. Holdings move; that is why the page re-checks.
- The link is bearer evidence. Whoever holds it can forward it. It shows the address was controlled at a moment in time, not that the sender is that party.
- It is not an identity check. A signature proves control of a key, not who owns the company. The link between a name and an address is STOKR's onboarding record.