Security
Trust compounds slowly and breaks instantly.
We design every security decision as if we are on the wrong side of the trust equation — because eventually, everyone is.
Security is a product decision, not a compliance exercise.
Security that exists to pass an audit is not the same as security that exists to protect people. We make the distinction intentionally. ORYN's security commitments are derived from first principles about what operators and their members are entitled to — not from what a checklist requires.
Those first principles are: no custody of value you don't need to hold; full transparency about what happened and when; clear ownership of data; and honest, fast communication when something goes wrong.
No fund custody
ORYN never holds your money or your members' money.
The marketplace and economy systems process entitlements — they record who is owed what and facilitate the transfer of value between parties. ORYN is not a wallet. It does not hold balances.
This is a deliberate architectural choice. Holding funds creates regulatory obligations, security surface area, and liability exposure that we have no reason to take on. The risk exists for no benefit. We removed it.
This means there is no scenario in which a security incident at ORYN results in financial loss for operators or their members. That's not a marketing claim — it's a design constraint we enforce at the architecture level.
Audit logging
Every authority decision is logged exactly once, in one place.
When a moderation action is taken, when a ticket is resolved, when a role is granted, when a configuration is changed — a record is created. That record includes who acted, what they did, when they did it, and what the state of the system was before and after.
These records are immutable. They cannot be edited, deleted, or suppressed by anyone, including ORYN. Operators have full access to their community's audit history. This is not a premium feature — it is a basic requirement of accountable operation.
If something goes wrong in a community, the audit log is the ground truth. Operators can investigate independently without needing to involve ORYN.
Data ownership
Your community is yours.
Community data — member records, moderation history, support tickets, marketplace listings — belongs to the operator. ORYN holds it in trust. You can export it. You can leave with it.
No lock-in.
Remove ORYN from Discord at any time. Your server's structure, channels, and roles remain exactly as they were. Nothing is stored in a way that requires ORYN to retrieve it.
No secondary use.
Member data is not used to train models, sold to third parties, or used to improve services for other operators. What happens in your community stays in your community.
Minimal collection.
We collect what we need to operate and nothing else. If a capability doesn't require a piece of data, we don't collect it. Data that ages out of usefulness is purged on schedule.
Incident response
When something goes wrong, we tell you immediately.
Our incident policy has three rules. Disclose quickly. Explain fully. Fix completely.
We do not delay disclosure while investigating scope. We do not use hedged language to minimize the appearance of impact. We do not close incidents until the root cause is understood and addressed.
Affected operators are notified directly, not through a status page update they have to check. We tell you what happened, what we know, what we don't know yet, and what we're doing about it — in plain language.
Past incidents are published and remain accessible. We don't remove them when the situation resolves. They are part of the record.
Responsible disclosure
If you find a vulnerability in ORYN, we want to know.
Security researchers who find and responsibly disclose vulnerabilities in ORYN are treated as collaborators, not adversaries. We respond to every report. We don't threaten legal action against good-faith disclosure.
If you discover a vulnerability, send a description to security@oryn.software. Include enough detail to reproduce the issue. We'll acknowledge within 24 hours and provide a resolution timeline within 72 hours.
We request 90 days to address vulnerabilities before public disclosure. If we're unable to meet that timeline, we'll tell you why and coordinate on an appropriate extension.