> ## Documentation Index > Fetch the complete documentation index at: https://partners.docs.polymarket.us/llms.txt > Use this file to discover all available pages before exploring further. # Legal agreements > The four documents your users must accept, the six requirements on how you present them, and why you must not host your own copies. 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](/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. | | Requirement | | ------- | -------------------------------------------------------------------------------------------------------------------------- | | R-1 | Not yet published **\[VERIFY]** | | R-2 | Not yet published **\[VERIFY]** | | **R-3** | **You must not host modified, excerpted or re-rendered copies of the agreements.** Link to the canonical hosted documents. | | R-4 | Not yet published **\[VERIFY]** | | R-5 | Not yet published **\[VERIFY]** | | R-6 | Not yet published **\[VERIFY]** | **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 | Symptom | Cause | What you do | | -------------------------------------------------------- | ---------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Compliance rejects your acceptance screen | You served your own copy, summary or PDF of a document | R-3 forbids modified, excerpted or re-rendered copies. Link to the canonical hosted URL. | | You were sent a Google Drive link for the agreements | Our own ISV page currently does this, in violation of R-3 | Ask for the canonical `polymarketexchange.com` URL and use that. | | You cannot tell which `agreement.version` to send | Two incompatible formats are live in our documentation | Do not guess. Get it in writing from your integration lead; this determines what your user is recorded as having accepted. | | A document changed and your users accepted the old text | No rotation policy, no notice, no discovery endpoint | Hash-monitor the four canonical URLs and alert your compliance owner. | | You need existing approved users to accept a new version | There is no re-acceptance mechanism for approved users | Escalate to your integration lead. There is no API path for this. | | You cannot produce evidence of what a user accepted | You did not record the URL, string, version and timestamp at acceptance time | Record all four from day one. Nothing on our side can reconstruct it. | ## Next [Funding and transfers](/funding)