PeerLink transcript contributions

PeerLink pays account owners a fixed $10 USDC for a useful transcript of how their bank presents transaction history. Your local agent finds the read-only requests your bank's own site uses; an attested PeerLink enclave replays them with your session and keeps only the structure of the requests and responses. Peer engineers use accepted transcripts to build bank integrations.

Current status

Grants are open: 34 banks have an open-recipe campaign paying $10 to each of up to five contributors (up to $50 per bank), and Mercury has a first-contributor source-validation campaign ($10 USDC for one accepted organization, first positive live acquisition still pending). All campaigns share one funded budget with no automatic refill. The current release holds $120 in total, enough for twelve $10 grants, so a successful reservation, not this page, is what admits a contribution. Wise is already integrated and has no reward. Check the pinned release and the campaign index.

Contribute your bank

Give your coding agent this prompt:

Read AGENTS.md and skills/contribute-transcript/SKILL.md in
https://github.com/zkp2p/peer-link and help me contribute a read-only
transcript of my bank's transaction history. Check live capacity for my bank
first. I will sign in myself; never start a payment or change a setting.
Preview what will be kept, and show me the model my API key will pay for,
before you send anything. Keep credentials and bank data out of chat, Git and
logs.

You need an account you are authorized to inspect with at least three past transactions, a Base address for USDC, and an API key for any OpenAI-compatible model endpoint. The contribution skill is the runbook and the recipe guide explains how to find and describe a bank's read route.

1. Pick a campaign. campaigns --live lists each bank's fixed reward, its allowed domain, the budget funded for the release, and the remaining slots and budget.
2. Write a recipe. You sign in and complete MFA. Your agent records up to six read-only requests on the bank's domain (GET, or the POST the site itself issues to list history), a selector for a stable account id, a selector for the transaction list, and notes for engineers.
3. Preview. preview replays the reads from your own machine and prints exactly what would be kept, and checks your agent's field mapping the way the enclave will. Review it before going further.
4. Contribute. The client verifies the enclave's AWS Nitro attestation against the pinned release, reserves a job for ten minutes, and encrypts the recipe, your bank session and your inference key to the attested key.
5. Get paid. The enclave repeats the reads, redacts them, makes one model call on your key, verifies the result in code, and sends the fixed reward to your address when it passes. You receive a signed receipt with the Base transaction.
6. Clean up. Log out of the bank session, revoke any dedicated API token, and revoke or cap the inference key.

You do not implement a provider or open a pull request. Never publish bank sessions, API keys, raw captures or financial records in GitHub, chat, logs or support requests.

Mercury uses a different, reviewed flow: a dedicated read-only API token, account and date hints only, and one of three pinned models. See its source-validation scope.

What is kept and what a model sees

The enclave keeps a value-free transcript:

• request path templates and query parameter names, with ids replaced;
• the names of the session headers, never their values;
• response field paths with JSON types and format classes such as decimal:neg:2 or datetime:iso8601:utc;
• short tokens under status-like fields, such as completed;
• your agent's notes.

Cookies, tokens, account numbers, names, balances, amounts, memos and transaction ids are discarded inside the enclave. A field name is kept when it repeats across the records or is made of common field-name words, and anything else is replaced. These rules are heuristic, which is why preview shows you the exact transcript first.

The enclave builds one prompt: PeerLink's instructions, then the notes and transcript, then PeerLink's output contract. It sends that once to the endpoint and model you chose, with your key. Your bank session is never part of a prompt. The enclave uses it only to make the reads, so no model provider receives it. The provider you choose does see the notes and the transcript; enclave protection does not make that provider confidential.

Accepted records are signed inside the enclave and stored in Peer's private archive for engineers. Rejected jobs leave no transcript with Peer.

Inference

You pay for inference, including failed or rejected jobs. Each job makes one call. Peer pays infrastructure, payout gas and rewards, and has no inference key or fallback billing route.

Option	Endpoint
--provider openai	https://api.openai.com/v1/chat/completions
--provider openrouter	https://openrouter.ai/api/v1/chat/completions
--provider near	https://cloud-api.near.ai/v1/chat/completions
--provider openai_compatible --base-url https://host/v1	Any public HTTPS server implementing chat completions

Any model id the endpoint accepts can be used for open-recipe campaigns. This is safe because the model does not decide the outcome. It proposes which transaction field is the payment id, amount, timestamp, counterparty, currency and status, and code verifies each proposal against your live records and computes the score. Confidential NEAR inference is not available.

Rewards and acceptance

Each campaign pays a fixed $10 USDC on Base per accepted contribution. Open-recipe campaigns take up to five contributors per bank (up to $50 per bank), and Mercury one organization, with one paid contribution per bank account per campaign. New wallets or GitHub accounts do not make a new contributor.

An open-recipe contribution is accepted when the reads ran from the enclave on the bank's domain and were not available without a session, the history held at least three records, the transcript passed redaction checks, the account was not already paid, budget was reserved, and the verified field mapping scored at least 85 of 100. Payment id, amount, timestamp and counterparty are required. Rejections return a fixed reason code, and the client prints a hint for each.

Rejected, expired or cancelled contributions receive no reward. See the reward terms and privacy details.

Limits

• The account used for deduplication in open-recipe campaigns is identified by a selector the contributor's recipe declares, backed by a comparison of the history rows themselves.
• No listed bank has an accepted contribution yet. Reading a bank's web session from the enclave, as opposed to a public API with a token, has only been exercised with synthetic tests.
• The enclave refuses POST requests that are obviously named as state changes but cannot prove a request is read-only; replay only what the bank's site issues while you view history.
• Responses must be uncompressed JSON, and a bank that blocks data-centre addresses may refuse the enclave even when preview worked.
• Rewards are paid from a non-exportable AWS KMS key that Peer's operators can also use and recover. It is not an escrow, and signing authority is not exclusive to the enclave.
• One funded epoch covers every campaign, and it can be smaller than the sum of the listed slots. Refilling it requires a new measured release.

The open-recipe flow was validated end to end on internal epochs against one Wise API account: contributor agents starting only from the repository's documentation wrote a recipe, contributed and were paid, and repeat attempts for the same account were rejected. That and the earlier paid Wise test with recovery after an enclave restart are recorded in the repository's evidence notes.

Adoption into Peer

Accepted transcripts help Peer engineers develop Curator metadata and attestation transformers. A transcript does not enable a bank in Peer, prove recipient credit or final settlement, or authorize a payment. Production support requires separate bank-specific review and release approval.