Kill / Loss Information

[Scetrov]

🧐 Motivation

As a tribe, we see significant value in Kill / Loss data as a way to understand the impact and evolution of conflict in The Frontier.

This data can be used to:

• Create killboards that measurably improve tribe morale and enjoyment by sharing both successes and failures.
• Generate signals intelligence for specific regions of the universe—either to route around contested areas or to concentrate stronger forces where conflict is detected.
• Deliver rewards via tribe leaderboards (e.g. loyalty points redeemable for ships or equipment).

---

📝 Details

At present, on-chain data and the World API expose only minimal information (Killer, Victim, Location, Timestamp). This creates several issues:

1. The data is trivial to game (e.g. repeatedly killing Wends or portable storage to inflate rankings).
2. There is no reliable way to verify the authenticity of a claimed kill, which erodes trust in downstream tooling and analysis.

By contrast, the client has access to much richer data, including:

• Basic: Victim, Killer, Location, Timestamp
• Fit: Victim ship, involved parties’ ships and weapons
• Drops: Items dropped and destroyed

This information is valuable but ephemeral. While there is no strong requirement for this data to be stored on-chain indefinitely, there is a clear requirement to verify that:

1. The killmail originates from an authoritative source (CCP).
2. The contents have not been tampered with.

Both requirements could be satisfied by issuing a cryptographic proof—e.g. a zero-knowledge proof or a signed Provable Object Datatype (POD).

---

✨ Proposal

• The client should expose this proof via Right Click → Copy from a Killmail interface or notification.

  • The clipboard would contain either:

    • A signed proof, or
    • A URN resolvable via the API.

• A historical record of killmail proofs should be available via the API:

  • /v3/killmails (list)
  • /v3/killmails/{id} (single killmail)

• Listing endpoints should support pagination and filtering to avoid refetching previously seen data, including:

  • Rider
  • Tribe
  • Solar System
  • Created Since (timestamp for differential fetches)

• These endpoints should not be subject to security trimming; all players should be able to view and independently verify all killmails in the Frontier.

• Killmails may expire after a fixed retention period (e.g. 90 days) to reduce long-term storage and operational burden on the API.

• Killmails Proofs contain:

  • Must Have:
    • Timestamp
    • Final Blow
    • Involved Parties
    • Solar System
    • Victim
    • Ship Lost
    • Ships involved
    • Items dropped / Items destroyed (including Quantity)
  • Should Have:
    • UIDs for Singleton Ships, Players and Items (Singleton and Transient)
    • Region (could be used with PODs to disclose only the region a ship was lost in)

• Should have reference implementations for General-Purpose Circuits which could be used to prove for example that a ship was lost, but not specifically by whom and where - although this information could be data mined.

---

📌 Outcome

By providing verifiable, authoritative killmail data, players gain a clear and trusted mechanism for consuming Kill / Loss information. This enables more robust analysis, tooling, and decision-making across the Frontier ecosystem.

[blurpesec]

It would be good to have an approximate $EVE value of assets destroyed if possible (this would be something to include in the proof/verification).

This would allow for creating things like "asset destruction" bounties.