Fifteen years of work, and every new client starts from zero

A freelancer's entire professional history is scattered across platforms that will not export it, portfolios that prove possession rather than authorship, and engagements covered by non-disclosure agreements. The client on the other side has the mirror image of the same problem, and pays for it. The fix is not a better profile page. It is a receipt the worker holds.

Picture a contract engineer, fifteen years into a good career. She has shipped a payments integration for a mid-size retailer, rebuilt an onboarding flow that cut a bank's drop-off by a third, and spent eight months inside a logistics company untangling a scheduling system that three previous contractors had abandoned. She is, by any reasonable measure, excellent and well evidenced.

Now she is bidding on a new contract, and here is what she can actually put in front of the buyer.

She can offer a marketplace profile with a rating, if the buyer happens to use that marketplace, and if she has not moved between platforms, which she has. She can offer a portfolio site containing screenshots and descriptions she wrote herself. She can offer the names of two former managers who have since changed jobs and may or may not reply to an email from a stranger. And she can offer a LinkedIn profile, on a network where the trustworthiness of a profile has become an open question rather than an assumption.

Everything in that list is either self-asserted, locked to a platform, or dependent on the goodwill of a busy third party. Fifteen years of verifiable, high-consequence, well-received work, and none of it is verifiable by the person deciding whether to hire her.

Why can a freelancer not prove their own work history?

The reason is not that nobody thought about it. It is that every piece of evidence a freelancer accumulates is generated and retained by someone whose interests do not include making it portable. There are four distinct failures here and they need separating, because they have different fixes.

The platform holds the record, and the record is not a document

When a client leaves a five star review with a paragraph of praise, that review is a row in the marketplace's database. It is displayed under the freelancer's profile, on the marketplace's terms, for as long as the marketplace chooses. It is not signed. It is not addressed to anyone. It carries no cryptographic relationship to the client who supposedly wrote it or the freelancer it describes.

This matters more than it sounds. If the freelancer screenshots the review and shows it to a new client, the new client is looking at an image. Images of praise are trivially manufactured. There is no operation the recipient can perform on that screenshot that distinguishes a real review from one made in a graphics editor in four minutes. The information was real; the artifact carrying it is worthless outside the walls it was created in.

Marketplaces generally restrict off-platform contact and off-platform contracting, which is commercially reasonable given that they invested in the introduction. The effect on the freelancer, though, is that the record of the relationship and the ability to continue the relationship both belong to the intermediary. We wrote about the structural version of this in Your five star rating is not yours, which covers why ratings specifically cannot travel. This post is about the working life underneath the rating.

A portfolio proves possession of a file, not authorship of the work

The traditional answer to "prove you can do this" is a portfolio. Show the work. That worked for a long time, imperfectly, on an unstated assumption: producing convincing evidence of expert work required expert work.

That assumption is gone. A generated portfolio piece costs minutes. Case study copy describing a project that never happened reads exactly like case study copy describing a project that did, because the genre is formulaic and the model has read all of it. A design portfolio, a code sample, a writing clip, a strategy deck: each of these is now producible without the underlying competence, and the recipient has no reliable way to tell. We covered the design-specific version in The end of the fake portfolio.

The deeper point is one that predates generative tools and that the tools have simply made unavoidable. A portfolio has never proved authorship. It proves that the person showing it has the file. Possession and authorship look identical in an email attachment. For most of the history of freelancing this did not matter much, because acquiring someone else's portfolio piece was awkward and pointless. Now it is neither.

The NDA problem, which almost nobody writes about

Here is the constraint that makes freelancer verification genuinely hard rather than merely neglected, and it is routinely skipped in discussions of this topic.

Much of the best freelance work cannot be shown. Not "is inconvenient to show". Cannot be shown, as a matter of contract. The engineer who spent eight months inside a logistics company fixing their scheduling system signed a non-disclosure agreement covering the existence of the project, the client's internal systems, and in many cases the client's identity. The consultant who advised on an acquisition cannot mention the acquisition. The contractor who rebuilt a bank's onboarding cannot show the bank's onboarding.

This produces a perverse inversion: the more senior and consequential the work, the less of it can appear in a portfolio. Junior work on public-facing marketing sites is showable. Senior work on internal systems, regulated processes and unannounced products is not. So the evidence a freelancer can display is systematically biased toward their least impressive engagements, and the buyer evaluating that evidence is systematically misled downward about experienced practitioners.

Any proposal that solves freelancer verification by "just show the work" has not engaged with this. The information that needs to travel is not the deliverable. It is a fact about the engagement, stripped of everything confidential.

References are social, not verifiable, and they decay

References remain the most trusted signal in professional hiring, and they are held together with string. A reference is an unverified assertion by an unverified person about an unverified relationship, delivered over email or a phone call, both of which are channels a motivated fraudster can supply. The buyer usually cannot confirm that the referee is who they say they are, held the role they claim, or worked with the candidate at all.

They also decay fast. Managers change jobs, companies restructure, email addresses stop working, and after five years the person who could vouch for a piece of work is unreachable. The evidence has a half-life measured in employment tenure, which is now short.

What does the client on the other side actually see?

It is tempting to write this as a story about an exploited worker and an indifferent market. That would be a worse post, because the buyer's problem is real and rarely stated sympathetically.

Put yourself on the hiring side. You need a senior engineer for a four month engagement with production access to a system that handles customer money. You have a shortlist of six people you have never met, who live in four countries, and you have about ninety minutes of total evaluation time per candidate before the cost of hiring exceeds the cost of the risk.

Here is what you can practically do. You can interview them, which tests interviewing. You can look at a portfolio, which you now know proves possession. You can ask for references, which you cannot verify and which nobody offers as a negative. You can run a background check, which is disproportionate in cost and turnaround for a four month contract, tells you about criminal history and identity rather than competence, and in many jurisdictions cannot be run at all for a short engagement. You can check a marketplace rating, if you are hiring on that marketplace, which constrains your candidate pool to that marketplace.

None of these answers the actual question, which is: has this specific human done this specific kind of work before, for someone who was satisfied enough not to dispute it?

So buyers do the rational thing under uncertainty. They pay a premium for the signal they can verify cheapest, which is a recognisable name: a known agency, a known former employer, a known school. That premium is paid for legibility, not capability. It is not stupidity, it is a reasonable response to a market with no verification mechanism.

Why is this a market failure and not just an annoyance?

Because the cost is not distributed evenly, and it is not a cost that competition erodes. It compounds.

Every freelancer pays an entry toll with every new client. The toll is priced in discounted first engagements, unpaid trial work, extended interview processes, and time spent producing bespoke evidence that will not be reusable with the next buyer. Because the toll is paid per relationship rather than once, it does not amortise. A freelancer with forty past clients pays it for the forty first exactly as they paid it for the second.

Two consequences follow, and they push in the same direction.

The first is that newcomers are structurally disadvantaged beyond their actual lack of experience. A capable practitioner with two years of excellent work has no way to compress the buyer's uncertainty, so they compete on price, which is the only lever they control. This suppresses rates at the entry end of the market well below what capability alone would justify.

The second is that incumbency compounds. A practitioner attached to a recognisable name carries a portable signal, because the name travels even though the work does not. That advantage has very little to do with whether they are better and quite a lot to do with whether the buyer has heard of their last employer. Buyers overpay for the brand and underpay for the unbranded equivalent, and neither party is behaving irrationally.

Marketplaces sit in the middle of this and capture part of the spread. They charge a service fee on billings in exchange for a bundle of matching, payment handling, dispute resolution and, crucially, trust intermediation. Published fee schedules have changed repeatedly over the years and vary by platform and arrangement, so any specific percentage quoted here would be stale before it was read. What is durable is the structure: a meaningful share of the fee is payment for a trust signal that the platform will not let the freelancer take with them. That is the actual lock-in, and it is far stronger than the matching algorithm, which is replicable.

Estimates of the total size of the freelance and independent workforce circulate widely and disagree enormously, mostly because they define the population differently. Some counts include anyone who earned any independent income in a year, including delivery work and occasional side income; others count only full-time independent professionals. Those are different populations by an order of magnitude, so treat any single headline number with suspicion, including the ones in vendor reports. The argument here does not need a market size. It needs only the observation that the toll is paid per relationship and never amortises, which is true at any scale.

What would a work receipt actually contain?

The mechanism is deliberately small. The temptation with problems like this is to design a comprehensive professional identity system, and comprehensive systems do not get adopted. What gets adopted is something a busy client can complete in fifteen seconds at a moment when they are already thinking about the engagement, which is when they approve the final invoice.

An engagement receipt is a signed statement by the client that a specific human did a specific kind of work over a specific period, and whether it ended in dispute. It contains no deliverables, no confidential detail, and no rating.

{
  "type": "engagement.receipt.v1",
  "issuer": "did:web:clientco.example",
  "subject_key": "z6MkfR7NtqA9pZ2v...",       // freelancer's enrolled public key
  "engagement": {
    "role": "Senior backend engineer",
    "started": "2026-02-03",
    "ended": "2026-05-29",
    "engagement_type": "fixed-term contract",
    "hours_band": "300-500",
    "deliverable_digest": "sha256:9f2a41c8...",  // optional
    "disputed": false
  },
  "issued_at": "2026-05-30T16:04:11Z",
  "nonce": "7f14c0be9a"
}

Walk the fields, because each one is doing a job and two of them are doing a job that is not obvious.

subject_key is the freelancer's enrolled public key, not their name and not an email address. This is what makes the receipt bind to a person rather than to a string. A receipt naming "R. Sharma" can be presented by any R. Sharma; a receipt naming a public key can only be usefully presented by whoever controls the corresponding private key, which lives on the freelancer's own device.

hours_band is a band rather than a number on purpose. Clients are often contractually restricted from disclosing engagement value or precise scope, and a band carries the useful information (this was a substantial engagement, not a two day job) without disclosing commercial terms. Design choices like this are the difference between a scheme clients will sign and one legal will block.

deliverable_digest is optional and it is the field that addresses authorship rather than merely participation. If the client hashes the delivered artifact at handover and includes the digest, the freelancer can later demonstrate that a specific file was the one delivered under this engagement. That does not prove they typed every line, which we will come back to in the limits, but it does bind a particular artifact to a particular engagement to a particular person, which is more than a portfolio has ever done. The signed commit demonstration shows the same idea applied to individual commits.

disputed is a boolean rather than a rating, and that is a deliberate and slightly uncomfortable choice which we will defend in the limits section.

Verification, from the perspective of the next client, involves contacting nobody:

receipts = wallet.present(type="engagement.receipt.v1", since="2021-01-01")

for r in receipts:
    issuer_key = fetch_published_key(r.issuer)     # from the client's own domain
    assert ed25519_verify(issuer_key, canonical(r.payload), r.signature)
    assert r.subject_key == candidate.enrolled_key  # the bidder holds this key
    assert not r.engagement.disputed

# no call to a marketplace, no call to the previous client,
# no call to us. Signature checks are arithmetic.

The property that matters is in the comment. Verification is arithmetic performed against a published key, so it works when the marketplace has changed its terms, when the previous client has been acquired, when the referee has changed jobs, and in ten years when several of the parties no longer exist. We covered why this property is worth so much in Can you verify a credential without phoning the issuer?.

How do you prove a track record without naming your clients?

This is the question that decides whether the design is usable, because a freelancer who must disclose their client list to bid is worse off than one who shows screenshots.

The shipped capability is straightforward selective presentation: the freelancer holds a wallet of receipts and chooses which ones to show to which buyer. That already solves a large part of the problem, because most confidentiality concerns are about specific clients rather than about the existence of a career. A freelancer can show three receipts from clients who permit disclosure and say nothing about the other twenty.

The more interesting capability is aggregate disclosure: proving "I hold eleven receipts for senior backend engagements totalling more than four thousand hours, none disputed, the most recent within the last six months" without revealing a single issuer. That is a predicate over a set of credentials rather than a disclosure of them.

We should be precise about status here, because this is exactly the kind of claim that gets oversold. Selective disclosure using SD-JWT, and zero knowledge predicates over credential sets, are roadmap at Manav, not shipped. What is shipped is the wallet of Ed25519 receipts, issued to the worker's key, held by the worker, exported selectively, and verified offline. The aggregate-without-issuers version is a design we think is correct and have not built. Treat any vendor claiming otherwise, including us, with the scepticism you would apply to any unreleased feature.

Why do schemes like this usually fail?

Because of the cold start, and it is worth being blunt about it rather than hand-waving, since the graveyard of portable reputation projects is well populated.

On day one, no freelancer has any receipts. A wallet containing nothing is worse than a portfolio containing screenshots. The value of the scheme to any individual participant is roughly proportional to how many other people are already in it, which is the classic condition under which good ideas die.

Worse, the party who must act first is the client, and the client captures none of the benefit. A client signing a receipt at the end of an engagement is doing a small favour for a person who is, at that moment, leaving. There is no natural incentive there. Appeals to fairness do not scale.

So the honest answer about adoption is that this does not start with individual clients being persuaded. It starts wherever an intermediary already sits in the closing workflow and has a reason to want the freelancer to come back: staffing agencies, whose value proposition is a vetted bench and who would rather their contractors' history be portable to their next placement than locked in a marketplace they do not own; vendor management systems, which pay real money to re-verify the same contractors repeatedly and would prefer not to; and challenger marketplaces, for whom issuing portable receipts is a competitive weapon against incumbents whose moat is captivity.

That last point is the strategic heart of it. An incumbent marketplace will not issue portable receipts, because captive reputation is the actual product. A challenger absolutely will, because "your history is yours and you can take it with you" is the only pitch that reliably moves professionals off an established platform. The interests of the freelancer and the challenger align exactly, which is the condition under which these schemes have historically managed to start.

Regulation is a slower but real tailwind. The European Union's Platform Work Directive, which entered into force in 2024 with a transposition deadline for member states at the end of 2026, addresses employment status and algorithmic management in platform work, and the Data Act addresses access and portability of data more broadly. Neither, so far as we can determine, mandates portable reputation specifically, and we are not going to claim they do. The direction of travel is toward workers having rights over data generated about them, which makes the argument easier to have than it was five years ago.

What this cannot do

Five limits, and the first three are the ones that matter.

An attestation of completion is not an attestation of quality. A receipt says the engagement happened, lasted this long, and was not disputed. It does not say the work was good. Plenty of mediocre engagements end without dispute because ending a dispute is expensive and clients often prefer to pay and move on. Anyone reading a wallet of undisputed receipts should read them as evidence of professional reliability, which is genuinely useful and much scarcer than it sounds, and not as evidence of excellence.

If it becomes a rating, it inherits every problem of ratings. This is why disputed is a boolean. The moment you add a five point scale, you import rating inflation, retaliation dynamics, the reluctance of clients to give an honest low score to someone they may need again, and the well documented demographic biases in subjective evaluation. A boolean is coarse, and coarse is the point. There will be pressure to enrich it. That pressure should be resisted, and if it is not resisted, this scheme becomes another rating system with cryptography bolted on, which is worse than useless because it looks authoritative.

Collusion is straightforward and must be assumed. Two people can incorporate two entities and issue each other glowing receipts all afternoon. A receipt is only as meaningful as the issuer, which means the verifier's real question is not "is this signature valid" but "do I recognise this issuer", and that is a governance question rather than a cryptographic one. The realistic mitigations are ordinary rather than clever: issuers with an independent public existence carry more weight, receipts from an agency or vendor management system that has its own reputation at stake carry more weight, and a wallet consisting entirely of receipts from entities nobody has heard of should be read exactly as suspiciously as a portfolio full of unnamed clients.

The deliverable digest does not prove human authorship. It binds an artifact to an engagement and a person. If the freelancer generated the artifact with a model, the digest is identical. Proving that a human produced particular work is a genuinely harder problem, partially addressable at the moment of creation rather than the moment of delivery, and it is the subject of Proof of Human Work rather than this post. Do not let anyone tell you a hash solves it.

The freelancer must not lose the key. A wallet of receipts bound to a key is worth exactly nothing if the key is gone and there is no continuity path to re-establish the binding. This is the recovery problem, it is the weakest point in every scheme of this shape, and it is treated properly in Why does losing your phone mean uploading your passport?.

What to do this week

Practical steps, depending on which side of the engagement you sit.

If you are an independent professional:

1. Write down, today, the engagements from the last five years you can currently prove to a stranger. For most people the honest count is close to zero. That number is your actual portable evidence base.
2. Ask your next two clients for a short written confirmation of role and dates at invoice close, before the relationship goes cold. Even unsigned, it is better collected now than reconstructed in three years, and it establishes the habit of asking.
3. Check your marketplace contracts for what you are permitted to export and reference off-platform. Most freelancers have never read this and are more restricted than they assume.
4. Stop treating your portfolio as your primary evidence. Treat it as a demonstration of taste and capability, which it still does well, and build a separate record of verifiable engagement facts.

If you hire independent professionals:

5. Add a receipt to your engagement close checklist. It costs a signature at the moment you are already approving the final invoice, and it makes you the kind of client good contractors return to.
6. Work out what you actually pay per contractor to verify history today, including recruiter fees, interview time and re-onboarding through your vendor management system. That number is usually larger than anyone expects and is the business case.
7. When someone shows you evidence, ask the discriminating question: can I verify this without asking you or the party who supposedly issued it? If the answer is no, you are looking at a claim, not evidence.
8. Read the receipt schema in the developer documentation before designing anything bespoke, because a format that only you accept is a format nobody's history travels through.

Frequently asked questions

How can a freelancer prove work history outside the platform where the work happened? With an engagement receipt: a short attestation the client signs at the close of the engagement, bound to the freelancer's own enrolled key, recording role, dates and whether the work was disputed. The freelancer stores it in a wallet they control and presents it to whoever they choose. Any recipient verifies the signature against the issuing client's published key, without contacting the platform or the previous client.

Do Upwork or Fiverr reviews transfer to another platform? No. Marketplace reviews are records in that marketplace's system, displayed under its terms. They are not signed documents addressed to the freelancer, so there is nothing to transfer, and a screenshot of a review is an image rather than evidence. This is the central mechanic of platform lock-in for independent workers, and it is deliberate rather than an oversight.

Can a portfolio prove that a human did the work? No, and it never could. A portfolio proves the person showing it possesses the files. Possession and authorship are indistinguishable in an email attachment. Generative tools removed the practical barrier that used to make faking a portfolio not worth the effort, which turned a long-standing theoretical weakness into a live problem.

What exactly is an engagement receipt? A small signed object containing the issuing client's identifier, the freelancer's public key, the role, the start and end dates, an hours band, an optional digest of the delivered artifact, and a boolean saying whether the engagement was disputed. It deliberately contains no confidential detail, no deliverables and no rating, which is what makes it possible for a client's legal team to approve issuing one.

Why would a client bother to sign one? Individually, most will not, which is the honest answer. Adoption realistically starts with parties already in the closing workflow who benefit: staffing agencies who want their bench to be portable, vendor management systems that pay to re-verify the same people repeatedly, and challenger marketplaces for whom portable history is a competitive weapon against incumbents whose advantage is captive reputation.

Does presenting receipts reveal my client list to a competitor? Only if you choose to present them. The shipped capability is selective presentation: you show the receipts you are permitted to show and stay silent about the rest. Proving an aggregate track record without revealing any issuer requires selective disclosure and predicate proofs, which are roadmap at Manav rather than available today.

How do enterprises verify contractor history today? Mostly by re-doing it. Vendor management systems and procurement teams run their own onboarding, identity checks and reference gathering per contractor per client, and none of that work is reusable by the next buyer. It is expensive, slow, and answers a different question from the one that matters, which is whether this specific human has done this specific work before.

Sources

1. Directive (EU) 2024/2831 on improving working conditions in platform work, EUR-Lex. Covers employment status and algorithmic management; member state transposition deadline in December 2026.
2. Regulation (EU) 2023/2854 (Data Act), EUR-Lex. Data access and portability obligations.
3. W3C Verifiable Credentials Data Model, W3C Recommendation track. The standards work an engagement receipt should interoperate with.
4. Selective Disclosure for JWTs (SD-JWT), IETF Datatracker. The mechanism behind aggregate disclosure, referenced here as roadmap.
5. Open Badges specification, 1EdTech. Prior art for portable, issuer-signed achievement records.
6. MBO Partners, State of Independence in America. One of several independent workforce sizing studies whose definitions differ substantially from others.

Your portfolio proves you have the file. Your rating proves the platform liked you. Only a receipt proves a client stood behind the work, and only if you are the one holding it.