> ## Documentation Index > Fetch the complete documentation index at: https://aven-docs.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Reputation Contract: Scoring Based on Verified Work History > The Aven Reputation Contract aggregates on-chain attestations into a portable score you can share with any potential employer or automated system. Your Aven reputation score is derived entirely from on-chain data. The Reputation Contract reads `StreamCompletion` attestations from the Attestation Contract and computes a score that reflects your total verified work history — amounts paid, number of completed engagements, and the category of work. Because every input is an immutable on-chain record, the score cannot be fabricated and does not depend on Aven's servers remaining online. ## Purpose The Reputation Contract provides a single, stable number — and a per-category breakdown — that any external party can query for any Stellar address. It is read-only and stateless: it holds no data of its own, only a pointer to the Attestation Contract. Scores update automatically as new `StreamCompletion` attestations accumulate without requiring any additional transaction. > [!NOTE] > > Only `StreamCompletion` attestations contribute to the reputation score. Individual `WorkSession` records do not directly affect the score — the score is updated once per fully-completed stream engagement. This prevents partially-completed streams from inflating or deflating scores. *** ## ScoreBreakdown When you call `get_score_breakdown`, the contract returns a `ScoreBreakdown` struct with both a total score and per-category sub-scores: | Field | Type | Description | | - | - | - | | `total` | `i128` | Aggregate reputation score, capped at **10,000** | | `freelance` | `i128` | Points from `Freelance` category streams | | `salary` | `i128` | Points from `Salary` category streams | | `bounty` | `i128` | Points from `Bounty` category streams | | `grant` | `i128` | Points from `Grant` category streams | | `agent_task` | `i128` | Points from `AgentTask` category streams | | `subscription` | `i128` | Points from `Subscription` category streams | *** ## How Scores Are Calculated For each `StreamCompletion` attestation, the contract computes a point value using the following logic: 1. **Base points:** Every completed stream starts with 10 points. 2. **Payment bonus:** `(amount_paid / 10_000_000 / 10)`, clamped between 0 and 100. This awards up to 100 bonus points for larger payments (amounts are in Stellar's 7-decimal fixed-point, so dividing by `10_000_000` converts to whole units). 3. **Category multiplier:** Applied as a percentage multiplier to the raw score. | Category | Multiplier | | - | - | | `Grant` | 130% | | `Bounty` | 120% | | `Freelance` | 110% | | `Salary`, `AgentTask`, `Subscription` | 100% | 4. **Confirmation multiplier:** `100%` if the employer explicitly confirmed the work (`client_confirmed = true`); `50%` if the payment was auto-released after the deadline. 5. **Score cap:** The total score across all attestations is capped at **10,000**. > [!NOTE] > > Score inputs are immutable attestation fields — there is no current-ledger multiplier or time decay. A completed project's contribution to your score is fixed the moment the `StreamCompletion` attestation is minted and will never drift. *** ## Public Entrypoints ### `compute_score` Returns the aggregated reputation score for a Stellar address. ```rust theme={null} compute_score(recipient: Address) → i128 ``` Reads up to 100 attestation IDs from the Attestation Contract and sums the scores from all `StreamCompletion` records. The result is capped at 10,000. **Example use cases:** * Display a score badge on a worker's profile page. * Screen candidates programmatically before assigning an `AgentTask` stream. * Verify a minimum score threshold before releasing a grant. *** ### `get_score_breakdown` Returns the full `ScoreBreakdown` struct with a total score and a score for each work category. ```rust theme={null} get_score_breakdown(recipient: Address) → ScoreBreakdown ``` Use this when you need to understand what type of work contributed to a score. For example, a grant program might only care about the `bounty` or `grant` sub-scores, while a salary-track employer might focus on `salary` and `freelance`. *** ### `verify_claim` Returns `true` if the recipient's current score meets or exceeds a minimum threshold. ```rust theme={null} verify_claim(recipient: Address, minimum_score: i128) → bool ``` Designed for automated pipelines that need a simple pass/fail check without parsing a full breakdown. Returns `false` for any negative `minimum_score`. **Example:** An automated agent task dispatcher calls `verify_claim(worker_address, 50)` before assigning high-value tasks. Workers with a score below 50 are not eligible. *** ## How the Score Is Used in Aven | Surface | How reputation appears | | - | - | | `/profile/[address]` | Full score breakdown with per-category bars and a list of contributing attestations | | `/agents` | Sortable reputation lookup for human or automated workers; employers can filter candidates by minimum score | | Automated workflows | Any system with a Stellar SDK can call `compute_score` or `verify_claim` directly without using the Aven frontend | > [!TIP] > > Share your `/profile/[your-address]` URL with potential employers to showcase your on-chain work history. The page is publicly accessible without a wallet connection and displays your full attestation timeline alongside your score. *** ## Score Limits and Constraints The Reputation Contract reads at most **100 attestations** per `compute_score` or `get_score_breakdown` call (`MAX_HISTORY_READ = 100`). If a worker has more than 100 attestations, only the first 100 (oldest) are included in the score calculation. The maximum possible total score is **10,000** regardless of the number of completed streams. *** ## Limitations and Notes > [!WARNING] > > Reputation scores are computed from Stellar testnet attestations and are **not** production credentials. The testnet can be reset, and scores will reset if the contracts are redeployed with new contract IDs. * The Reputation Contract holds no state of its own. It resolves everything by cross-contract calls to the Attestation Contract at query time. This means score reads incur the cost of multiple contract invocations, which is reflected in the transaction fee. * Disputed work sessions do not produce attestations and do not affect the score. * Auto-released sessions (employer did not respond within the timeout) do produce `WorkSession` attestations, but the `client_confirmed` flag is `false`, which halves their contribution to the final `StreamCompletion` score. * Only `StreamCompletion` attestations count toward the score. Individual `WorkSession` attestations within an incomplete stream do not contribute until the stream is fully paid out. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.