Institutional Security Disclosure
OwnPay Security
Comprehensive architecture, engineering practices, AI-agent spending controls, and responsible vulnerability disclosure policy.
1. Our Security Commitment
OwnPay is designed to support payment workflows for merchants, developers, and autonomous AI agents. Security is a core requirement for protecting accounts, payment instructions, transaction integrity, and sensitive business information.
We aim to identify and reduce security risks through appropriate engineering practices, access controls, automated regression testing, monitoring, and disciplined incident response.
Transparency Note:
This page describes our security approach and technical controls. It is not an ISO certification, guarantee of absolute invulnerability, or a statement that every listed control has already been implemented across experimental alpha features. We uphold factual, auditable statements regarding our platform capabilities.
2. Security Principles
Our engineering, infrastructure, and smart contract orchestration adhere to 7 core security principles designed to defend payment flows against fraud, compromise, and unauthorized software actions.
01
Least-Privilege Access
Access to accounts, APIs, internal infrastructure, and sensitive operations is restricted strictly to authorized identities and software services that explicitly require it.
02
Credential Protection
API keys, signing secrets, private keys, and session tokens are strictly scoped. Production secrets must never be committed to source control, embedded in public frontend bundles, or logged in cleartext.
03
Payment Integrity
Payment processing strictly validates transaction amounts, asset contracts, network chain IDs, intended recipients, and cryptographic block receipts before treating an intent as settled. Idempotency prevents double-execution.
04
Webhook Security
All outbound webhooks include cryptographic HMAC-SHA256 signatures and timestamp replay defense. Consumers verify payload integrity and handle idempotent redeliveries safely without trusting unverified HTTP alerts.
05
AI-Agent Spending Controls
Agent integrations enforce deterministic spending policies: per-transaction caps, daily allowances, recipient whitelists, and kill-switch revocation to halt suspicious autonomous execution instantly.
06
Environment Separation
Sandbox, testnet (Base Sepolia 84532), and production (Base Mainnet 8453) run isolated environments with segregated credentials, distinct asset contracts, and independent routing rails.
07
Data Protection
Sensitive business information is encrypted at rest and in transit via TLS 1.3. Logs redact authentication tokens, private session material, and unnecessary personal metadata.
3. Non-Custodial Architecture
OwnPay workflows are designed around user sovereignty. Settlement executes directly on Base Layer-2 into the merchant's designated wallet or smart account. OwnPay does not pool merchant deposits or hold collective custody of customer assets.
The exact custody model depends on the wallet type, smart-account delegation, provider integration, and transaction configuration chosen by the merchant or developer:
- Direct Merchant Settlement: Buyer funds transfer via smart contracts directly to the seller's Base L2 address in native USDC.
- AI Agent Session Scopes: Agents execute within bounded session policies without holding root custody of merchant treasury funds.
- Independent Verification: Users and merchant accounting systems can verify settlement proofs independently on-chain via block explorers.
Realistic Understanding:
“Non-custodial” does not mean risk-free. Smart contracts, user devices, third-party wallet extensions, and blockchain networks carry inherent technical risks. Users remain responsible for validating recipient addresses and transaction payloads before signing.
4. Vulnerability Reporting
We welcome and value responsible security research from the developer and white-hat community. If you believe you have discovered a vulnerability in OwnPay systems, APIs, or smart contracts, we appreciate your responsible cooperation.
Submission Requirements
When reporting a security concern, please include:
-
Clear Summary: A concise explanation of the vulnerability and its potential impact.
-
Affected Component: The specific URL, endpoint, smart contract address, or API service affected.
-
Reproduction Steps: Step-by-step instructions or non-destructive proof-of-concept code.
-
Confidentiality: Do not include real user private keys, production passwords, or third-party cardholder data.
5. Responsible Testing Rules of Engagement
To qualify for good-faith review and protect our merchants and end-users, security research must strictly observe the following boundaries:
- No Data Privacy Violations: Do not view, modify, extract, or delete data belonging to other accounts or users.
- No Service Disruption: Do not perform Denial of Service (DoS/DDoS) attacks, flood transaction mempools, or degrade service performance.
- No Social Engineering: Do not engage in phishing, physical security attacks, or deception targeting OwnPay staff or merchants.
- Testnet Isolation: Always execute proof-of-concept tests on sandbox or Base Sepolia testnet (Chain ID 84532) before touching production contracts. If real funds could be affected, cease testing immediately and contact us.
Reports submitted in good faith will be reviewed promptly. Please note that safe-harbor commitments or bug bounty payouts are only available when explicitly governed by an active written program agreement.
6. Incident Response Framework
Upon detecting or being notified of a suspected security incident, OwnPay executes an incident response protocol designed to minimize risk and restore system integrity:
- Verification & Triage: Immediate assessment of severity, scope, and affected accounts or microservices.
- Containment: Rapid suspension of compromised API keys, revocation of affected agent session keys, or temporary rate-limiting.
- Remediation: Deployment of hotfixes, configuration changes, or patched smart contract integrations.
- Notification: Notification of affected merchants, integration partners, and regulatory authorities where legally required.
- Post-Mortem: Technical root-cause analysis and implementation of preventative regression checks.
Suspected Compromise? If you suspect that your OwnPay API key or connected wallet has been compromised, immediately rotate your credentials via the Merchant Dashboard and notify
security@ownpay.tech.
7. Security Limitations & Residual Risks
No digital software system, internet transmission, or decentralized blockchain ledger can be guaranteed completely immune from vulnerabilities or adverse network events.
Security outcomes depend fundamentally on implementation hygiene, wallet configuration, client-side safeguards, third-party infrastructure reliability, and evolving adversarial attack vectors. OwnPay communicates security advisories in good faith and as required by applicable law and contractual agreements.
8. Security Updates & Monitored Contact
This policy is reviewed periodically as platform features, autonomous agent standards, and blockchain infrastructure evolve. Material updates will be documented on this page with an updated timestamp.
