The service terms should describe one coherent system, not a loose collection of tools.
These are the canonical terms for using DeadArk across identity, invitations, content, locality, participation, and safety. Last updated June 8, 2026.
Calm, readable policy pages inside the same system.
These pages should feel authoritative without dropping out of the DeadArk design language. The goal is clarity, not spectacle: stronger rhythm, stronger hierarchy, and direct explanation.
The service
DeadArk is a social platform for people, communities, businesses, projects, publications, and institutions to connect through interests and locality. Features may change as the service develops.
Access and invitations
Anyone may use DeadArk with a free ghost identity, subject to baseline limits. Creating a fuller profile may require an invite or a tier upgrade. Invites can be issued by eligible members, communities, businesses, or institutions and grant the first profile tier. Availability is not guaranteed, and invitation or tier access may be limited or withdrawn to protect the service.
Your account
You are responsible for activity under your account and for protecting your passkey and recovery kit. Do not share recovery words. Tell us if you believe your account or device has been compromised.
Your content and identity
You retain ownership of content you submit. You give DeadArk the limited permission needed to store, process, and display it to operate the service. You are responsible for having the rights to what you publish.
Locality and safety
Locality features are optional. Do not use them to stalk, harass, expose precise locations, or endanger others. You are responsible for deciding what location information to share and for using appropriate care when meeting people.
Acceptable use
Do not harass, deceive, impersonate, exploit, spam, manipulate visibility, distribute harmful content, break the law, compromise security, or interfere with the service. The Code of Conduct is part of these terms.
Moderation and access
DeadArk may limit content, features, invitations, or participation to reduce harm, enforce these terms, or protect the service. Where practical, access to your own information remains separate from participation privileges.
Availability and liability
DeadArk is provided as available and may change, pause, or stop. We do not guarantee reach, recognition, connections, opportunities, or uninterrupted availability. Nothing here limits rights that cannot legally be limited.
Changes
These terms may be updated as DeadArk develops. Material changes will be communicated through the service. Continued use after an update means you accept the revised terms.
Trust pages should still route people into the right DeadArk context.
These pages are not isolated legal dead ends. They should explain the rule or safeguard clearly, then point people toward the correct surface for access, security, recovery, or broader system understanding.
DeadArk App
Use the app when the issue is tied to account state, access level, identity, or participation across the full system.
Route here when the user needs to act on their account or participation status rather than only read the policy
Code of Conduct
Use the conduct page for the behavioral boundary layer that sits underneath these terms.
Route here when the question is about participation standards and harmful behavior rather than service structure
Docs
Use Docs when deeper process or implementation detail is needed beyond the terms summary.
Route here when the next step is operational explanation rather than policy framing
Legal clarity should reduce confusion before it becomes support burden.
People should be able to understand what DeadArk is, how access works, what responsibilities come with identity and publication, and when the service may intervene. The more this aligns with the actual product design, the less policy feels detached from reality.
Help should stay available in context.
If someone asks a terms question from inside the app or a focused surface, answers should reference the relevant account, publishing, or participation context rather than forcing them to translate a generic policy document by themselves.
Even trust and policy flows should make sense relative to the wider app, the user's active identity, and the focused surface they came from.