Skip to main content
Every end user must be presented with four legal documents and must accept them before you submit their verification.
Before this page you need:
  • your POST /v1/kyc/start integration — see /kyc#start-a-verification,
  • a place in your own database to record what each user accepted, when, and from which URL,
  • your compliance reviewer in the loop. This page is a compliance surface, not a UI detail.

​
The four documents

Four end-user documents apply, issued by QCX LLC and QC Clearing LLC, and hosted by us on polymarketexchange.com.
Not yet published. The exact document titles, the canonical hosted URL of each one, and which of the two entities issues which document are not published in a form we can reproduce here. Get all four canonical URLs from your integration lead in writing, and link to those URLs — not to a copy, and not to a path you constructed from the domain.
Link out to our hosted copies from your acceptance screen. Do not summarise them, and do not put the text inline in your own app.

​
R-1 to R-6

Six requirements govern how you present and record acceptance.
Not yet published. Five of the six requirements are not published in full. Ask your integration lead for R-1 to R-6 verbatim before your acceptance screen goes to compliance review. Do not infer them from R-3.

​
R-3 in practice: do not serve your own copies

Serve no copy of these documents from your own infrastructure. That includes a PDF in your app bundle, a mirrored file on your CDN, a shared-drive link, a modal containing pasted text, and a “summary of key terms” screen. All of those are modified, excerpted or re-rendered copies. Two specific failure modes:
  • A cached copy drifts. When a document is updated on polymarketexchange.com, your copy keeps showing the superseded text and every acceptance you record after that moment is an acceptance of the wrong document.
  • Re-rendering changes the document. Pulling the text into your own typography, collapsing sections, or dropping a schedule produces a different document even when nothing was intentionally edited.
Our own current ISV page violates R-3 by serving the participant agreements out of Google Drive. Do not copy that pattern from us. If your integration lead sends you a shared-drive link, ask for the canonical hosted URL instead, and record that URL against each acceptance.

​
The acceptance language

The acceptance text your user sees is prescribed and must be presented verbatim.
Not yet published. The verbatim acceptance language is not published here, and paraphrasing it is not an option — this is the sentence that makes the acceptance enforceable. Get the exact string from your integration lead, put it in your codebase as a single constant with a comment naming its source, and have compliance sign off on the screenshot before launch.
Record, per user and per acceptance: the document set presented, the canonical URL of each document, the acceptance string shown, the agreement.version you sent, the UTC timestamp, and your external_id. You will be asked to produce this, and there is no API that can reconstruct it for you.

​
agreement.version is not settled

The agreement.version format is not settled, and no value is published here. Two shapes are in circulation: an effective-date string, and a semantic-version-style token. One of those tokens is sandbox-specific, so you may face environment drift on top of format drift.Do not hardcode either format, and do not guess which one your environment expects. This is a compliance-relevant gap: the value you send is the record of which document version your user accepted. Get the canonical format and the current value from your integration lead in writing, store it as one constant, and keep the written answer.

​
Gaps you must plan around

None of these have a workaround. Design for their absence.
  • No discovery endpoint for agreement.version. You cannot query the current version, so you cannot detect a change programmatically. Your value is a constant you maintain by hand, from a written answer.
  • No rotation policy. There is no published notice period, no changelog commitment and no schedule for when these documents change. You will not be told in advance by the platform.
  • No grace period. There is no published window in which an acceptance of the previous version remains valid.
  • No re-acceptance mechanism for existing approved users. There is no endpoint to re-collect acceptance from a user who is already approved. When a document changes, you have no supported way to get their agreement to the new one through this API.
The practical consequence: poll the canonical URLs yourself. Fetch each of the four documents on a schedule, hash the body, and alert your compliance owner when a hash changes. That is not a platform feature, it is you compensating for the absence of one — but it is the difference between learning about a new version from your own monitor and learning about it from a regulator.

​
What can go wrong

​
Next

Funding and transfers