Request access

$PORT · Proof-network security

USDC pays for the work. PoPW proves it. $PORT backs the proof.

$PORT is the economic security asset of the Proof of Physical Work network. Verifiers lock it up as collateral behind the proofs they anchor, and can lose it only for provable protocol misconduct. Nobody needs $PORT to post a task, do one or get paid.

Run a verifierWhat a proof proves
How $PORT backs a batch of proofsFour accepted claims are combined into one Merkle root. Part of the verifier's bonded $PORT in the PortSecurityVault is locked to that batch, and the root is anchored on Base. A challenge window runs. When it closes without a valid challenge, the batch is final and the locked $PORT is released back to the verifier.ACCEPTED CLAIMSROOTPORTSECURITYVAULTBONDED $PORTLOCKED TO BATCHBASE · ANCHOREDCHALLENGE WINDOWFINALLOCKED UNTIL FINAL. THEN RELEASED.SLASHED ONLY FOR PROVABLE MISCONDUCT.
Batch lifecycle · PORT Proof Security v0.2 (draft)
§ 01

Almost nobody needs it. That's the point.

Dollars and USDC carry the value of the work. $PORT sits behind the proof, held only by the operators who vouch for it.

Who needs $PORT, by role
RoleNeeds $PORT?What they use
RequestersPeople, organizations, AI agents and machinesNoCard, invoice, x402 + USDC, or a mandate budget
PerformersPeople, robots and fleets that do the workNoDollars to a bank account, or USDC
Proof consumersAuditors, insurers, buyers and downstream agentsNoPublic PoPW inclusion proofs
VerifiersApproved operators that anchor proofsYesA $PORT bond in the PortSecurityVault
ChallengersAuthorized parties that dispute a batchYesA small $PORT bond during the challenge window
§ 02

Collateral, not currency.

You don't spend $PORT. A verifier locks it up so it's allowed to do a job, and loses it if it cheats.

$PORT is

  • Collateral that verifiers and challengers put at risk to vouch for Proof of Physical Work.
  • Locked against each batch in the PortSecurityVault on Base, and released when the challenge window closes.
  • Sized to the dollar value a batch of proofs backs, and to how much assurance it claims.
  • Slashable only for provable protocol misconduct.

$PORT is not

  • A way to pay for tasks. Work is priced and paid in USD or USDC.
  • Needed to post a task, do one, get paid or check a proof.
  • A source of yield. There is none for holding it, and no new emissions to fund any.
  • The proof itself. $PORT can't say which task happened or which policy accepted it. PoPW does.
  • An investment offer. This page makes no claims about its price.
§ 03

What a verifier puts its name, and its bond, behind.

A verifier doesn't decide whether a room is clean. The verification pipeline does that under a versioned policy. The verifier attests that the proof was built and labeled correctly, with its own $PORT at risk.

  1. 01

    Receive accepted work

    A task resolves to ACCEPT under a versioned verification policy. It may be marketplace, direct or verify-only work.

  2. 02

    Build the claim

    Task, requester type, mandate, performer, origin-tagged evidence, policy, rights, decision and settlement are hashed into one PoPW claim.

  3. 03

    Assign an honest tier

    The tier can't exceed what the evidence allows. Proofs built on uploaded files top out at Standard.

  4. 04

    Batch the claims

    Claims that qualify for the same tier go into one Merkle tree. One 32-byte root stands for the batch.

  5. 05

    Lock $PORT

    A separate Teleport key signs a security authorization, and exactly that much of the verifier's bonded $PORT is locked to the batch.

  6. 06

    Sign and anchor

    The verifier's own attestation key signs the batch, and the root is anchored in the PhysicalWorkRegistry on Base.

  7. 07

    Wait out the window

    Anyone authorized can challenge an objective fault. If no challenge succeeds, the batch is final and the bond unlocks.

§ 04

The more a proof backs, the more is bonded.

The bond scales with the dollar value the proofs stand behind, not with how many proofs there are. Double the value of a batch and the required bond doubles.

B = (R × m / 10000) / P

R Reference value
The dollar value the batch's proofs back.
m Assurance multiplier
In basis points. Standard is 10,000 (1.0×); higher tiers use more.
P PORT/USD reference
Set off-chain by Teleport, so issuing proofs never waits on a live price feed.
B Required bond
The $PORT locked against this batch until it is final.

For verify-only work, R is the service fee or the money that depends on the proof, such as a contractor payment released on verification, whichever is larger. A cheap proof can't back a big decision without matching security.

  1. Standard

    One primary verifier, minimum coverage and a short challenge window.

  2. Verified

    Extra review, more $PORT behind it and a longer window. A co-verifier is optional.

  3. High assurance

    Several verifiers, including an independent reviewer, plus human adjudication and the largest coverage. Planned; not live at launch.

A tier is also capped by the weakest evidence behind it. See the caps.

§ 05 · Slashing

Lying about a proof costs a bond. Being honestly wrong doesn't.

A slash needs something anyone can check from hashes, signatures or committed records. The test is whether the verifier misrepresented the proof, not whether it got a physical judgment wrong.

Can cost a bond

  • Signing two conflicting claims for the same task
  • Signing a root that doesn't match its claims
  • Signing with an inactive or unauthorized key, or for a mode it isn't approved for
  • Citing a policy hash that doesn't match the recorded run
  • Signature forgery or replay
  • Claiming stronger evidence than was recorded
  • Anchoring above the tier the evidence allows

Never costs a bond

  • A vision model made an honest error
  • A model's probability later proves wrong
  • A reviewer or customer disagrees
  • “The room did not look clean.”
  • A mandate turned out to be too permissive
  • Third-party evidence was faked, and was labeled as submitted evidence
  • A good-faith call under the declared policy

Honest mistakes still have consequences, just not in $PORT. They affect a verifier's reputation, review rates, eligibility and bond minimums.

§ 06

Challengers check the verifiers.

During a batch's challenge window, an authorized challenger can post a small $PORT bond and point to one specific, checkable fault. A valid challenge gets its bond back. A spam challenge can lose part of it.

The nine challenge types

  • INVALID_MERKLE_INCLUSION
  • DUPLICATE_CONFLICTING_BATCH
  • INVALID_VERIFIER_SIGNATURE
  • UNAUTHORIZED_VERIFIER
  • INVALID_POLICY_REFERENCE
  • CLAIM_HASH_MISMATCH
  • ORIGIN_FLOOR_MISREPRESENTED
  • MANDATE_HASH_INVALID
  • ASSURANCE_EXCEEDS_ORIGIN_CAP

Not valid challenges: “The model should have scored this 0.91,” “I disagree with the AI,” or “That robot shouldn't have been allowed to post this.” Those go to Teleport review and mandate governance, not to slashing.

§ 07

Run a verifier.

Inspection firms, insurers' loss-control teams, facilities auditors and fleet operators already verify physical work. As a Teleport verifier, those judgments become portable and provable, with your stake behind them. The network is permissioned and bonded: Teleport is the only verifier at launch, and approved co-verifiers join through a pilot.

Teleport ships the software. The verifier brings the key, the bond and, where required, the judgment.

Two ways to sign

  1. ATTESTING

    Profile A · Attesting

    Re-checks that each claim and batch was built correctly from Teleport's recorded verification run: hashes, Merkle root, evidence floor, tier cap, mandate and policy.

    Typical use: a second signer on Standard and Verified batches.

    No evidence access needed
  2. INDEPENDENT

    Profile B · Independent

    Everything in Profile A, plus its own ACCEPT decision under the declared policy, reached through scoped, logged access to the evidence.

    Typical use: multi-verifier quorum, high assurance and verify-only work for regulated buyers.

    Own reviewers or pipeline

High-assurance batches need at least one independent signature besides Teleport's. Proof pages say which kind each signer is. An attesting verifier is never described as having reviewed the work.

How verifiers are paid

In USDC, for verification work: $0.20 per PoPW claim in the current draft, with verify-only jobs priced per task because they include reviewing outside evidence. The bond isn't a return. It sets how much value a verifier can anchor at once, and at which tiers.

Three keys, all yours

The three keys a verifier holds
KeySignsCustody
Attestation keyBatch anchors and claim attestationsHSM or managed KMS, never exported
Submitter keyBase transactions that relay signed anchors (gas only)Hot wallet with a low balance
Bond custody keyDepositing and withdrawing $PORT in the vaultCold wallet or multisig

Teleport never holds an external verifier's keys and doesn't offer hosted signing. Coverage is authorized by a separate Teleport key, so no verifier can authorize its own.

From application to active

  1. 01

    Apply

    Get allowlisted in the VerifierRegistry. There is no open sign-up.

  2. 02

    Deploy

    Run the reference client and your signing backend on infrastructure you control.

  3. 03

    Conform

    Reproduce the published encoding test vectors and pass the conformance suite.

  4. 04

    Rehearse

    Register a test key, bond test $PORT and anchor test batches on Base Sepolia.

  5. 05

    Bond

    Bond $PORT and register your attestation key on Base. You start as PENDING.

  6. 06

    Shadow

    Verify live batches in parallel without signing, while agreement is measured.

  7. 07

    Go active

    Usually marketplace work first. Direct, verify-only and Profile B come with a track record.

Verifier profiles, keys and onboarding are from the PORT Verifier Infrastructure v0.3 draft and may change.

§ 08

Canonical on Ethereum. Put to work on Base.

The existing Ethereum ERC-20 remains canonical $PORT. Proof operations run on Base. Teleport will not create an independently mintable Base token, and any bridge design follows an audit of the existing contract.

  1. Ethereum mainnet

    Canonical $PORT (the existing ERC-20)

  2. Approved bridge

    After an audit of the existing contract

  3. Base

    • PhysicalWorkRegistry anchors proof batches
    • PortSecurityVault holds bonded $PORT
    • VerifierRegistry lists approved verifiers and keys
    • ChallengeManager runs challenge windows
§ 09

Straight answers.

Is $PORT a utility token?No.

Nobody spends it to use Teleport. The operators who verify and challenge proofs bond it as collateral.

Do I need $PORT to use Teleport?No.

Requesters pay in dollars or USDC. Performers are paid in dollars or USDC. Anyone can check a proof without it.

Is there yield for holding or bonding $PORT?No.

There is no yield for holding and no new token emissions. Bonding is a requirement for doing verification and challenge work. Verifiers are paid in USDC for that work.

Why does $PORT exist if work is paid in USDC?Payment and security are different jobs.

USDC carries the value of the work. $PORT puts money at risk behind the proof that the work was verified, so a verifier that signs something provably false pays for it.

Who runs the proof network today?Teleport.

At launch the network is permissioned and bonded, with Teleport as the primary verifier. Approved co-verifiers are planned to join through a pilot. That is a design goal, not a promise.

What about price, listings or returns?We don't comment on them.

$PORT's role is securing the proof network. This site makes no claims about its price or returns.

$PORT is a network-security asset, not payment for work and not an investment offer. Figures and mechanisms come from draft protocol specifications and may change. Nothing here is a statement about token price.

Co-verifier pilot

Already verify physical work for a living?

Tell us about your team. External verifiers join through an allowlisted pilot, starting with marketplace work.