Start here

Port gives agents structured Solana wallet and token evidence, bounded investigations, watches and alerts.

This documentation site does not hold wallet keys or accept payments. Chat, account controls and intelligence run as separate services. Use the links below when your deployment has them configured; availability and token settings are reported by those services. Do not send tokens to an address from an example.

This deployment has not configured chat and account destinations. Read the setup guide or contact the operator.

Your first research session

1. Create a wallet in your own wallet application, or connect an existing Solana wallet.
2. Sign in to your account with a message proving wallet ownership.
3. Read your holder tier and allowances. If you need deep research, review a token-burn quote for credits.
4. Give an agent access to specific tools with a bounded lifetime. Review paid research before it starts.
5. Open the hosted agent or connect your own MCP client.
6. Review results, credit usage and evidence. Sign out when finished; separately issued client tokens retain their bounded lifetime.

The backend uses authenticated access, optional token holder tiers and burn-funded deep research. Hosted chat and account controls require the agent service; external clients require their own configured connection. Burning tokens does not create a refundable account balance.

Wallet and sign-in

Your wallet keeps its own keys. Create it in a wallet application and keep its recovery phrase there. Port should never ask you to paste a recovery phrase or private key into chat.

Three separate permissions

• Connect: let the site see the selected public wallet address.
• Sign in: sign a short-lived, site-bound message to prove ownership. This is not a payment.
• Pay: separately review and approve a transaction showing its network, token, amount and effect.

The current intelligence server accepts a verified solana_wallet claim from its configured identity issuer. An address entered in a form is not proof of ownership. Sign in on the configured agent service, which owns the wallet session. This static site never receives that session or signs for you.

Account continuity

Access belongs to the authenticated account. The same verified issuer and subject must be used by website chat and external clients to share watches and credits. Switching wallet accounts must not silently transfer an existing balance or another account’s data.

Connect an agent

Use hosted chat for a browser conversation or an MCP client for tools in your own environment. Both use the same authenticated account identity. The service’s public MCP endpoint, when configured, appears below; it still requires a scoped access token.

No intelligence origin is configured for this deployment. Obtain the exact service URL from its operator.

Connect an external client

1. Obtain the deployed service URL and a scoped access token through the agent account integration or its operator. On the account page, create a read-only client key first, choose its lifetime, and save the displayed token in your client’s protected credential settings.
2. Use a client supporting MCP Streamable HTTP and bearer authentication.
3. Set its endpoint to the service origin followed by /mcp. Store the token in the client’s protected credential settings, not in a prompt or public configuration.
4. Initialize MCP and list tools. The server lists only tools permitted by your scopes.
5. Call capabilities_get with {}, then utility_status with {} to inspect availability and account allowances.
6. Start with a read-only question before requesting a saved watch or paid investigation.

Client configuration formats differ. A server URL alone does not supply an identity, authorize payments or guarantee that a client supports this authentication method.

First questions

• “Summarize this public Solana wallet’s balance and holdings; show observation time and coverage gaps.”
• “Explain this transaction and cite the source signature.”
• “Inspect this token’s mint authorities and largest accounts; separate evidence from inference.”

HTTP integrations

Send JSON arguments to POST /v1/tools/<tool_name> with Content-Type: application/json and Authorization: Bearer <access token>. Public resource metadata is at /.well-known/oauth-protected-resource. It identifies the configured issuer; it is not a sign-up endpoint.

{"network":"solana:mainnet","address":"<public Solana address>"}

This is the argument shape for wallet_overview and token_overview. Replace the placeholder before sending. Never put your bearer token in a URL.

Access and payments

Holder access and research credits

Sign in with your wallet, use the allowances available to your holder tier, and optionally burn tokens for deep-research credits. The backend supports this model; use the configured account service for customer controls when its burn interface is available. Read the configured mint and conversion quote before approving a burn. The designated mint is listed below. Its program and decimals must be verified, and the launch policy must match the configured quote, before payment is enabled.

Launch pricing

The mint address has been supplied, but its on-chain mint account is not yet verified. These are launch-policy amounts, not an active sale or a token-value promise. The service must use the actual mint program and decimals to calculate raw amounts. Check the account’s live status and exact quote before approving. SOL network fees are separate. Holding a tier is not a payment or a lock of your tokens.

Backend allowances

When configured, token holdings select Free, Holder or Pro allowances. utility_status reports the current tier, limits and credit balance. Holding tokens does not replace authentication or tool permissions. Limits are ceilings; provider availability and deployment-wide quotas still apply.

The deployment admits at most 100 distinct watched network/address pairs in total. Sharing a watched address across customers reuses that demand.

Existing burn-credit integration

This developer flow is available only on a configured deployment with a verified wallet claim and credits:write permission. Use the account service for wallet interaction; this documentation site cannot perform it.

1. Read utility_status for the actual mint and conversion settings.
2. Request burn_quote with an owned token account and an idempotencyKey.
3. Display the quoted raw amount, decimals, credits and expiry before the customer approves. Burning permanently destroys those tokens.
4. The wallet signs the exact burn transaction. The account adapter submits those signed bytes; direct integrations can submit through their wallet/RPC. The intelligence service never signs or submits it.
5. After finalization, call burn_redeem with the quote ID and transaction signature. Repeating the same valid proof credits it only once.
6. A research start with mode: "deep" spends 10 credits when admitted. Keep the same idempotency key when retrying that start.

Burn quotes last ten minutes. A burn executed inside that window may settle afterward. Admitted deep work is not refunded for cancellation, expiry, missing provider history or partial findings. Credits pay for admitted research work, not a guaranteed finding or a refundable token deposit.

Tools and evidence

Live MCP discovery is authoritative for input schemas and permitted tools. The backend currently defines these tool groups:

Permissions

Read tools use intelligence:read. Research uses research:run and research:read. Watch and alert access use their respective watch:read, watch:write, alerts:read and alerts:write scopes. Credits require credits:write. The configured issuer grants these permissions; asking an agent does not grant them.

Read the evidence with the answer

Evidence responses include timestamps, sources, warnings and a coverage status: complete, partial or unavailable. Completeness applies to the reported operation and scope, not all chain history. Do not interpret missing history as zero activity or zero profit.

Research examines bounded recent signatures. A requested history window is not a promise of every transaction in that interval. Funding links do not prove common ownership. Token-2022 coverage, trade classification and priced profit-and-loss can be partial. Monitoring requires a configured monitor export; creating a watch alone does not prove an event feed is active.

Receipts

Research evidence is stored by the service for the authenticated tenant. A burn receipt separately tracks its quote, transaction signature, state and granted credits. A prepared or pending burn is not a credited balance. Wait for finalized verification and the credited state; a transaction signature alone does not prove successful payment.

Recovery and privacy

When a call fails

• 401: the access token is missing, invalid or expired. Obtain a fresh token from the configured issuer.
• 403: permissions, resource origin or live authorization do not permit the operation. Correct the connection or request the needed scope.
• 429: an allowance is exhausted. Read account status; do not loop retries or assume another tier removes global limits.
• 400: arguments or network are unsupported. Compare the request with the discovered schema.
• 422: the requested evidence cannot satisfy coverage requirements. Narrow the request or inspect the coverage reason.
• 503: a provider or service dependency is unavailable. Inspect the response and service status before retrying.

MCP calls can return a tool error inside a successful transport response. Check isError and the structured error rather than HTTP status alone.

Lost responses

For mutations that take an idempotency key, retain the key and exact arguments. Reconcile the original request or job before starting another. For a burn, retain the quote ID and transaction signature and check finality before redemption. Never burn again merely because a response was lost.

Agent privacy

Research queries can reveal interests even when the underlying chain data is public. Keep access tokens, wallet recovery material and private account data out of prompts. The separate hosted agent processes prompts through its configured model and supports ephemeral and saved conversations. Review its privacy choice before sending. The landing page and documentation do not receive your prompts.

Stopping access prevents future authorized work; it does not erase completed transactions or public chain evidence. Port’s research tools do not trade, withdraw or sign on your behalf.

Account and client access

These routes belong to the agent service, not the intelligence origin or this static site. They use the existing signed-wallet session. Authenticated browser mutations require the exact agent Origin and the session’s CSRF token in X-CSRF-Token. Keep cookies and bearer tokens out of prompts.

Client keys and renewal

Customer client keys last one day by default, with a maximum of seven days. The account page defaults to read-only and displays the exact permissions and expiry. The token is shown when issued and kept only in that page’s memory; it cannot be retrieved from the grant list later. Store it in your MCP client’s protected configuration as a bearer credential, never in a model prompt.

Review your keys on the account page and revoke those you no longer need. Revocation prevents future authorized operations; it does not undo completed work. Renewal means explicitly creating a new key and updating your client. There is no automatic refresh or OAuth flow claimed here. Signing out ends the browser session but does not revoke independent client keys.

Hosted-agent delegation is separate and still lasts at most 120 seconds per grant. The account identity, audience and permissions remain checked by the intelligence service for both access paths.

Account wallet flow

The account UI destination is /account.html on the configured agent origin. Its burn adapter implements owned token-account discovery, quote and exact transaction review, wallet signature, submission, finality reconciliation and credit redemption. Availability still depends on the deployed service configuration. Do not replace this sequence with an arbitrary transfer or an additional burn after a lost response.