Security Policy

OnRampDLT is built on a non-custodial, serverless architecture designed to minimize the attack surface and eliminate the most critical security risk in crypto platforms: the risk of fund loss from platform compromise.

The most significant security property of OnRampDLT is that it is non-custodial by design. The platform:

• Never stores, processes, or transmits private keys, seed phrases, or wallet credentials
• Never holds user funds, tokens, or securities on behalf of users
• Cannot initiate, authorize, or reverse any blockchain transaction without explicit user signature
• Cannot access, freeze, or recover user wallets under any circumstances

OnRampDLT's platform and API are deployed on Cloudflare's global infrastructure, which provides:

• DDoS protection and traffic filtering at the network edge
• Web Application Firewall (WAF) blocking common attack patterns
• Global CDN for performance and availability
• Bot management and rate limiting

The OnRampDLT API runs on Cloudflare Workers, a serverless compute platform. This architecture eliminates persistent server processes, reduces the window of opportunity for server-side attacks, and provides automatic isolation between request handling contexts. No customer data is held in memory between requests.

All token and bond operations are executed on the XRP Ledger, a public, decentralized blockchain with a ten-year track record of security and availability. The XRP Ledger's consensus mechanism does not rely on mining, reducing exposure to 51% attacks. All transactions are publicly verifiable on the XRPL Explorer at xrpl.org/explorer.

OnRampDLT connects to the XRP Ledger via public WebSocket nodes (wss://xrplcluster.com, wss://s1.ripple.com) and has no operational control over the network, validator behavior, or transaction ordering.

All communications between users and the OnRampDLT platform are encrypted using TLS 1.3. Plain HTTP connections are automatically redirected to HTTPS. Cloudflare enforces HTTPS-only access at the network edge. Connection security is enforced for all API endpoints, the dashboard, and the marketing site.

User data stored by OnRampDLT is encrypted at rest using AES-256 encryption. This includes account data, API key hashes, offering documents, attestation records, and compliance records. Database encryption is managed at the infrastructure level through Cloudflare's platform controls.

OnRampDLT does not store, and has no technical mechanism to store, the following:

• Private keys or seed phrases of any kind
• Wallet signing credentials
• Payment card data (handled entirely by Stripe, a PCI DSS Level 1 certified processor)
• Unencrypted API keys (keys are one-way hashed at creation; the original value is shown once and cannot be recovered)

All payment processing is handled by Stripe. OnRampDLT does not receive, process, or store payment card numbers, bank account numbers, or other financial account credentials. Stripe's security practices, including PCI DSS Level 1 certification, govern the handling of payment data. See Stripe's Security Documentation for details.

All platform API access is authenticated via API key. API keys are:

• Generated cryptographically at account creation
• Displayed to the user exactly once at the time of issuance
• Stored only as a one-way cryptographic hash — OnRampDLT cannot recover a lost key
• Tied to a specific subscription tier that enforces rate limits and feature access
• Immediately revocable by contacting support

By design, no OnRampDLT employee, contractor, or system can access user funds, tokens, or private keys. This is a structural property of the non-custodial architecture, not a policy control. There is no administrative override, master key, or recovery mechanism that provides OnRampDLT employees with access to user assets.

Access to OnRampDLT's internal systems is restricted on a principle of least privilege. Production environment access is limited to authorized personnel and is logged. Code deployments follow a review process before reaching production.

Investor access to bond and equity token offerings is restricted to users who have received a direct invitation from the issuer. No public catalog of offerings exists. This access control is intentional and required under Rule 506(b) of Regulation D. For 506(c) offerings, investors must complete identity verification via Stripe Identity before accessing any offering details.

OnRampDLT maintains an incident response process for security events affecting the platform or user data.

• Critical: Confirmed unauthorized access to user data, offering documents, attestation records, or platform secrets. Requires immediate response.
• High: Suspected unauthorized access, service outage affecting securities issuance, or vulnerability with active exploitation potential.
• Medium: Potential vulnerability identified but not exploited, or degraded platform performance affecting availability.
• Low: Security configuration issues, non-sensitive data exposure, or informational findings from security review.

1. Incident detected and classified by severity
2. Affected systems isolated or mitigated where possible
3. Root cause investigation initiated
4. Affected users notified where required
5. Remediation implemented and verified
6. Post-incident review completed and documented

In the event of a confirmed security incident involving unauthorized access to user data, OnRampDLT will notify affected users within 72 hours of confirming the breach, to the extent notification is legally required and technically feasible. Notification will be sent to the email address on file for the affected account.

To report a security incident or suspected breach, contact: security@onrampdlt.com

OnRampDLT collects the minimum data necessary to provide the service. This includes:

• Email address (for account, API key delivery, and service communications)
• API key hash (for authentication — original key is never stored)
• XRPL wallet addresses associated with your account
• Offering documents uploaded for securities issuance (PPMs and related materials)
• Attestation records (token declaration, accredited investor certification)
• Compliance records (issuance events, fee calculations, investor access logs)
• Standard server logs (IP address, request metadata) retained for up to 30 days

See the Privacy Policy for a complete description of data collection, use, and retention practices.

Offering documents, attestation records, and compliance records are subject to extended retention periods under applicable securities law. These records are retained for a minimum of seven (7) years and cannot be deleted by user request. See the Privacy Policy for full details.

The most important data security property of OnRampDLT is that a breach of the platform's data cannot result in loss of user funds or tokens. The platform holds no private keys, no wallet credentials, and no signing authority over any user wallet. A complete compromise of OnRampDLT's systems would expose account metadata, email addresses, and offering documents — not user funds.

All token issuance, bond subscription, and payment transactions executed through OnRampDLT are settled on the XRP Ledger, a public blockchain. On-chain data — including wallet addresses, transaction amounts, token balances, and trust line relationships — is publicly visible by design and cannot be altered, reversed, or deleted by OnRampDLT or any other party. This is a fundamental property of the XRP Ledger, not a platform policy.

Users may request access to, correction of, or deletion of their account data by contacting support@onrampdlt.com. Deletion requests will be processed within seven (7) business days. Compliance records and attestation records subject to regulatory retention requirements cannot be deleted regardless of user request.

Maximal Extractable Value (MEV) refers to profits that can be extracted from blockchain users by manipulating the ordering, inclusion, or exclusion of transactions within a block. Common MEV strategies on proof-of-work and proof-of-stake networks include front-running, sandwich attacks, and arbitrage exploiting pending transactions in a public mempool.

The XRP Ledger uses a consensus mechanism that differs materially from Ethereum and similar networks in ways that significantly limit MEV risk:

• No public mempool: Transactions submitted to the XRP Ledger are not held in a publicly observable pending queue accessible to validators. This eliminates the primary information source used for front-running and sandwich attacks on Ethereum.
• Consensus-based ordering: Transaction ordering within a ledger is determined by the consensus protocol among a set of trusted validators, not by miners or stakers who can freely reorder transactions for profit.
• Ledger close every 3–5 seconds: The short ledger close time reduces the window during which transaction ordering manipulation could occur.
• No block builder market: There is no equivalent to Ethereum's MEV-Boost or block builder ecosystem on the XRP Ledger.

OnRampDLT further reduces MEV exposure through its transaction design:

• All investor subscriptions use direct payments only — no automated routing through AMM pools or decentralized exchange order books
• Securities subscriptions are fixed-price by definition (primary issuance) — there is no price to manipulate between submission and execution
• OnRampDLT does not route user transactions through any liquidity aggregator, DEX, or routing protocol subject to sandwich attacks

While MEV risk is significantly lower on the XRP Ledger compared to proof-of-work and proof-of-stake networks, residual risks exist:

• Validator behavior is not controlled by OnRampDLT and could theoretically be used to benefit affiliated parties through transaction ordering, though no such behavior has been documented on the XRP Ledger
• Future additions of AMM or DEX functionality to OnRampDLT would introduce MEV risks that currently do not apply; this disclosure will be updated if such features are added
• On-chain transaction data is publicly visible immediately upon ledger close, which could allow third parties to observe and react to transaction patterns

OnRampDLT welcomes responsible disclosure of security vulnerabilities. If you have discovered a security issue affecting the OnRampDLT platform, API, or marketing site, please report it to our security team before public disclosure.

Report security vulnerabilities by email to: security@onrampdlt.com

Please include in your report:

• A clear description of the vulnerability and potential impact
• Steps to reproduce the issue (proof of concept is helpful)
• The affected URL, endpoint, or component
• Your contact information for follow-up

• Acknowledgment: We will acknowledge receipt of your report within 3 business days
• Initial assessment: We will assess severity and provide a preliminary response within 10 business days
• Resolution: We will work to remediate confirmed vulnerabilities as quickly as possible, with timelines depending on severity and complexity
• Disclosure coordination: We ask that you allow us a reasonable remediation window before public disclosure; we will coordinate a disclosure timeline with you upon confirming a valid finding

In scope for responsible disclosure:

• onrampdlt.com and onrampdlt.io web applications
• OnRampDLT API endpoints
• Authentication and access control vulnerabilities
• Data exposure or unauthorized data access vulnerabilities
• Injection vulnerabilities (SQL, command, XSLT, etc.)
• Cross-site scripting (XSS) and cross-site request forgery (CSRF)

Out of scope:

• Vulnerabilities in third-party services (Stripe, Cloudflare, XRP Ledger) — report these to the respective vendors
• Social engineering attacks against OnRampDLT employees
• Physical security
• Denial of service attacks
• Findings from automated scanners without manual verification of actual impact

For good-faith disclosures that comply with these guidelines, OnRampDLT commits to:

• Acknowledge and investigate your report promptly
• Not pursue legal action against researchers acting in good faith
• Treat your report confidentially until a coordinated disclosure date is agreed
• Credit your contribution in any public security advisory, if you wish to be acknowledged