14 minutos de leitura

Visão geral

O Machine Payments Protocol (MPP) permite-lhe pagar pelo acesso à API diretamente numa solicitação HTTP. Sem contas, sem chaves de API. Basta uma carteira com saldo em stablecoin.

As sessões vão um passo além. Basta abrir um canal de pagamento uma vez e, depois, reutilizá-lo para todos os pedidos. Cada chamada é paga com um pequeno voucher assinado, pelo que não há uma transação na cadeia de blocos de cada vez e os pedidos continuam a ser rápidos.

Neste guia, irá criar um script em TypeScript que abre uma única sessão MPP, consulta os saldos de tokens nativos em 15 cadeias EVM utilizando os pontos de extremidade MPP da Quicknode e gera um relatório formatado com uma discriminação dos custos.

Esta é uma excelente opção para sessões, porque o script efetua várias chamadas RPC em diferentes redes numa única execução. Em vez de pagar cada chamada individualmente, todos os pedidos passam por um único canal de pagamento. Paga-se o custo de configuração uma única vez e, depois, reutiliza-se essa configuração para o resto.

O Quicknode suporta sessões MPP em todas as cadeias compatíveis. A mesma sessão que consulta a Ethereum também pode consultar a Base, a Arbitrum, a Polygon e outras, sem necessidade de configuração adicional.

Nível gratuito

Cada carteira dispõe de um limite gratuito partilhado de 1 000 000 de créditos API por mês nas plataformas de pagamento baseadas em agentes da Quicknode, incluindo o MPP e o x402. Os pedidos RPC padrão consomem 1 crédito API cada, enquanto o SQL Explorer consome os créditos API utilizados pela consulta.

O MPP é um dos dois protocolos de pagamento agênicos na Quicknode

O Quicknode suporta dois protocolos de pagamento baseados em carteira para acesso RPC sem conta: o MPP (utilizado neste guia) e o x402 (um padrão aberto da Coinbase). Ambos permitem que scripts e agentes de IA paguem pelas chamadas à API diretamente, sem necessidade de conta ou chaves de API, mas diferem no formato da transmissão, na mecânica da sessão e nos métodos de pagamento suportados. Consulte a visão geral dos Pagamentos Agentic para uma comparação lado a lado, ou aceda à documentação do x402 e à documentação do MPP para obter detalhes sobre os protocolos.

O que irá aprender

• Como funciona o Protocolo de Pagamentos Automáticos e por que razão existem as sessões
• O ciclo de vida completo da sessão: desafio 402, depósito no canal, assinatura do voucher e liquidação
• Como utilizar o mppx SDK para criar e gerir sessões de pagamento
• Como efetuar várias chamadas RPC numa única sessão em diferentes cadeias, utilizando os pontos de extremidade MPP da Quicknode

O que vai precisar

• Node.js v20 ou posterior
• Conhecimentos básicos de TypeScript e cadeias EVM
• Não é necessário ter uma conta Quicknode nem chaves API (o MPP trata do acesso e da faturação)
• Uma pequena quantidade de PathUSD na rede de testes do Tempo (financiada automaticamente através do «faucet» no script) ou de PathUSD/USDC.e na rede principal do Tempo para utilização em produção

O que é o Protocolo de Pagamentos Automáticos?

O Protocolo de Pagamentos Automáticos é um padrão aberto proposto à IETF que permite a integração de pagamentos em qualquer ponto final HTTP. Foi concebido para resolver um problema específico: os clientes programáticos (agentes, scripts, bots) não dispõem de uma forma adequada de pagar pelo acesso à API sem que um utilizador humano configure previamente a faturação.

Os fluxos de pagamento tradicionais dependem de formulários de finalização de compra, sessões do navegador e CAPTCHAs visuais. O MPP substitui esses elementos por uma negociação de pagamento legível por máquina, baseada em HTTP 402 Pagamento necessário.

Como funciona

O protocolo segue um padrão de desafio-resposta:

1. Pedido: O cliente envia um pedido HTTP normal para um ponto final pago.
2. Desafio: O servidor responde com 402 Pagamento necessário e um WWW-Authenticate: Pagamento cabeçalho que descreve o preço, as moedas aceites e os métodos de pagamento disponíveis.
3. Pagamento: O cliente escolhe um método de pagamento e efetua o pagamento (assina uma transferência de stablecoin, abre um canal de pagamento, etc.).
4. Tentar novamente: O cliente reenvia o pedido original com um Autorização: Pagamento cabeçalho com o comprovativo de pagamento.
5. Entregar: O servidor verifica o pagamento e devolve a resposta com um Recibo de pagamento cabeçalho.

Bibliotecas de cliente como mppx executa automaticamente os passos 2 a 4. Do ponto de vista do seu código, o pedido simplesmente funciona.

Cobrança vs. Sessão

O MPP define duas intenções de pagamento que controlam o funcionamento da faturação:

	Carga	Sessão
Padrão	Pagamento único por pedido	Pagamento à medida que se utiliza, através de um canal de pagamento
Acordo	Transação na cadeia de blocos por pedido	Vouchers fora da cadeia; liquidação na cadeia apenas na abertura/fecho
Latência de verificação	Centenas de milissegundos (na cadeia de blocos)	Microssegundos (limitado pela CPU ecrecover)
Ideal para	Consultas ocasionais, integrações simples	Pedidos de alta frequência, fluxos de trabalho em lote, agentes

A principal diferença reside na forma como a verificação do pagamento é efetuada. No caso do «charge», cada pedido desencadeia uma transação na cadeia de blocos. No caso das «sessões», o servidor verifica um comprovativo assinado utilizando um único ecrecover chamada, sem chamadas RPC nem gravações na base de dados no caminho crítico. Isto significa que o servidor nunca acede à cadeia durante a sessão, pelo que a taxa de processamento é limitada pela CPU do servidor e não pelo consenso da blockchain.

Nos endpoints MPP da Quicknode, isto traduz-se também em poupanças concretas: as solicitações de cobrança custam 0,001 dólares cada, enquanto as solicitações de sessão custam 0,00001 dólares cada. Para um script que efetua mais de 15 chamadas RPC em diferentes redes numa única execução, as sessões são a opção mais adequada:

Cadeias consultadas	Custo (0,001 $/solicitação)	Sessão (0,00001 $/pedido)
10	$0.010	$0.0001
25	$0.025	$0.00025
50	$0.050	$0.0005

Compreender o ciclo de vida da sessão

Antes de passarmos ao código, é importante compreender como as sessões funcionam nos bastidores. O diagrama seguinte mostra o fluxo completo do nosso verificador de saldo multichain:

Conceitos-chave

Canal de pagamento: Um contrato de garantia na cadeia de blocos, no qual o cliente deposita os fundos antecipadamente. Isto ocorre uma única vez, no início da sessão.

Vouchers cumulativos: Cada pedido inclui uma mensagem assinada que diz «Já consumi um total de X». Os vouchers são cumulativos, não incrementais. O servidor apenas necessita do voucher mais recente para reclamar todos os fundos em dívida. Por exemplo, após três pedidos de 0,00001 $ cada: voucher(1) = 10, voucher(2) = 20, voucher(3) = 30 unidades atómicas.

Sessões em várias redes: Uma única instância de sessão processa pedidos em diferentes /sessão/:rede pontos finais. A sessão gere o canal de pagamento; o «slug» da rede determina para qual backend RPC da Quicknode a solicitação é encaminhada.

Liquidação: Quando a sessão termina, o servidor liquida o comprovativo final na cadeia de blocos. O cliente recebe o reembolso de qualquer depósito não utilizado.

Configuração do projeto

O script completo encontra-se no qn-guia-exemplos repositório (ver o ficheiro fonte diretamente). Clone-o e instale as dependências:

git clone https://github.com/quiknode-labs/qn-guide-examples.git
cd qn-guide-examples/mpp/multichain-balance-checker
npm install

Também pode copiar o index.ts ficheiro no seu próprio projeto e instale as dependências necessárias.

O projeto utiliza duas dependências de tempo de execução:

Embalagem	Objetivo
mppx	Cliente do protocolo MPP (gestão de sessões, assinatura de vouchers)
vieram	Operações com a carteira e formatação do saldo

E duas dependências de desenvolvimento: tsx para executar o TypeScript diretamente, e Typescript para a verificação de tipos.

Definição do Registo da Cadeia

O script consulta os saldos nativos em várias cadeias EVM. Cada cadeia é definida com o seu slug de rede MPP, nome de exibição, símbolo do token nativo e precisão decimal:

const CHAINS = [
  { slug: 'ethereum-mainnet', name: 'Ethereum', symbol: 'ETH', decimals: 18 },
  { slug: 'base-mainnet', name: 'Base', symbol: 'ETH', decimals: 18 },
  { slug: 'arbitrum-mainnet', name: 'Arbitrum', symbol: 'ETH', decimals: 18 },
  { slug: 'optimism-mainnet', name: 'Optimism', symbol: 'ETH', decimals: 18 },
  { slug: 'matic-mainnet', name: 'Polygon', symbol: 'POL', decimals: 18 },
  { slug: 'worldchain-mainnet', name: 'World Chain', symbol: 'ETH', decimals: 18 },
  { slug: 'bsc-mainnet', name: 'BNB Chain', symbol: 'BNB', decimals: 18 },
  { slug: 'fantom-mainnet', name: 'Fantom', symbol: 'FTM', decimals: 18 },
  { slug: 'celo-mainnet', name: 'Celo', symbol: 'CELO', decimals: 18 },
  { slug: 'xdai-mainnet', name: 'Gnosis', symbol: 'xDAI', decimals: 18 },
  { slug: 'zksync-mainnet', name: 'zkSync Era', symbol: 'ETH', decimals: 18 },
  { slug: 'scroll-mainnet', name: 'Scroll', symbol: 'ETH', decimals: 18 },
  { slug: 'linea-mainnet', name: 'Linea', symbol: 'ETH', decimals: 18 },
  { slug: 'mantle-mainnet', name: 'Mantle', symbol: 'MNT', decimals: 18 },
  { slug: 'blast-mainnet', name: 'Blast', symbol: 'ETH', decimals: 18 },
]

O slug de rede é o elemento-chave aqui. Este remete para o ponto final da sessão MPP em https://mpp.quicknode.com/session/:slug. O /sessão/ O prefixo na URL é o que indica ao servidor para utilizar a intenção de sessão em vez da intenção de cobrança.

Pode adicionar ou remover cadeias, conforme necessário. Os pontos finais MPP do Quicknode suportam todas as redes compatíveis. Também pode obter dinamicamente a lista completa de slugs compatíveis:

curl https://mpp.quicknode.com/networks

Tenha em atenção que as cadeias que consulta estão dissociadas da rede de pagamentos. A sua sessão é executada na blockchain Tempo (testnet ou mainnet), mas pode aceder a pontos finais RPC em qualquer cadeia suportada.

Configurar a carteira

O script necessita de uma carteira para assinar os comprovativos do canal de pagamento. Pode utilizar uma chave privada já existente no ambiente ou gerar uma nova automaticamente:

importar { gerarChavePrivada, chavePrivadaParaConta } de 'viem/accounts'

const chave privada = (process.env.MPPX_PRIVATE_KEY como `0x${string}`) || gerarChavePrivada()
const conta = chavePrivadaDaConta(chave-privada)

Quando uma chave é gerada automaticamente, o script guarda-a num .env ficheiro (com chmod 600 (permissões) para que as execuções futuras reutilizem a mesma carteira:

import { existsSync, writeFileSync } from 'fs'

if (isGenerated && !existsSync(envPath)) {
  writeFileSync(
    envPath,
    [
      '# Auto-generated by multichain balance checker',
      '# This file is gitignored — never commit private keys.',
      `MPPX_PRIVATE_KEY=${privateKey}`,
      '',
    ].join('\n'),
    { mode: 0o600 },
  )
}

Financiamento através da «Faucet» da Testnet

Para utilização na rede de teste, o script carrega automaticamente a carteira através da fonte de fundos da rede de teste Tempo. Isto atribui à carteira PathUSD (uma stablecoin da rede de teste) e gas na Tempo Moderato (ID da cadeia 42431):

async function fundWallet(address: string): Promise<void> {
  const res = await fetch('https://docs.tempo.xyz/api/faucet', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ address }),
  })
  if (res.ok) {
    console.log('Faucet: Request accepted — waiting for onchain confirmation...')
    await waitForFunding(address)
  }
}

O aguardar financiamento A função consulta o contrato PathUSD na Tempo Moderato para confirmar se o saldo foi creditado antes de prosseguir:

const TEMPO_RPC = 'https://rpc.moderato.tempo.xyz'
const PATHUSD_ADDRESS = '0x20c0000000000000000000000000000000000000'

async function getPathUSDBalance(walletAddress: string): Promise<bigint> {
  const data = '0x70a08231' + walletAddress.slice(2).padStart(64, '0')
  const res = await fetch(TEMPO_RPC, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0', id: 1,
      method: 'eth_call',
      params: [{ to: PATHUSD_ADDRESS, data }, 'latest'],
    }),
  })
  const json = (await res.json()) as { result?: string }
  return BigInt(json.result ?? '0x0')
}

Esta configuração sem complicações significa que qualquer pessoa pode clonar o repositório e executar o script sem ter de se registar em nada nem de recarregar manualmente uma carteira.

informações

O fluxo de sessões MPP da Quicknode utiliza o mesmo bucket do nível gratuito que o x402: 1 000 000 de créditos API por mês por carteira. As solicitações RPC consomem 1 crédito API cada, enquanto o SQL Explorer consome os créditos API utilizados pela consulta. Após esgotar o nível gratuito, mude para uma carteira financiada pela mainnet. Consulte «Passar para a produção».

Criação da sessão e consulta dos saldos

É aqui que se encontra a lógica principal da sessão. O script cria uma sessão MPP com tempo.session(), e, em seguida, percorre cada cadeia, enviando eth_getBalance pedidos efetuados durante a sessão:

import { tempo } from 'mppx/client'

const session = tempo.session({
  account,
  maxDeposit: '1', // 1 PathUSD — covers 100,000 requests at $0.00001/each
})

O maxDeposit Este parâmetro define o orçamento total para o canal de pagamento. O montante que não for gasto será devolvido no final da sessão.

informações

Se o saldo do canal se esgotar a meio da sessão, o mppx O cliente pode recarregar o canal com um depósito adicional na cadeia, sem ter de encerrar e reabrir a sessão. No caso do nosso script de 15 cadeias, mesmo um pequeno depósito é mais do que suficiente, mas isto é útil se estiver a desenvolver aplicações de execução mais prolongada que efetuam milhares de pedidos.

Efetuar chamadas RPC através da sessão

Para cada cadeia, o script chama session.fetch() com um JSON-RPC padrão eth_getBalance carga útil. A sessão gere automaticamente todos os mecanismos do MPP:

const MPP_BASE_URL = 'https://mpp.quicknode.com/session'

for (const chain of CHAINS) {
  const response = await session.fetch(`${MPP_BASE_URL}/${chain.slug}`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 1,
      method: 'eth_getBalance',
      params: [WALLET_ADDRESS, 'latest'],
    }),
  })

  const data = (await response.json()) as { result?: string; error?: { message: string } }
  // Parse hex balance to human-readable format
  const balance = formatBalance(data.result!, chain.decimals)
}

No primeiro pedido, session.fetch() gestiona todo o fluxo de desafio-resposta 402: recebe o desafio, deposita PathUSD no contrato de garantia na cadeia de blocos e volta a tentar com um voucher assinado. Este processo demora cerca de 500 ms.

Em cada pedido subsequente, a sessão limita-se a incrementar o número acumulado do comprovativo e a incluí-lo no Autorização cabeçalho. O servidor verifica o voucher com um único ecrecover operação (sem necessidade de transação na cadeia de blocos), pelo que as respostas são recebidas com custos de pagamento praticamente nulos.

O script também inclui uma tentativa de repetição em caso de respostas 404, para resolver problemas transitórios de encaminhamento do MPP:

if (response.status === 404) {
  response = await session.fetch(`${MPP_BASE_URL}/${chain.slug}`, {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: rpcBody,
  })
}

Formatação do balanço

O eth_getBalance A resposta devolve uma cadeia hexadecimal que representa o saldo em wei (ou na unidade mais pequena equivalente da cadeia). O script converte este valor para um número decimal legível:

import { formatUnits } from 'viem'

function formatBalance(hexBalance: string, decimals: number): string {
  const value = BigInt(hexBalance)
  return parseFloat(formatUnits(value, decimals)).toFixed(4)
}

Encerramento da sessão

Após a conclusão de todas as consultas, o script encerra a sessão para desencadear a liquidação na cadeia de blocos. O servidor liquida o comprovativo cumulativo final e reembolsa o depósito não utilizado para a carteira:

// Capturar os dados da sessão antes de fechar
const channelId = sessão.channelId
const despesaCumulativa = sessão.cumulative

console.registo(«A encerrar a sessão e a efetuar a liquidação na cadeia de blocos...»)
const recibo = await sessão.fechar()

Em seguida, o script apresenta um resumo com o custo total, o montante do reembolso e os detalhes da liquidação:

printSummary(
      resultados,
      totalRequests,
      channelId,
      cumulativeSpend,
      receita?.txHash,
    );

O script também envolve todo o ciclo de consultas num try/catch e tenta encerrar a sessão mesmo em caso de erros, para que o canal de pagamento não permaneça aberto indefinidamente:

try {
  // ... query loop ...
  await session.close()
} catch (err) {
  console.error('Fatal error:', err instanceof Error ? err.message : err)
  try {
    await session.close()
    console.log('Session closed after error.')
  } catch {
    console.log('Could not close session.')
  }
  process.exit(1)
}

Executar o script

Com tudo configurado, execute o script:

# Executar com uma carteira de testnet gerada automaticamente (sem configuração)
npx tsx index.ts

# Ou forneça a sua própria chave privada através de um ficheiro .env
echo "MPPX_PRIVATE_KEY=0x..." > .env
npx tsx --env-file=.env index.ts

Deve ver um resultado semelhante a este:

Verificador de saldo multichain (através de uma sessão MPP)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Carteira:  0x1234...abcd (gerada automaticamente)
Destino:  0xd8dA...6045

 Cadeia            | Saldo               | Estado
──────────────────┼───────────────────────┼──────────
 Ethereum         | 1,2345 ETH            | ok
 Base             | 0,5000 ETH            | ok
 Arbitrum         | 0,0000 ETH            | ok
 Optimism         | 2,1000 ETH            | ok
 Polygon          | 150,0000 POL          | ok
 BNB Chain        | 0,0312 BNB            | ok
 ...              | ...                   | ...

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Resumo da sessão
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 Cadeias consultadas:    15 (15 ok, 0 erros)
 Total de chamadas RPC:   15
 Custo da sessão:      0,000150 PathUSD (0,00015 $)
 Depósito no canal:   1,000000 PathUSD
 Reembolsado:          0,999850 PathUSD
 ID do canal:        0xdef456...abc123
 Transação de liquidação:     0xabc123...def456

Assim que a sessão terminar, poderá verificar a liquidação no explorador de blocos. O Transação de liquidação O hash nos links de saída remete para a transação final na cadeia de blocos. Utilize o explorador da rede de teste para o «Tempo Moderato» ou o explorador da rede principal para séries de produção.

A captura de ecrã abaixo mostra como se apresenta uma transação de liquidação:

A caixa vermelha mostra as duas transferências de saldo associadas ao canal de pagamento: 1 PathUSD enviado para o contrato de garantia aquando da abertura da sessão e 0,99985 PathUSD devolvido como reembolso aquando da liquidação. A caixa laranja mostra o custo real da sessão (0,00015 PathUSD) pago ao servidor como parte da transação de liquidação.

Pode alterar o endereço da carteira que está a ser verificado, editando o WALLET_ADDRESS constante no topo de index.ts:

const WALLET_ADDRESS = '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045' // qualquer endereço

Passagem para a produção

O script utiliza a rede de teste (testnet) por predefinição, para facilitar a integração. Eis o que muda para a utilização em produção:

	Testnet (padrão)	Rede principal
Rede de pagamentos	Tempo Moderato (ID da cadeia 42431)	Rede principal do Tempo (ID da cadeia 4217)
Moeda	PathUSD	PathUSD ou USDC.e
Nível gratuito	1 000 000 de créditos API partilhados por mês por carteira, entre o MPP e o x402	Ilimitado
Financiamento da carteira	Financiamento automático através do «faucet»	É necessário um financiamento manual

Para mudar para a mainnet, forneça uma chave de carteira que contenha PathUSD ou USDC.e na mainnet do Tempo. A mppx O cliente deteta automaticamente os saldos disponíveis e seleciona o método de pagamento adequado a partir do desafio 402.

Ampliar o script

O verificador de saldo é intencionalmente simples, para manter o foco na mecânica da sessão. O ponto importante a reter é o padrão: abrir uma sessão, efetuar várias chamadas RPC em diferentes cadeias, fechar e liquidar. Uma vez que uma única sessão MPP processa pedidos em todos os slugs de rede, é possível alargar o script para chamar qualquer método RPC em qualquer cadeia suportada, sem alterar a configuração da sessão. Por exemplo, poderia adicionar verificações de saldo de tokens ERC-20, trocando eth_getBalance para um eth_call para o contrato do token saldoDe função.

Conclusão

Criou um verificador de saldo multichain que consulta 15 cadeias EVM através de uma única sessão MPP. O padrão-chave a reter: abra um canal de pagamento, efetue quantas chamadas RPC forem necessárias em qualquer combinação de cadeias suportadas utilizando vouchers fora da cadeia e, em seguida, feche e liquide. A sessão tratou de toda a mecânica de pagamento automaticamente, desde o desafio 402 inicial, passando pela assinatura do voucher, até à liquidação final e ao reembolso.

Este padrão aplica-se a qualquer fluxo de trabalho que efetue várias chamadas RPC: ferramentas de acompanhamento de carteiras, scripts de monitorização, pipelines de dados ou agentes de IA que necessitem de ler o estado na cadeia de blocos em várias redes. As sessões permitem que estas ferramentas paguem pelo acesso de forma programática, sem contas nem chaves de API, mantendo simultaneamente os custos de pagamento fora do caminho crítico.

Próximos passos

Para saber mais sobre o MPP, o Tempo e a integração do MPP com o Quicknode, consulte os seguintes recursos:

• Documentação do Protocolo de Pagamentos Automáticos
• Guia de faturação baseada em sessões do MPP
• SDK do mppx no npm
• Referência do protocolo MPP do Quicknode
• Especificação de autenticação de pagamentos da IETF
• Utilizar o MPP com o Foundry e o Tempo (guia complementar para programadores de Solidity)

Perguntas frequentes

O que é o MPP e em que difere da autenticação tradicional por chave API?

O Machine Payments Protocol (MPP) é um padrão aberto que permite efetuar pagamentos em linha em pontos de extremidade HTTP, utilizando o código de estado 402 «Pagamento Necessário». Em vez de criar uma conta e gerir chaves de API, o utilizador paga por cada pedido utilizando stablecoins a partir de uma carteira. Isto permite que scripts, agentes e bots comecem a utilizar APIs imediatamente, sem necessidade de uma configuração de faturação mediada por pessoas.

Quando devo utilizar uma sessão MPP em vez de pagamentos por pedido?

Utilize sessões quando o seu script ou aplicação efetuar várias chamadas RPC numa única execução. As sessões abrem um canal de pagamento na cadeia e utilizam vouchers fora da cadeia para os pedidos subsequentes. A verificação dos vouchers consiste numa verificação de assinatura que depende da CPU e que acrescenta microssegundos de sobrecarga, em comparação com as centenas de milissegundos necessários para pagamentos de encargos na cadeia. Nos pontos finais MPP da Quicknode, as sessões são também significativamente mais económicas por pedido. Se estiver a efetuar menos de 10 pedidos, o pagamento de encargos é mais simples.

Preciso de ter uma conta Quicknode para utilizar os endpoints MPP?

Não. Os endpoints do MPP não requerem conta, chaves API nem registo. Basta ter uma carteira com stablecoins (ou tokens da testnet). O pagamento é efetuado em simultâneo com cada pedido HTTP.

Posso consultar cadeias que não sejam EVM, como a Solana, através de uma sessão MPP?

Os pontos de extremidade MPP da Quicknode suportam a Solana e outras cadeias não EVM. Pode utilizar a mesma instância de sessão para consultar qualquer cadeia suportada, alterando o slug da rede no URL. Por exemplo, utilize /session/solana-mainnet para consultar os pontos de extremidade RPC da Solana através do mesmo canal de pagamento.

O que acontece se o meu script falhar antes de encerrar a sessão?

Se a sessão não for explicitamente encerrada, o canal de pagamento permanece aberto até atingir o tempo limite. O servidor ainda pode liquidar o último voucher que recebeu. Para evitar isso, o script envolve o ciclo de consultas num bloco «try/catch» e tenta encerrar a sessão mesmo em caso de erros.

Como funciona o plano gratuito e como posso migrar para a mainnet?

Os endpoints MPP da Quicknode utilizam o mesmo limite de 1 000 000 de créditos de API por mês por carteira, partilhado com o x402. As solicitações RPC consomem 1 crédito de API cada, enquanto o SQL Explorer consome os créditos de API utilizados pela consulta. Para uma utilização ilimitada, forneça uma carteira com saldo em PathUSD ou USDC.e na mainnet da Tempo (ID da cadeia 4217).

Adoramos ❤️ os vossos comentários!

Diz-nos se tiveres algum comentário ou sugestão de novos temas. Adoraríamos saber a tua opinião.