Integrate PCOC into your service
Bots spread their cost across thousands of sign-ups, and today's gates make real people pay too. With an admission gate, each new sign-up brings a PCOC its maker made, with a cost of its own.
The admission gate measures the PCOC. Your policy decides.
groundinglab's hosted gate is one policy, not the policy.
You can use the hosted gate, run the gate yourself, or embed the SDK verifier. The SPEC is there when you want to go further.
Producer and verify
Someone produces a PCOC. A service measures it and applies its policy to admit. The same four SDKs, at 2.3, cover both sides. Quickstarts and the tags that are cut today are on the SDK page.
Producer
- The maker's device creates the key and holds the memory. A client is where that happens.
- Linux and Android apps are the reference clients.
- To put the SDK in your own app, start with Make a PCOC or Integrate a producer.
Verify
- The verifier checks one randomly placed leg in each stage, so every stage gets checked, and returns a measurement. It does not admit anyone.
- Run a gate, which pairs that measurement with your policy. The steps are on the admission gate page.
- Or embed the verifier and apply the policy in your own code. That path is Verifier and policy.
One list. Each language is the producer and the verifier.
| Language | SDK | Readme |
|---|---|---|
| Rust | pcoc | Rust SDK readme |
| C | pcoc | C SDK readme |
| Go | pcoc | Go SDK readme |
| Java | pcoc | Java SDK readme |
Three paths
| Path | What you hand over | What stays yours |
|---|---|---|
| Hosted gate | groundinglab runs the verifier and one published policy. Sign-in on this site is that gate. | Whether you send your sign-ups there, and every rule of your own service around it. The hosted policy is one policy, not the policy. |
| Run the gate yourself | You operate the gate: build, config, and the machine it listens on. The run instructions are the detail page. | The deployment and the policy file. You set the count of legs and whether one identifier may open one account. |
| Embed the SDK verifier | The SDK measures the PCOC inside your own service and returns a record. You write the step that reads that record. | Where the check sits in your sign-up flow, and the whole admission decision. See a measurement. |
Your policy sets how many legs to check and whether one identifier may open one account. See groundinglab's admission policy for one worked example.
What happens at the door
The five steps are Make, Anchor, Keep, Check, Decide. Make, Anchor and Keep happen on the maker's device. At this door the service checks and decides.
- 1
PCOC presented
- 2
Verifier checks one random leg in each stage
- 3
Your policy decides
- 4
Account admitted or not
A PCOC that has been made has not been admitted. Admission happens only here.
Why a service would want this
Each new sign-up brings its own cost, with no phone number or big-platform account, and the admission policy stays yours. It does not make fake accounts impossible.
Going further
- The SPEC, the normative source for producers and verifiers.
- Point a coding agent at the specification, when you would rather hand the wiring to an agent. The specification stays the contract.
- Technical reference: SDKs, Bari (the batch anchoring service you can run), the gate, and the sign-in wire.
- How it works, if you want the making before the integration.
- Learn: trust and safety.