Scored by asking 15 questions a buyer of a blockchain product asks, then grading this site’s own pages: answered, hedged (partial or vague), or silent (no page answers it). How scoring works
15 buyer questions · graded against the site’s own pages
4 of 15 come back answered. 8 get a hedge. 3 meet silence.
44 points sit between tempo.xyz and 100: 11 open questions and 6 missing protocol checks, ordered by estimated payoff.
Point estimates are per fix under scoring v2. They are not additive to a promised total.
01pricing · importance mediumGoes silent+7 content pts est.
For the ARQ and Coastal Bank cross-border payment solutions built on Tempo, what FX spread or margin do they typically charge on currency conversions, or is that entirely up to the integrating institution?
What the pages say
No page on the site addresses this.
The fix
Add a pricing or economics section to the ARQ and Coastal customer stories, or create a dedicated page explaining how FX conversion works on Tempo—including whether spreads are standardized, set by integrating institutions, or handled by third-party liquidity providers.
confidence high · grounding world-knowledge · weight 0.00 · Absent
02pricing · importance lowGoes silent+7 content pts est.
The Kv storage feature for server handlers — is this billed per read/write operation, per GB stored, or included free with account abstraction usage?
What the pages say
No page on the site addresses this.
The fix
Add a pricing or billing section to the Kv documentation explaining whether server handler Kv usage is free, metered per operation, metered by storage volume, or bundled with account abstraction usage.
confidence high · grounding synthesized · weight 0.00 · Absent
03operations · importance lowGoes silent+7 content pts est.
For Handler.relay transactions, is there an SLA on relay inclusion time, and what happens if the relay is congested — do transactions queue or fail immediately?
What the pages say
No page on the site addresses this.
The fix
Add documentation on Handler.relay service level expectations: target inclusion times, SLA commitments if any, and explicit behavior when the relay is under load (queueing policy, rate limits, or error responses).
confidence high · grounding synthesized · weight 0.00 · Absent
Hedged · 8 of 15 questions
A buyer gets something, then has to guess the rest. Expand any row for the evidence and the fix.
04For the native DEX used in stablecoin exchanges, what's the maximum slippage protection or minimum output guarantee we can set programmatically, and are there MEV protections?technicalHedges+2 pts est.+−
For the native DEX used in stablecoin exchanges, what's the maximum slippage protection or minimum output guarantee we can set programmatically, and are there MEV protections?
What the pages say
The Stablecoin DEX allows programmatic slippage protection via `minAmountOut` (for exact-in swaps) and `maxAmountIn` (for exact-out swaps) parameters in the swap functions. These are set by the caller based on their own slippage tolerance calculations—the protocol does not enforce a maximum slippage limit or provide a built-in minimum output guarantee; you must calculate and specify your own thresholds. For example, the docs show calculating a 0.5% slippage tolerance off-chain and passing the resulting `minAmountOut` or `maxAmountIn` to the swap function. Regarding MEV protections: the chunks do not mention any specific MEV protection mechanisms (such as private mempools, commit-reveal schemes, or MEV-resistant batch auctions).
confidence high · grounding synthesized · weight 0.70 · Answered
05We're a fintech looking to embed Tempo for customer payouts. Does Tempo provide built-in KYC/AML tooling in their embedded finance offering, or do we need to integrate our own compliance stack?securityHedges+2 pts est.+−
We're a fintech looking to embed Tempo for customer payouts. Does Tempo provide built-in KYC/AML tooling in their embedded finance offering, or do we need to integrate our own compliance stack?
What the pages say
Tempo does not provide built-in KYC/AML tooling as a native feature. Instead, Tempo offers 'native compliance controls' and integrations with leading compliance providers including Blockaid, Chainalysis, Sardine, and TRM Labs. For embedded finance specifically, Tempo partners with infrastructure providers like Blockradar that offer 'AML checks automatically' as part of their wallet and payment operations platform. However, the chunks do not explicitly state whether Tempo itself provides KYC/AML tooling directly in its embedded finance offering or if customers must always integrate with third-party compliance partners.
The fix
Add explicit documentation on whether Tempo's embedded finance offering includes built-in KYC/AML features or requires integration with third-party compliance providers, with clear guidance on which compliance partners are pre-integrated vs. require separate contracts.
confidence medium · grounding synthesized · weight 0.65 · Vague
06The Payment Lane Specification mentions dedicated throughput — what's the actual TPS allocation per lane, and can we burst above our allocation or is it strictly capped?limitsHedges+2 pts est.+−
The Payment Lane Specification mentions dedicated throughput — what's the actual TPS allocation per lane, and can we burst above our allocation or is it strictly capped?
What the pages say
The chunks describe payment lane throughput in terms of gas limits and TPS calculations, but do not specify a per-lane TPS allocation that can be directly purchased or assigned to a specific customer. Chunk [8] from TIP-1016 shows that with a 500M payment lane gas limit, existing account transfers achieve ~20,000 TPS and new account transfers ~14,300 TPS. Chunk [15] from TIP-1010 clarifies this is a shared capacity model: the payment lane is 'non-dedicated' with 450M gas for the proposer pool (shared between general and payment transactions), where general transactions are capped at 30M gas, guaranteeing at least 420M gas remains for payment transactions. However, there is no information about whether customers can burst above their allocation or if throughput is strictly capped per lane. The 'dedicated payment lanes' marketing language in chunks [1]-[7], [12] appears to describe protocol-level reservation, not customer-specific dedicated throughput with burst policies.
The fix
Add explicit documentation on whether payment lane throughput is allocated per customer/organization, what the specific TPS allocation is per lane, and whether bursting above allocation is permitted or strictly capped. The current 'dedicated payment lanes' marketing conflicts with the 'non-dedicated' shared capacity model described in technical specs.
confidence medium · grounding synthesized · weight 0.65 · Vague
07If we're using Handler.webAuthn for biometric authentication, what happens when a user loses their device or biometric factor changes — is there a recovery flow, and who controls the recovery keys?securityHedges+2 pts est.+−
If we're using Handler.webAuthn for biometric authentication, what happens when a user loses their device or biometric factor changes — is there a recovery flow, and who controls the recovery keys?
What the pages say
The chunks do not describe a specific recovery flow for Handler.webAuthn when users lose devices or biometric factors change. However, the Terms of Service state that 'If you lose your private keys or credentials to access your passkeys, you will permanently and irrevocably lose access to your Wallet and any digital assets associated with it. Tempo cannot recover your private keys or credentials to access your passkeys or restore access to your Wallet.' This suggests a self-custody model where recovery is user-controlled or impossible. The blog post on passkey accounts notes that 'Passkeys are stored in the device's secure enclave and sync across devices through iCloud Keychain or Google Password Manager,' which provides some device-loss protection via platform-level sync, but does not address biometric factor changes or explicit recovery key mechanisms.
The fix
Add explicit documentation for Handler.webAuthn covering: (1) what happens when a user loses their device, (2) whether recovery keys exist and who controls them, (3) how biometric factor changes (new fingerprint, Face ID re-enrollment) are handled, and (4) whether the platform-level passkey sync (iCloud/Google) is the only recovery mechanism or if app-level recovery exists.
confidence medium · grounding synthesized · weight 0.65 · Vague
08We have existing Solidity contracts on Ethereum. What's the actual compatibility level — can we deploy unmodified EVM bytecode, or are there opcodes or precompiles that Tempo doesn't support?migrationHedges+2 pts est.+−
We have existing Solidity contracts on Ethereum. What's the actual compatibility level — can we deploy unmodified EVM bytecode, or are there opcodes or precompiles that Tempo doesn't support?
What the pages say
Tempo targets the **Osaka EVM hard fork** and states that "all opcodes are supported out of the box" at the VM layer. However, there are critical behavioral differences: `BALANCE`, `SELFBALANCE`, and `CALLVALUE` opcodes always return 0 due to Tempo having no native token. Additionally, state-creating operations have significantly higher gas costs (e.g., new storage slot: 250,000 gas vs Ethereum's 20,000 gas; account creation: 250,000 gas vs 0 gas; contract creation: 1,000 gas/byte vs 200 gas/byte). The chunks do not provide a comprehensive list of supported precompiles or confirm whether all Osaka precompiles are implemented, though chunk [20] mentions "Bumped precompile set from Prague to Osaka at T1C" suggesting precompile support follows hard fork targeting.
confidence medium · grounding synthesized · weight 0.65 · Answered
09We're considering running our own Tempo node for redundancy. What are the exact hardware requirements, and is there a minimum stake or validator bond required to participate in consensus?operationsCollapsed+2 pts est.+−
We're considering running our own Tempo node for redundancy. What are the exact hardware requirements, and is there a minimum stake or validator bond required to participate in consensus?
What the pages say
The active validator set is currently permissioned — you cannot self-register a validator without coordinating with the Tempo team. To become a validator, you must contact partners@tempo.xyz. The site mentions "minimum and recommended system requirements" exist but the actual hardware specs (CPU, RAM, storage size) are not shown in the retrieved chunks — only that execution state needs NVMe storage while consensus state can live on lower-performance volumes like EBS, and that cloud instances with network-attached storage do not provide sufficient I/O performance. No minimum stake or validator bond amount is mentioned anywhere in the retrieved content.
The fix
The System Requirements page appears to have collapsed or failed-to-render content — the heading promises 'minimum and recommended' specs but no numbers appear. Expand the accordion or fix the rendering to show CPU, RAM, and storage requirements. Also add explicit documentation on whether a minimum stake or validator bond is required for consensus participation.
confidence medium · grounding synthesized · weight 0.65 · Collapsed
10When using Handler.compose to batch multiple calls, is the entire batch atomic — meaning if one call reverts, do all revert? And is there a maximum number of calls per composed transaction?technicalHedges+2 pts est.+−
When using Handler.compose to batch multiple calls, is the entire batch atomic — meaning if one call reverts, do all revert? And is there a maximum number of calls per composed transaction?
What the pages say
Yes, batch transactions in Tempo are atomic — if any call reverts, the entire batch reverts. This is stated explicitly in multiple places: "Atomic execution: All calls succeed or all calls revert together—no partial failures" and "If any call reverts, the entire batch reverts." However, the chunks do not specify a maximum number of calls per composed transaction. The examples show 3 calls, and one blog post mentions "thousands of payments at once" as a supported use case, but no explicit limit is documented.
The fix
Add explicit documentation on the maximum number of calls allowed per batch transaction, including any protocol-level limits or practical gas-based constraints.
confidence high · grounding synthesized · weight 0.70 · Vague
11Using tempoWallet with Wagmi, can we customize the connection UI branding or is it whitelabeled Tempo-only, and does it support WalletConnect for mobile?integrationHedges+2 pts est.+−
Using tempoWallet with Wagmi, can we customize the connection UI branding or is it whitelabeled Tempo-only, and does it support WalletConnect for mobile?
What the pages say
The tempoWallet connector uses the Tempo Wallet dialog which appears to be Tempo-branded ("Sign in" button opens "the Tempo Wallet dialog for the user" per chunk [11]). The chunks do not mention any UI customization or whitelabeling options for the connection UI. For WalletConnect on mobile: chunk [9] mentions that Wagmi wallet connectors like `metaMask` can be used "to support mobile devices," but this refers to using MetaMask's connector, not WalletConnect specifically. The tempoWallet connector itself is not documented as supporting WalletConnect.
The fix
Add documentation clarifying whether tempoWallet's UI can be customized or whitelabeled, and explicitly state WalletConnect support status for mobile connections.
confidence medium · grounding synthesized · weight 0.65 · Vague
What the pages already answer cleanly
4 of 15. Answered with enough specificity for a buyer to act on. This is the bar the queue above is chasing.
technicalAnswered
Our wallet team needs to implement gasless transactions for users. Does Tempo's account abstraction support third-party gas sponsorship, and can we sponsor via our own relayer or only through Tempo's infrastructure?
What the pages say
Yes, Tempo's account abstraction supports third-party gas sponsorship, and you can sponsor via your own relayer. The protocol includes a `fee_payer_signature` field directly in the transaction where a sponsor signs to agree to pay fees. You can run your own fee payer service using `Handler.relay` with a configured `feePayer` account, or use Tempo's public testnet fee payer service at `https://sponsor.moderato.tempo.xyz` for development. The documentation explicitly states: "You can also build your own fee paying service" and provides code examples for configuring a custom relay with `feePayer: { account: privateKeyToAccount('0x...'), name: 'My App', url: 'https://myapp.com' }`. No contracts or external infrastructure are required—sponsorship happens natively at the protocol level.
confidence high · grounding synthesized · weight 0.95 · Answered
technicalAnswered
We're building a high-frequency trading integration and need to know the exact time to finality for Tempo transactions — is it sub-second, and what's the specific block time or confirmation threshold?
What the pages say
Tempo provides sub-second finality with blocks finalized every ~0.5 seconds. The confirmation threshold is a single finalized block—once a block is marked as final, transactions in that block are guaranteed to be included in the chain with no additional confirmations needed. Tempo uses Simplex BFT consensus (via Commonware) with deterministic finality, unlike Ethereum's ~12 minute finality. For settlement purposes, treat finalized blocks as irreversible and query them using `eth_getBlockByNumber` with the `finalized` tag.
confidence high · grounding synthesized · weight 0.95 · Answered
pricingAnswered
Does Tempo charge network fees for TIP-20 stablecoin transfers, and if so, are they fixed per transaction or percentage-based? We're comparing against USDC on Solana for our remittance product.
What the pages say
Tempo charges network fees for TIP-20 stablecoin transfers, and they are fixed per transaction (not percentage-based). Specifically, Tempo uses a fixed base fee set so that a TIP-20 transfer costs less than $0.001. The fee structure is fixed rather than variable like EIP-1559, and fees are denominated in attodollars (10^-18 USD) per gas. This is a flat fee per transaction, not a percentage of transfer value.
confidence high · grounding synthesized · weight 0.95 · Answered
migrationAnswered
We built on Handler.feePayer before it was deprecated. What's the exact migration path — is there a drop-in replacement or do we need to rearchitect our sponsorship flow?
What the pages say
There is a drop-in replacement. Replace `Handler.feePayer` with `Handler.relay` and nest the `account` under `feePayer`. All other options (`chains`, `transports`, `path`, `onRequest`) remain the same — `validate` moves inside `feePayer`. Example: `const handler = Handler.relay({ feePayer: { account: privateKeyToAccount('0x...'), validate: (request) => request.from !== blocked, } })`
confidence high · grounding stated · weight 1.00 · Answered
Protocol plumbing · 45/1005 of 11 checks pass · each fix +9 protocol pts est.
The other half of the score: 11 checks for the files and headers agents look for. The 6 below are installs, not judgment calls, and most are an afternoon. Expand any for the snippet and the standard it follows. They sit after the queue because none of them changes what your pages say.
llms.txtDiscoverability+9 pts est.+−
Sitedex generates this file from your crawl. Grab it in Files from this audit below.
Already passing 5 of 11: robots.txt, sitemap.xml, AI crawler access, Clean crawl, Server-rendered content.
Ask this site’s index
Sitedex already serves tempo.xyz as an MCP endpoint. Ask tempo.xyz anything an AI agent might ask, and see what its index returns. (To score your own site, use the form below.)
Snippets & configs
For developers and the engineer-on-call: copy these into your tools or your site.
Files from this audit
Built from this crawl. Download or copy each, then install it at the path noted.
llms.txt
Built from this crawl. Install at /llms.txt so agents start here.
organization.json
Organization JSON-LD, pre-filled from this crawl. Wrap in a ld+json script.
server-card.json
MCP server card built from this crawl. Host at /.well-known/mcp/server-card.json.
webmcp.json
WebMCP discovery manifest built from this crawl. Host at /.well-known/webmcp.json.
MCP endpoint
https://mcp.sitedex.dev/s/tempo-xyz/mcp
The URL anyone's agent points at. Read-only; safe to share.
Claude Code
claude mcp add tempo --transport http https://mcp.sitedex.dev/s/tempo-xyz/mcp
Drop in <head>. In browsers with WebMCP, this script registers your site's tools with navigator.modelContext.registerTool().
2 · Discovery manifest
{
"schema_version": "2026-04",
"name": "Tempo",
"description": "Tempo is a purpose-built, Layer 1 blockchain for payments, developed in partnership with leading fintechs and Fortune 500s. WebMCP tools served by Sitedex.",
"homepage": "https://tempo.xyz",
"documentation": "https://app.sitedex.dev/sites/tempo.xyz",
"source": "navigator.modelContext",
"tools": [
{
"name": "search_site_content",
"description": "Ask about this site in plain language and get the most relevant passages from its pages, each with the source URL and a relevance score. Searches the site's published text, not live inventory or accounts."
},
{
"name": "get_site_info",
"description": "This site's profile: name, description, category, who it is for, page count, and AI Visibility Score. Use it to learn what the site is before you search it."
},
{
"name": "list_site_pages",
"description": "The pages indexed on this site, with title, URL, and path. Use it to see what the site covers, or to find the path to pass to get_site_page."
},
{
"name": "get_site_page",
"description": "The full markdown of one page on this site, by path. Use it after search_site_content points you at a page and you want all of it."
}
]
}
Host alongside the script at /.well-known/webmcp.json. Crawlers that don't render JS rely on this.
Your turn
See which of these questions your site goes silent on.
Free, about 5 minutes. We crawl your site, test it against the buyer questions your category asks, and name what’s vague, contradictory, or missing, plus the files AI agents look for.
ComingEmbeddable grade badgeScore history and deltasOpt-in public board