Atlas Protocol
Security
Atlas treats security as a full chain: protect the real key, let apps borrow only limited power, make data prove who it belongs to, and build on cryptography meant to last.
Security that's calm and solid
Most internet security still feels like juggling sharp objects. You keep typing secrets into apps, services keep inventing their own login flows, and every server has to bolt on its own filters, rate-limits, and DDoS protection after the fact.
Atlas starts from a simpler idea: the most valuable key should stay protected, apps should only receive temporary delegated permission, and network traffic should carry proof before it gets to behave like a trusted participant.
That way, security is not just something hidden in one app or one company. It becomes part of how the whole network works.
Today's internet keeps adding defenses too late
The web usually starts with open requests and scattered accounts, then tries to patch security in later. That leads to familiar problems:
- Your strongest secret leaks into too many places. Apps often ask for more access than they really need.
- Raw internet traffic says very little by default. Every service has to invent its own anti-spam and anti-DDoS rules.
- Cheap identities make bot swarms cheap too. Without stronger proofs or human context, abuse scales easily.
- Cryptography is chosen for today only. If a protocol should still matter in 10 or 20 years, it has to think ahead now.
Atlas responds by building security into identity, transport, reputation, and cryptography together.
Atlas security is layered from the inside out: key custody, delegated permissions, identity-bound transport proofs, network-wide attack signaling, identity verification, and quantum-resistant cryptography.
Your real key stays in one safe place
Custodian + Delegated KeysIn Atlas, your main private key can live inside specialized secure hardware or with a dedicated provider called a custodian. The custodian's role is intentionally narrow: keep an encrypted copy of the key and help authorize use of it. By design, it should never need to handle that key in plaintext.
When a client app needs access, it sends the encrypted key material together with the passphrase or other approval input needed for that session. The custodian's job is to recognize you, apply the rules you chose, and let you decide how much permission the app gets and for how long.
After approval, the app receives a delegated key. That means it can operate under your decentralized global identity without ever owning your root secret.
Every request carries identity and proof
Signatures + Soft RandomXAtlas does not treat communication like anonymous raw HTTP. Every request is followed by a public key, a signature proving the holder authorized it, and proofs tied to that identity.
At the transport layer, Atlas uses a soft RandomX proof-of-work approach with time windows. In plain language: identities must keep showing fresh compute commitment. It is not giant mining. It is background friction that makes abuse more expensive and easier to classify.
The stronger the proof, the more kindly registries and the network can treat the traffic. Weaker or noisier traffic can be slowed, deprioritized, or asked for FairShares payment sooner.
Attack defense becomes a network behavior
Registry SignalingBecause requests already arrive with identity and proof context, Atlas does not need to lean on the usual pile of custom DDoS tools and one-off rate-limit rules everywhere. Much of that abuse resistance moves down into the protocol itself.
If one registry starts mitigating an attack, the rest of the network can recognize that quickly through signaling. The same attacker identities can be given negative trust, so their traffic becomes easier for others to treat cautiously before the damage spreads.
One defender's work becomes shared intelligence. The network can rapidly shift between lenient and strict behavior by adjusting how it treats unfamiliar identities. This flexibility makes it harder to wear the system down by targeting a single point.
Abusive identities and weak proofs get recognized in real time.
Other registries can adjust treatment without starting from zero.
Negative trust, weaker routing, and earlier payment expectations.
Verified humans stand out from automated swarms
Identity + Bot ReportingAtlas also repeats an important idea from the other pages: compute alone is not the whole answer. Real humans can earn identity proofs, while suspicious identities can be reported and escalated for further checks.
That gives registries and clients more than just traffic volume to judge. They can ask whether this identity is a verified human, whether others have flagged it as abusive, and whether it keeps behaving like a bot farm instead of a person.
Bots may still exist, but they do not blend in as easily. They face proof costs, weaker trust, and the possibility of public negative trust or renewed identity verification.
The cryptography is chosen for the long run
Falcon + X-WingAtlas assumes the important question is not if older non-quantum-resistant algorithms will be broken, but when. A protocol that wants to be a serious foundation for more than the next 10 years has to plan for that horizon from day one.
That is why Atlas uses Falcon public keys and X-Wing encryption. The goal is simple: start with a stronger long-term base instead of migrating the entire network later under pressure.
Identity and signatures are built for a longer threat horizon.
Private communication should not assume today's attackers forever.
Security that starts at the key and ends at the network
The most valuable secret lives behind secure hardware or a custodian.
Delegated keys limit what each app can do and how long it can do it.
Requests carry keys, signatures, and fresh proof tied to identity.
Registry signals, negative trust, and human checks make attacks easier to isolate.
Falcon and X-Wing aim for a protocol that can age more gracefully.
