Overview
T3N tokens are used to meter TEE contracts execution and storage inside the T3N. They are not OAuth tokens, session tokens, JWTs, or API keys.
Every T3N identity is represented by a DID, and each DID can hold a T3N token balance. When a DID performs a metered operation, the operation and its associated token charge are processed as a single atomic transaction. This guarantees that the work and the charge either succeed together or fail together. If the operation is successfully recorded, the corresponding tokens are deducted. If the operation fails, no tokens are charged. As a result, work cannot be recorded without payment, and payment cannot be deducted without the corresponding work being recorded.
At a high level:
Your DID balance
|
| pays for
v
Metered contract execution
- WASM compute fuel
- host-function calls such as kv.put or cas.write
- storage deposit and storage rent
- contract registration when the admin request bills your DID
Tokens are currently non-transferable. Transferrability is coming soon.
Failure Semantics
Metered WASM uses charge-on-attempt semantics.
If a contract starts and consumes cluster resources, the caller pays for the fuel and
host-function budget consumed even if the contract later returns an error, panics, or
runs out of token. Contract writes are rolled back on failure, but consumed work is
still charged.
Consensus write conflicts are different. If the prepared transaction cannot commit
because another transaction won the same write conflict, the prepared charge is dropped
with the rest of the transaction. A retry runs the contract again and, if that retry
commits, that retry is charged independently.
Practical rule for app developers: handle contract-level failures as billable attempts;
handle retry loops carefully so your app does not submit the same expensive work more
than intended.
