Security & audits

Non-custodial design

Poly Syncer never holds user funds. The mirror engine acts on a scoped EIP-712 trading permission issued by the user’s own wallet. The permission is bounded by an explicit maxNotional cap, a maxSlippageBps ceiling, an expiry timestamp, and a per-owner nonce the user can invalidate at any time. There is no path in the contract or the operator software by which Poly Syncer can move USDC out of a user wallet to any address other than the Polymarket CTF Exchange.

Trading permissions are verified on every fill against on-chain state. Revocation propagates within one block (~2 seconds on Polygon). The contract is deployed at a fixed, well-known address and is non-upgradeable: there is no proxy, no admin key, no migration switch. If we ever need to change behaviour, we deploy a new contract at a new address and users opt in by re-signing a fresh permission.

The same model extends to Safe (multisig) accounts via a trading module. Owners install the module once with a normal Safe transaction; the module reads role state from the Safe on every fill and can be removed by the owners at any time without our involvement.

Threat model

We design against the assumption that any single component can be compromised. The categories below describe the threats we explicitly defend against and the mitigation in each case.

• Operator compromise. An attacker takes over Poly Syncer’s mirror keys. Mitigation: the contract enforces maxNotional, maxSlippageBps, and expiry bounds; the operator key cannot move funds outside the CTF Exchange; revocation is one block; HSM-bound keys cannot be exfiltrated.
• Front-running and MEV. An adversary observes a mirror order in the public mempool and trades against it. Mitigation: orders submit through Flashbots-style private bundles. Block builders see the bundle; the public mempool does not.
• Compromised user device. An attacker installs malware on a user’s machine. Mitigation: this is outside our trust boundary, but the trading permission’s caps mean even a malicious operator that the attacker enrols cannot drain the wallet. Hardware wallets remain the recommended setup.
• Polymarket protocol bug. A bug in the underlying CTF Exchange affects user funds. Mitigation: outside our control. We monitor Polymarket releases, replicate fills only after on-chain confirmation, and pause copy-trading on any anomalous protocol behaviour.
• Supply-chain compromise. A dependency in the mirror engine ships malicious code. Mitigation: pinned dependencies with lockfile verification, reproducible builds, and a 24-hour soak window in staging before any production deploy. The signing release pipeline is isolated from developer machines.
• Social engineering. An attacker impersonates a user and asks support to make a change. Mitigation: support has zero account-modifying capability. Every change requires a wallet signature. There is no “reset my account” flow because there is no account to reset.

Smart contract audit

The Poly Syncer mirror executor and trading-permission contracts were audited by Trail of Bits in Q1 2026. The full report is published verbatim, including all findings and our responses. The engagement covered the executor, the permission registry, the Safe trading module, and the surrounding deployment scripts.

The audit produced two informational findings, both relating to gas-optimisation suggestions, and no medium-or-higher severity issues. Both informational items were implemented before mainnet deployment. The deployed bytecode hash is published on the audit page and matches the hash in the report.

A second audit is scheduled for Q4 2026, ahead of the multi-chain expansion. The auditor will be announced in the changelog.

Bug bounty

We pay for security research that improves the platform. Payouts are made in USDC on Polygon. Findings must be reproducible, in-scope, and submitted privately before any public disclosure.

Out of scope: third-party services we don’t control, Polymarket protocol issues, denial-of-service via volumetric flooding, social engineering of staff, and findings already known to us or in our public audit report. Duplicate reports are paid to the first valid submitter only.

Disclosure policy

Email [email protected] with a clear write-up and a proof-of-concept where possible. We acknowledge within 24 hours and aim to triage within 72. Critical issues are patched within 7 days and we coordinate a disclosure timeline with the reporter — typically 90 days from triage, sooner if the fix is rolled out and stable.

We commit to: not pursuing legal action against good-faith researchers, not requiring NDA as a precondition to engage, and crediting the reporter publicly unless they prefer to remain anonymous. A PGP public key for encrypted submission is available on request — fingerprint 9F2C 5E8B 1A4D 7F0E 3B6C 9A2D 5F8B 1E4C 7A0D 3F6B.

Operational security

Operator signing keys are generated inside FIPS 140-2 Level 3 HSMs and never leave the hardware. Signing requests are rate-limited and bounded by per-key policies that enforce the contract’s maxNotional and maxSlippageBps values at a second layer of defence. Key rotation is automated on a 90-day cadence; the contract’s permission registry handles the handover atomically.

Internal service-to-service authentication uses ed25519 signatures. Every request between the listener, the risk engine, the sizing engine, and the submitter is signed and verified; logs are append-only and shipped to a separate, isolated audit cluster. No engineer has standing production access — privileged operations require a documented change ticket and a co-signer.

The infrastructure runs in two geographically separate regions with a hot-standby co-located node for Elite. We patch the operating system within 24 hours of CVE publication for high-severity findings, and within 7 days for medium. Full deploy logs and configuration diffs are retained for one year.

Incident history

We publish every incident that touches user-visible behaviour, including the ones that didn’t put funds at risk. Recent ten-year-tail entries appear here; the full log is in the changelog and the live service health is on /status.

For real-time service status, see /status. Subscribe to incident notifications by emailing [email protected].