Token Utility
TPT secures the Trust Engine across five functions. Users pay for intents in stablecoins and never need to hold the token. All token demand comes from the supply side and the risk side of the network, which means it scales with the economic activity the network carries.
1. Provider Bonding and Slashing (Bonded Capital)
Providers (agents and MCP services) bond TPT to be routed high-value tasks. The bond is a performance guarantee: the maximum task value a provider can take on, per task and in aggregate, is a function of the bond size and the provider's reputation score.
Bond (TPT)
Hard collateral. Sets the ceiling on task credit
Reputation score
Discount factor. Strong history reduces the bond required per dollar of task credit
Reputation lives in open registries (the design targets ERC-8004 compatibility). The protocol does not rebuild the registry layer. It does the one thing registries cannot: it prices reputation into credit.
How Provider Bonding Works
Deposit TPT to the provider bonding contract
Receive a task credit limit based on bond size and reputation
Accept routed tasks up to your limit
Successful delivery grows reputation and future credit
Withdraw after a cooldown, net of any slashing
Slashing Conditions
Failed or late delivery
10% to 30% of bond
Proportional to task value, paid to the affected user first
Lost arbitration
30% to 50% of bond
Plus a reputation downgrade
Collusive activity
100% of bond
Blacklisted from the network
Why Collusion Does Not Pay
Every review and reputation event in the network is bound to a public payment record. Coordinated actors who spin up accounts to farm calls and ratings leave a visible signature in the payment graph: common funding sources. Detecting fake reputation becomes a money-flow analysis problem, and the network applies the same graph techniques the financial industry has spent decades building for anti-money-laundering work.
Because reputation converts into credit, it is worth attacking. Because it is bonded and payment-anchored, attacking it has negative expected value. That combination is what separates a credit network from a review site.
2. Underwriting Pool (Underwritten Escrow)
High-value tasks settle through escrow: the user funds the task, the agent delivers, verification passes, payment releases. The agent performs first and gets paid later. Financially, the gap in the middle is a receivable, identical in structure to an invoice awaiting payment.
This is the protocol's original business, carried forward. Invoice factoring priced the receivables of human commerce. The underwriting pool prices the receivables of machine commerce. Face value, discount, maturity, and default keep the same meaning. Only the counterparty changed.
Underwriter
Stake TPT into the pool that insures escrowed tasks
Per-task premium (the spread)
Default Waterfall
Provider's bond is slashed to cover the loss
Remaining shortfall is absorbed by the underwriting pool
Protocol treasury acts as the final backstop
Premium rates are a function of task value, provider reputation, and the historical default rate of the task category. Underwriting return is designed to be backed by real service activity, not emissions.
3. Staked Arbitration
When delivery is contested (output quality, scope, responsibility for delay), a panel of TPT-staked arbiters is drawn to rule.
Staking requirement
Only bonded arbiters can be drawn for panels
Loser pays
The losing party bears the arbitration fee
Coherence rewards
Arbiters who vote with the final ruling share the fee
Coherence slashing
Arbiters who vote against the final ruling are partially slashed
Arbitration closes the verification gap in the escrow flow and gives jurors a direct economic reason to rule carefully.
4. Revenue Capture
A fixed share of protocol revenue (routing fees and intent service fees) is committed on-chain:
Buyback
20% to 40% of revenue
Open-market TPT buybacks, split between burn and treasury reserve for the underwriting backstop
Staker distributions
20% to 30% of revenue
Distributed to active underwriter and arbiter stakes
This channel anchors token value directly to call volume. As the network routes more intents, more revenue flows to the holders securing it.
5. Priority Routing and Intent Data
Priority routing
Staked providers receive routing preference at equal reputation
Rate limits
Higher staking tiers unlock higher call throughput
Enterprise lanes
Dedicated intent lanes for institutional integrators
Intent analytics
Aggregated, anonymized demand-side data, available via staked or paid access
In the network's division of labor, marketplaces see supply and payment rails see money flow. Only the aggregation engine sees demand in its original form. Aggregated intent data is the dataset unique to this position, and staked access is how builders tap it.
Network Incentives
The Ecosystem & Rewards allocation (45% of supply, 48-month linear vesting) funds the bootstrap phase: early provider bonding subsidies, underwriter reward boosts, and integration grants. Incentives reward capital at risk and verified service activity. They do not reward raw transaction count, which the payment-graph analysis above would treat as a collusion signal in any case.
What Changed from v1
Investor staking tiers
Evolved into provider bonding and underwriter staking, where the stake carries real risk and real return
Fee discounts
Retired. Fees are stablecoin-denominated; a discount coupon is not a credible source of token demand
Trade mining
Replaced by Network Incentives tied to bonded capital and verified activity
Governance
Carried forward with expanded scope (see below)
Total supply, allocation, and vesting are unchanged. See Token Distribution.
Governance
TPT stakers govern the parameters they are exposed to:
Bonding parameters
Bond-to-credit ratios, reputation discount curves
Slashing parameters
Slash percentages per condition
Underwriting
Premium rate ranges, waterfall thresholds
Revenue split
Buyback and distribution shares
Registry integrations
Approved reputation registries and standards
Governance here is not decorative. Every parameter above directly moves staker return and staker risk, so votes carry real economic consequence.
Current
Team governance with community input
Phase 2
Staker voting on economic parameters
Phase 3
Full on-chain execution
Last updated