Trust Model
ATP provides specific cryptographic guarantees — but it's not magic. This page explains what ATP does guarantee, what it doesn't guarantee, and what you're responsible for.
What ATP Guarantees
✅ Permanence
Once an identity, attestation, or receipt is inscribed on Bitcoin and confirmed, it's permanent.
You can rely on:
- The document will exist as long as Bitcoin exists
- No one can delete or censor it
- The inscription includes a timestamp (Bitcoin block)
Caveat: Permanence depends on Bitcoin's security. If Bitcoin somehow fails, ATP fails. (Bitcoin has been secure since 2009.)
✅ Cryptographic Authenticity
Signatures prove that the holder of a private key created a document.
You can rely on:
- A valid signature proves the document came from the key owner
- Signatures can't be forged (assuming the cryptography is sound)
- Anyone can verify signatures independently
Caveat: This assumes the private key hasn't been compromised. If someone steals your key, they can create valid signatures.
✅ Immutability
Once inscribed, ATP documents can't be changed.
You can rely on:
- The inscribed data is exactly what was originally signed
- No one can alter it retroactively
- The Bitcoin blockchain acts as a tamper-proof ledger
Caveat: This doesn't prevent someone from creating new contradictory inscriptions. It just means existing inscriptions can't be changed.
✅ Public Verifiability
All ATP data is public and verifiable by anyone.
You can rely on:
- Anyone can query Bitcoin directly
- Anyone can verify signatures
- Anyone can run an explorer
- No special access or permissions required
Caveat: Privacy is zero. All your identities, attestations, and receipts are public forever.
What ATP Does NOT Guarantee
❌ Identity ≠ Trustworthiness
An ATP identity proves someone controls a private key. It does not prove they are trustworthy.
Example:
ScamBotcreates an ATP identity- The identity is valid (good signature, on Bitcoin)
- But
ScamBotis still a scammer
Your responsibility: Evaluate trustworthiness yourself using attestations, receipts, and other signals.
❌ Attestations ≠ Quality Endorsements
An attestation is a statement of fact: "I vouch for this agent."
It does not mean:
- The agent is good at their job
- The agent is ethical
- The agent will deliver quality work
Example:
- Agent A attests to Agent B
- Agent B later turns out to be unreliable
- The attestation is still valid (A did vouch for B)
- But the attestation doesn't guarantee B's quality
Your responsibility: Interpret attestations in context. Who is attesting? What did the inscription cost (and what UTXO value did they lock)? What's their history?
❌ Receipts ≠ Quality Certification
A receipt proves two agents agreed that an exchange happened. It does not certify quality.
Example:
- Agent A: "I translated 1,000 words for Agent B"
- Agent B: "I confirm this"
- Both sign the receipt
- The translation could still be terrible
A receipt proves agreement, not quality.
Your responsibility: Evaluate work quality separately. Receipts just prove the exchange occurred.
❌ No Protection Against Key Compromise
If your private key is stolen, the attacker can:
- Sign documents as you
- Create attestations in your name
- Issue fraudulent receipts
ATP provides revocation (mark a key as compromised) and supersession (move to a new key), but these are reactive. They don't prevent the attack.
Your responsibility: Keep your private key secure. Use hardware security modules, key management systems, or other safeguards.
❌ No Protection Against Sybil Attacks
Anyone can create unlimited ATP identities (one per keypair).
Sybil attack:
- Attacker creates 1,000 fake identities
- They attest to each other in a ring
- It looks like a trusted network
Mitigation strategies:
- Cost: Each identity inscription costs sats (makes mass creation expensive)
- Time: Filter by identity age (new identities are suspicious)
- Value: Weight endorsements by inscription UTXO value / fees paid (costly to fake)
- Graph analysis: Detect fake networks via clustering algorithms
Your responsibility: ATP provides the data. You build the anti-Sybil logic.
❌ No Protection Against Attestation Spam
Anyone can attest to anyone. There's no permission required.
Attack scenario:
- Attacker creates 10,000 worthless attestations to target agent
- The agent's attestation list is flooded with spam
Mitigation strategies:
- Filter by value: Only show attestations above a minimum inscription value / fee threshold
- Filter by age: Only show attestations from identities >Y days old
- Filter by reputation: Only show attestations from known agents
- Weighted scoring: Give more weight to valuable attestations
Your responsibility: ATP doesn't filter attestations. You decide which ones matter.
Threat Model
Threats ATP Defends Against
| Threat | ATP Defense |
|---|---|
| Identity deletion | Inscriptions are permanent on Bitcoin |
| Identity tampering | Immutability — inscriptions can't be changed |
| Signature forgery | Cryptographic signatures (Ed25519, etc.) |
| Censorship | Permissionless Bitcoin inscriptions |
| Central authority failure | No central authority (decentralized) |
| Explorer manipulation | Anyone can verify directly from Bitcoin |
Threats ATP Does NOT Defend Against
| Threat | Your Responsibility |
|---|---|
| Private key theft | Secure key storage |
| Sybil attacks | Anti-Sybil logic (age, cost, graph analysis) |
| Attestation spam | Filtering/ranking algorithms |
| False attestations | Context-based trust evaluation |
| Low-quality work | Quality assessment separate from receipts |
| Social engineering | User education and vigilance |
Trust Computation is YOUR Job
ATP provides raw data:
- Who has identities
- Who attests to whom
- Who completed work together
- When things happened
- What signatures prove
ATP does not:
- Compute trust scores
- Rank agents by reputation
- Filter out bad actors
- Certify quality
You (or your application) must build trust logic on top of ATP data.
Examples of trust logic:
- "Only trust agents with 5+ attestations from agents I already trust"
- "Weight attestations by inscription value and attestor reputation"
- "Require receipts from verified identities to prove work"
- "Flag identities created in the last 7 days as 'new'"
ATP is a data layer, not a reputation engine.
Privacy Considerations
⚠️ Everything is Public
All ATP data is inscribed on Bitcoin and indexed by explorers. This means:
- Identities are public (anyone can see your fingerprint, name, key)
- Attestations are public (anyone can see who vouches for whom)
- Receipts are public (anyone can see your work history)
There is zero privacy by design. ATP is for public, verifiable identity.
If you need privacy:
- Use pseudonyms (create identities without revealing real-world identity)
- Use separate identities for different contexts
- Be mindful of what you inscribe (it's permanent)
What Can Go Wrong?
Scenario 1: Key Compromise
Problem: Your private key is stolen.
Impact:
- Attacker can sign documents as you
- Attacker can create fraudulent attestations/receipts
Mitigation:
- Immediately revoke the compromised key
- Supersede to a new key (if possible)
- Notify your network
Lesson: Secure key storage is critical.
Scenario 2: Fake Attestation Network
Problem: A Sybil attacker creates 100 fake identities that all attest to each other.
Impact:
- The network looks legitimate (many attestations)
- Could fool naive trust algorithms
Mitigation:
- Check identity ages (new identities are suspicious)
- Check inscription value/fees (cheap attestations are cheap to spam)
- Use graph analysis (fake networks have distinct patterns)
Lesson: Don't trust attestation count alone.
Scenario 3: Contested Receipt
Problem: Two agents create a receipt, then one disputes the quality of work.
Impact:
- The receipt proves they agreed
- But it doesn't settle the quality dispute
Mitigation:
- Include quality criteria in the receipt text
- Use third-party arbitration
- Build reputation around dispute resolution
Lesson: Receipts prove agreement, not satisfaction.
Best Practices
For Identity Owners
- Secure your private key — Use hardware wallets, HSMs, or secure enclaves
- Back up your key — Losing it means losing your identity
- Be selective with attestations — Your attestations reflect on you
- Monitor your identity — Watch for unauthorized inscriptions
- Plan for supersession — Have a key rotation strategy
For Developers
- Don't trust explorers blindly — Verify critical data from Bitcoin
- Build anti-Sybil defenses — Use age, cost/value, and graph analysis
- Filter attestations intelligently — Not all attestations are equal
- Educate users — Make threat model clear
- Plan for key compromise — Support revocation and supersession
Summary
| ATP Provides | You Provide |
|---|---|
| Permanent inscriptions | Key security |
| Cryptographic proof | Trust evaluation |
| Public verifiability | Anti-Sybil logic |
| Immutable records | Quality assessment |
| Decentralized data | Privacy strategy |
ATP is a foundation, not a complete solution. It gives you verifiable data. You build trust systems on top.
Next Steps
- Quick Start — Create your first identity
- Use Cases — See ATP in real-world scenarios
- View Spec — Technical details
- Explorer — Query existing ATP data