Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.arcpass.vibepas.xyz/llms.txt

Use this file to discover all available pages before exploring further.

When you create a new wallet on Arc Network, you start with a zero balance. That creates a problem: every transaction on the network requires gas, but you need tokens to pay for gas. ArcPass solves this by acting as a sponsor — it pays the gas cost of your first transaction so you can get started without acquiring tokens from an external source.

The sponsorship flow

Here is what happens from the moment you submit a request to when tokens arrive in your wallet.

1. Register your wallet

Before requesting sponsorship, you register your wallet address with ArcPass. Registration records your address and establishes your eligibility baseline. If your wallet is already registered, the API updates your last-seen timestamp instead of creating a duplicate record.

2. Request sponsorship

You submit your wallet address to the sponsorship endpoint. ArcPass immediately checks three eligibility conditions:
Eligibility requirements — Your wallet must meet all three conditions to receive sponsorship:
  • Your wallet must be registered (exists in the ArcPass registry).
  • Your wallet must not be blocked (blocked wallets are ineligible due to prior abuse).
  • Your wallet must not already have a pending sponsorship request. Duplicate requests within the same session are rejected.
If all three checks pass, ArcPass creates a sponsorship request in pending status and returns the request ID to you immediately.

3. Eligibility check and approval

Once your request is in pending status, the ArcPass relay picks it up. It re-validates your wallet’s eligibility and, if confirmed, transitions the request to approved. If your wallet is found to be blocked or otherwise ineligible at this stage, the request moves to rejected instead — a terminal state with no further transitions.

4. On-chain relay

After approval, the relay broadcasts an on-chain transaction to the Arc Network SponsorVault contract, which transfers native tokens directly to your wallet address. The request status moves to relayed while the transaction is being confirmed on-chain.

5. Completion

Once the on-chain transaction is confirmed, the sponsorship moves to completed. Your wallet now has a non-zero balance and can make transactions independently. If the on-chain transaction fails (for example, due to a network timeout), the request moves to failed and may be retried automatically.

Sponsorship lifecycle states

Every sponsorship request moves through a defined sequence of states. You can poll the status endpoint at any time to see where your request stands.
StateMeaning
pendingRequest received and queued for processing
approvedEligibility confirmed; relay transaction being prepared
relayedOn-chain transaction broadcast; awaiting confirmation
completedTokens delivered to your wallet
rejectedWallet is blocked or ineligible; no further action possible
failedOn-chain transaction failed; may be retried up to the retry limit
The normal path is: pending → approved → relayed → completed
rejected and failed are terminal states. A rejected request cannot be retried. A failed request may be retried automatically by the relay up to the configured maximum, after which it also becomes terminal.

On-chain verification

Every completed sponsorship is recorded by the SponsorshipRegistry contract on Arc Network. This means you can verify any sponsorship independently — you do not have to trust the ArcPass API response alone. The registry exposes an isSponsored() view function that you can call directly from any Arc Network client.

Replay and rate-limit protection

ArcPass applies two layers of protection to keep the service available for genuine new users:
  • Replay protection — Duplicate sponsorship requests from the same wallet and IP address within a 5-second window are rejected automatically.
  • Rate limits — Each IP address and each wallet address has a maximum number of requests allowed per hour. Exceeding the limit blocks further requests temporarily.
These limits do not affect wallets making their first legitimate request. They are designed to prevent automated abuse that would exhaust the sponsorship pool.