Dokens. A unit for useful work.

One token system. Two ways to reach people.

Dokens is the token system being introduced as part of sMCP’s agent economy. The aim is straightforward: create an agent, define what its work costs, and monetize its use by DiviDen and exponentialOS users—whether they encounter it on your property or inside our platforms.

sMCP describes the capability and governs the approved run. Dokens provides the unit for paid usage. OAuth connects an account to an external property. Each has a distinct job.

On your own property

Keep your website, app, brand, and relationship with your audience. A user connects their DiviDen account through OAuth. Your experience presents the agent’s task, requested permissions, and price before asking for approval.

The proposed Dokens integration connects that approved usage to the token system. Account sign-in alone does not authorize a paid run or access to every resource in the account.

Inside DiviDen and exponentialOS

Distribute your agent through DiviDen or an exponentialOS deployment. Users encounter the capability in their platform workflow; the agent still needs an explicit task contract and the appropriate permissions.

exponentialOS is DiviDen’s white-label enterprise version. The same product story applies under an organization’s brand. An enterprise deployment’s enabled integrations and access policies determine what is available to its users.

Build the capability first

1. Define a useful task with explicit input and output schemas.
2. Declare the permissions, pricing model, and settlement terms in the agent’s contract.
3. Verify and register the agent, then complete the applicable publication review.
4. Choose where people will use it: your own property, DiviDen, or exponentialOS.
5. Connect paid usage through the Dokens integration when enabled for that environment.

The build and publish guide covers the existing developer workflow. The wire specification defines the current contract. The current wire contract remains v0.1; Dokens-specific charging fields are not yet published.

OAuth on your property

DiviDen implements an authorization-code flow with PKCE. A registered, active OAuth client needs an allowed redirect URI and a permitted set of scopes.

The flow has three parts:

1. Send the user to the authorization endpoint with your registered client ID, redirect URI, requested scopes, a unique state, and an S256 PKCE challenge.
2. Check the returned state on your callback, then exchange the authorization code using its matching PKCE verifier.
3. Use the granted access token only for the allowed routes and scopes. Refresh and revocation are separate operations.

The current DiviDen endpoints are:

These belong to the account service. They are separate from an sMCP node’s authentication scheme. The reference node’s existing MCP bearer authentication is unchanged.

A scope such as earnings:read permits reading earnings information; it does not move money. The current OAuth catalog does not include a Dokens spend scope. Registering an external application is also separate from registering an OAuth client and obtaining a user’s consent.

Keep the price inside the agreement

An sMCP approval binds the agent’s manifest, task, inputs, scopes, and maximum charge. The broker rechecks the binding before dispatch. Settlement guards check the approved charge ceiling and prevent a replayed completion from settling the same execution twice.

For a Dokens integration, the token charge must remain part of that explicit agreement. Showing a price in your interface or connecting an account is not a substitute for server-side authorization.

Tokens, model tokens, and cash

Dokens is the product name for the proposed agent-usage token system. Model input and output tokens measure inference workload; they are a different unit. Use the cost calculator to model provider costs separately from your agent’s price.

The current DiviDen token wallet holds whole tokens and records each movement in a ledger. It is a closed-loop balance: supported returns go back to the DiviDen account, and tokens cannot currently be withdrawn as cash.

Integration status

The current reference implementation contains account OAuth, external-application registration, a token wallet, and paid-agent approval and settlement controls. The token wallet’s implemented movements currently serve purchases and contribution gates. Paid-agent settlement uses a separate payment path.

An end-to-end Dokens charge for an external OAuth app has not yet been verified in that implementation. This guide introduces the integration direction and documents the existing building blocks; it does not announce a self-service Dokens payment API.

Build an agent, read the security model, or explore DiviDen and exponentialOS.