Frequently Asked Questions

VSmarket is a non-custodial, skill-based challenge protocol. Two players agree on rules (for example “1v1 on FIFA 25, EU-West, PS5”), each escrow a stake from their wallet, then play off-platform on any game or ruleset they choose and agree. The winner posts proof, the loser has a limited time to contest, and the smart contract settles on-chain.

VSmarket is not a betting house, does not create matches for you, and does not hold funds in custody. It is neutral infrastructure: smart contracts + an interface to help you create and resolve challenges.

No. VSmarket is explicitly designed for skill-based challenges, not games of chance. You do not bet on random events, price movements, or spectator predictions. You only stake on your own performance in a competition you directly participate in.

You must not use VSmarket to wager on outcomes that are primarily random or that you do not personally control (e.g. lottery, dice, market prices, sports you are not playing in, etc.).

VSmarket’s challenge features are not intended for users located in jurisdictions where this type of activity is restricted or prohibited by law.

You are responsible for checking the Terms of Use and the laws of your jurisdiction. You must not use VPNs, proxies, or other tools to bypass geo‑restrictions or compliance controls.

There is no traditional “account”. Your wallet address is your identity. You connect a compatible wallet, create or join challenges, and all activity is tied to your on-chain address.

Optionally, you can link an email for notifications (for example: a proof was submitted against one of your challenges, a dispute was opened, or a contest was settled). Email is not required to use the protocol.

VSmarket V1 currently supports Base and USDC only. There is no native ETH staking in this version.

Creating, joining, contesting and finalizing are on-chain transactions. Gas fees are paid in ETH on Base.

Fees, deposits and timing values are read from the smart contract and can evolve over time. However, both the challenge and the resulting contest use snapshot values taken atcreation / match time (e.g. deposit and fee snapshots on the challenge and contest, and a silence-window snapshot applied to the contest).

Always double‑check the chain + token shown in the UI and in your wallet confirmation screen before approving or staking.

On VSmarket we use two main concepts:

• Challenge: the offer created by a player – it defines rules (game, mode, region, platform, stake per side, etc.) and waits for an opponent.
• Contest: the actual match once a challenge has been joined and both players' stake is escrowed on-chain.

A single challenge can lead to exactly one contest in the current 1v1 version. Once matched, that contest is where proof, counter-proof and settlement logic applies.

A challenge can optionally include off-chain metadata that documents the rules and context (game, mode, platform, region, handles, scheduling notes, etc.). The contract stores two fields:

• Metadata hash — an on-chain integrity commitment (a keccak256 hash of a canonical JSON document). If the JSON changes, the hash no longer matches.
• Metadata URI — an optional pointer to where the JSON is hosted (for example an ipfs://…link). The URI can be empty.

Metadata helps participants and reviewers understand what was agreed. It does not decide the winnerby itself — settlement still depends on the proof / counter-proof flow.

VSmarket can generate a one‑time join code that lets you enter a private Discord chat dedicated to a specific challenge. This is useful to coordinate schedules, room codes, rules clarifications, and any logistics.

• Open the challenge details page and use the Discord challenge chat section to generate your code.
• On Discord, go to CHALLENGES → challenge-chat and send the bot: /join <code>.
• The bot will add you to the private thread for that challenge. No wallet ↔ Discord account linking is required.

Treat join codes like a password: share them only with your opponent and do not post them publicly.
Note: these Discord challenge chats are private between participants, but they are also accessible to VSmarket moderators. In the event of a dispute, VSmarket may review relevant messages contextually (together with the proof and counter-proof submitted) and use them as an additional signal to help arbitrate the outcome.

In addition to your stake per side, VSmarket uses a refundable behavior‑bond deposit to discourage griefing and bad-faith disputes. The deposit rate is expressed in basis points (bps) and is sourced from the protocol (smart contract), then snapshotted per challenge so both sides pay the same rate.

• When you create or join a challenge, you escrow stake + deposit on‑chain.
• The deposit rate is snapshotted per challenge at creation time so joiners always pay the same deposit rate as the creator.
• In the happy path (proof submitted, no contest inside the silence window), deposits arefully refunded to both players.
• In disputes, an admin can decide outcomes that may slash deposits for abusive behavior (for example fake proof, bad‑faith contesting, or "match never happened" fraud).

Slashed deposits are sent to the protocol fee recipient address.

When the Creator creates a challenge:

• The Creator’s wallet escrows stake per side + the challenge's deposit into the smart contract.
• The challenge is visible in the marketplace as open until a compatible opponent joins or it is cancelled.

When the Joiner joins:

• The Joiner escrows the same amounts (stake + the same deposit rate snapshotted on the challenge).
• The challenge becomes a contest: total stake = two times the stake per side.
• VSmarket’s fee is taken from the total stake pool when the contest is finalized or resolved by an admin, not from deposits.

You can cancel a challenge if no opponent has joined yet. When you cancel before matching:

• Your stake and deposit are refunded according to the smart-contract rules.

Once another player has joined and a contest exists, there are still contract-native ways to unwind it depending on the situation.

• Mutual resolution (2/2, pre-proof): if the match is cancelled, void, or ends in a draw/tie and no proof has been submitted yet, either participant can propose a mutual resolution. The contest is resolved on-chain only if both participants propose (2/2). Until both sides agree, proof submission remains possible — a single proposal does not block proofs.

If you can’t use mutual resolution (for example because a proof was already submitted, or because you disagree), you have two additional contract-native options:

• Admin cancel (dispute): open a dispute and request an admin resolution of Cancel (no abuse). This splits the net stake and refunds deposits.
• No-proof cancel: if no one submits any proof, after the no-proof window expires anyone can call cancelIfNoProof to split the net stake 50/50 and refund deposits.

In both paths, the protocol fee is taken from the stake pool. Deposits are refunded on these cancellation paths unless an admin explicitly slashes them for abuse in a dispute resolution.

If a contest exists (both sides have escrowed funds) but the match never happens, or one side refuses to cooperate/respond, you can still move the contest toward resolution.

• Collect evidence of non-cooperation (Discord/DM chat logs, invites, timestamps, lobby screenshots, stream VODs, etc.).
• Submit a proof hash anyway: your proof payload can explicitly describe no-show / refusaland link to the evidence. Submitting a proof starts the silence window and is the on-chain trigger required for arbitration.
• If the other player disagrees, they must submit a counter-proof within the silence window. If they do not respond in time, the contest can be finalized via proof-of-silence.
• If they do counter, the contest becomes disputed and an admin can resolve it. Non-cooperation can be treated as abusive behavior and may lead to deposit slashing for the non-cooperative party.

Repeated abuse can lead to access restrictions at the interface layer in addition to on-chain penalties.

After the off‑platform match ends, the self‑declared winner submits a proof hashon‑chain (a keccak256 hash that commits to the exact proof payload referenced in the UI—typically a canonical JSON document that includes a content-addressed URI, such as IPFS). This starts the contest’s silence window (snapshot value stored in the contest).

Proofs are stored as follows: on-chain the contract stores only the hash; the underlying evidence (video, screenshots, logs, etc.) lives off-chain (e.g. IPFS or other storage) and participants should keep a durable copy.

• During the silence window, a counter‑proof hash can be submitted to contest the proof and mark the contest as disputed.
• If nobody contests in time, anyone can call the finalize function to settle on‑chain.

On finalize (no dispute):

• The protocol fee is taken from the total stake (the 2‑player bet pool).
• The net stake is released to the declared winner.
• Both players’ deposits are refunded in full.

This is called Proof of Silence: silence implies acceptance of the submitted proof.

Important: admins can only resolve a contest after a proof is submitted. They also cannot bypassthe silence window — if the contest is still Active, arbitration is only possible once proofTime + silenceWindowhas elapsed.

Mutual resolution is an on-chain agreement between both participants to settle a matched contest as a void/draw before any proof is submitted.

• Either participant can propose a mutual resolution at any time while the contest is active and no proofhas been submitted.
• The contest is resolved on-chain only if both participants propose (2/2).
• If only one side proposes, nothing is finalized and proof/counter-proof remain possible.
• On mutual resolution, the protocol fee is deducted from the stake pool, the remaining net stakeis split 50/50, and both deposits are refunded.

Typical use-cases: agreed draw/tie, match cancelled, null/void match, or a rematch agreed before any proof is posted.

If you believe the submitted proof is incorrect, incomplete, or fraudulent, you must contest it on‑chainwithin the silence window. You can:

• Submit a counter‑proof hash on‑chain (a keccak256 hash committing to your counter‑evidence payload, referenced off‑chain via a content-addressed URI such as IPFS).
• Explain the dispute: rule violation, incomplete match, disconnect, wrong score, identity fraud, etc.

Once a contest is marked as disputed, automatic settlement via proof-of-silence is disabled. Instead, it moves to an admin / governance review flow as described in the Arbitration rules.

Without limitation, proofs or counter-proofs may be considered invalid or abusive when they:

• Are obviously unrelated to the challenge (e.g. different game, different gamertag, wrong date or lobby).
• Are manipulated or edited to misrepresent the score or participants.
• Omit crucial context (e.g. only showing the final score after a disconnect caused by the submitter).
• Are part of a pattern of spam submissions to grief the opponent or delay settlement.
• Demonstrate identity fraud (playing on someone else’s account while claiming to be them).

Submitting bad-faith or falsified proofs can lead to deposit slashing and progressive access restrictions at the interface level.

In a disputed contest (or an active contest that has a proof), a dispute admin can resolve it on‑chain using one of these outcomes:

1. Uphold winner — the original claimant wins the net stake pool; the other player’s deposit may be slashed.
2. Flip winner — the opponent is declared the winner; the original claimant’s deposit may be slashed.
3. Cancel (no abuse) — the net stake is split and both deposits are refunded.
4. Cancel (both abusive) — the net stake is split, and both deposits are slashed.
5. Cancel (only Creator abusive) — the net stake is split; the Creator’s deposit is slashed; the Joiner’s deposit is refunded.
6. Cancel (only Joiner abusive) — the net stake is split; the Joiner’s deposit is slashed; the Creator’s deposit is refunded.

In all cases, the protocol fee is taken from the total stake pool, and deposits are handled separately (refunded or slashed) according to the decision.

If nobody submits any proof, the contest can still be resolved after a timeout.

Each contest snapshots a no‑proof cancel window at match time. If no proof hash is submitted by the timecontestStartedAt + contestMaxNoProofWindow is reached, anyone can call cancelIfNoProof.

• The protocol fee is still taken from the total stake pool.
• The remaining net stake is split 50/50 between both players.
• Both players’ deposits are refunded (this path does not slash deposits).

Tip: still include a clear proof deadline in your challenge rules to avoid ambiguity and disputes — but funds should not be locked indefinitely due to missing proof.

No. At the smart-contract level, only the other participant can contest a proof.

• contestContest requires the caller to be a participant in the contest.
• The caller must be different from the claimed winner.
• It must happen within the silence window after the proof is submitted.

If you see off-platform drama or third-party messages, they can be shared as context for admins, but they do not grant on-chain contest rights.

Over time, VSmarket plans to integrate advanced AI-assisted tooling to help:

• Detect patterns of repeated fraud or exploit attempts.
• Flag suspicious proofs or counter-proofs for deeper human or governance review (e.g. inconsistencies, reused screenshots, mismatched overlays).
• Cluster related disputes and identify high-risk wallets or handles.

AI tools are assistive only: they do not guarantee detection, and final arbitration decisions are made through the human / governance process defined by the protocol and its policies.

VSmarket charges a protocol fee on each settled contest. The exact fee is a feeBps snapshot that is shown in the UI for each challenge/contest. (Current fee: 5.00%)

Example (5% fee):

• Stake per side: 100 units.
• Total stake: 200 units.
• Fee (5% of 200): 10 units.
• Net stake released to the winner: 190 units.

The fee is taken from the total stake pool (the 2‑player stake), not from the deposit. Deposits are refunded (or slashed) separately based on behavior and disputes.

Note: VSmarket does not control Base network congestion, wallet routing, or gas pricing. Gas fees are paid in ETH on Base and may vary depending on demand.

VSmarket provides an experimental view of your PnL. In broad terms:

• Your total staked = sum of all stake per side you committed in contests you participated in.
• Your total prizes = sum of the net stake you won as the declared winner in finished contests (after protocol fees).
• PnL = total prizes − total staked.

Deposits are generally excluded from long-term PnL, assuming they are refunded in normal, non-abusive play patterns. This PnL view is approximate and purely informational; always rely on on-chain data for exact balances.

The leaderboard aggregates public, on-chain contest data and ranks wallets primarily by PnL (and optionally by secondary metrics like number of contests, win-rate or volume).

To keep things usable:

• The UI typically shows a Top N (e.g. top 100 addresses) by default.
• You can load more or search for a specific wallet to jump to a given profile.
• Clicking “View profile” takes you to that address’s detailed stats page.

The leaderboard is based solely on transparent, on-chain outcomes. It cannot be manually edited.

Leaderboard and PnL views are derived from on-chain data; there is no centralized db you can edit. However, users could attempt to:

• Farm volume or contests between multiple addresses they control.
• Arrange "friendly" matches designed only to push PnL up.

While such behavior can distort public rankings, it is expensive (fees + gas + risk of disputes), and can be detected over time by analytics and fraud-detection systems. VSmarket reserves the right to flag or down-rank obvious wash-trading or manipulative patterns in the UI layer.

A profile is just a view over an address. The profile page aggregates:

• Challenges the address created.
• Challenges the address joined.
• Contests, results, and disputes involving that address.
• Experimental PnL and summary stats (wins, losses, etc.).

Anyone can view a public profile by opening /profile?address=0x…, or by clicking “View profile” in the leaderboard or challenge details.

Other users see public, on-chain information related to your address, including:

• Your wallet address (and ENS / username if you choose to set one on the interface).
• Aggregated stats (wins, contests played, etc.).
• Challenge and contest history with high-level status.

Sensitive details (for example, opponent gamertags / handles in some states) are only visible where the protocol deems it safe and consistent with privacy rules (e.g. to participants and admins, not to arbitrary spectators in every state). The exact visibility rules are documented in the Terms and relevant API documentation.

Email is optional and opt-in. If you choose to, you can save an email address in your profile preferences to receive alerts such as:

• A proof has been submitted against one of your contests.
• A counter-proof was filed.
• A dispute was opened or resolved.
• A settlement was executed.

You can change or remove your email at any time from the profile page. Email is never used as your identity; your wallet remains the source of truth.

You are free to use multiple wallets, but each address has its own profile. The protocol does not currently support “merging” histories across addresses.

If you change wallets, your old stats remain on the old address, and the new wallet starts fresh. In the future, governance may introduce optional aliasing or social-linking features, but they will never override the on-chain source of truth.

Yes. VSmarket is designed to be non-custodial:

• All stakes, deposits and payouts flow directly between your wallet and the smart contracts.
• VSmarket does not hold private keys or take direct control of user funds.
• Any interaction you make is initiated and signed from your wallet.

As with any DeFi system, you remain responsible for securing your wallet and verifying contract addresses before signing.

VSmarket is built around pseudonymous wallets. At the protocol level:

• Your public address is your identifier.
• No mandatory KYC is performed by the contracts.

At the interface level, basic telemetry or anti-abuse signals may be collected in line with the Privacy Policy (for example IP logs, device fingerprints, etc.), and third-party tools (wallets, RPCs, IPFS gateways, analytics) will apply their own policies. If and when KYC becomes required in specific jurisdictions, it would be implemented at the interface and access level, not in the protocols themselves.

Compliance note: you must meet the platform’s minimum age requirement (typically 18+, per the Terms of Use) and you are responsible for complying with your local laws and any jurisdictional restrictions.

Key risks include (but are not limited to):

• Smart-contract risk: bugs or vulnerabilities in the deployed contracts could lead to loss or freezing of funds.
• Market/UX risk: opponent not showing up, rage quitting, or abusing dispute rules (mitigated, but not eliminated, by deposits and arbitration).
• Regulatory risk: rules in your jurisdiction may change, and you are responsible for compliance.
• Infrastructure risk: RPC, IPFS, or the underlying chain can experience downtime, congestion or reorgs.

You should read the Risk, Arbitration and Terms of Use pages carefully before using the platform.

No. Transactions on VSmarket are final and irreversible once confirmed on-chain, and all behavior is governed strictly by the smart contracts and arbitration logic.

There are no chargebacks, no manual reversals, and no off-chain refunds beyond what the contracts and arbitration process explicitly allow. You must not use VSmarket if you are not comfortable with this model.

By using VSmarket, you agree that:

• Disputes about contest outcomes are resolved exclusively via the on-chain / protocol arbitration mechanisms.
• Higher-level legal disputes (for example about the platform itself) are governed by the Terms of Use and the Arbitration Rules, including any jurisdiction and venue clauses.

You waive class actions and agree to individual arbitration where specified. Always consult the latest Terms before using the platform.

VSmarket has an emergency pause switch controlled by the owner. When paused, most protocol actions are disabled.

Specifically, pausing disables:

• Create / join / cancel challenge.
• Proof & counter-proof submission.
• Finalize (no-dispute settlement) and no-proof cancel.
• Admin dispute resolution.

If the protocol is paused, you may need to wait until it is unpaused before you can take any on‑chain action.

For privacy and safety, the interface only reveals opponent handles or platform identities where it is:

• Necessary for coordination between participants.
• Consistent with the viewer's role in a challenge (creator, joiner, third-party viewer).
• Allowed by the visibility rules documented in the Terms and APIs.

For example, as a participant you may see your opponent’s handle and profile links, but a random spectator may only see anonymized or aggregated data.

Several reasons can prevent you from joining a challenge:

• The challenge has already been filled and the UI has not refreshed yet.
• Your wallet is on a different network than the challenge’s chain, or you don’t have the required token.
• You are in a restricted jurisdiction for this feature.
• Your wallet or address may be under temporary restriction due to suspected abuse, unresolved disputes or compliance reasons.

In most cases, switching to the correct chain and refreshing the page solves the issue. If not, contact support via the Contact page.

You can explore:

• The Risk page for detailed risk factors and disclaimers.
• The Arbitration page for how disputes are handled and the exact outcomes.
• The Terms of Use for legal framing, jurisdictions and limitations of liability.
• Official docs, repositories or whitepapers linked from the main site (if and when they are published publicly).

If you are a developer, you can also inspect the smart contracts directly on the relevant block explorer.

VSmarket is currently in V1. The VSmarket teams are actively working right now on several protocol improvements for a future V2.

These upgrades aim to make VSmarket more safe, scalable, and decentralized, while also diversifying the options available to challengers (more formats, flows and flexibility).

More information about these evolutions will be communicated in due time, as specifications and rollout plans are finalized.

Have suggestions or ideas? We’d love to hear them — please reach out via the Contact page.

For regular support (UI bugs, UX issues, questions about contests), you can use the Contact page.

For sensitive security issues or potential exploits, please do not disclose publicly at first instance. Use the official security / disclosure channels indicated in the docs or Contact page so that the team can investigate and mitigate responsibly.

A typical end-to-end flow looks like this:

• Match is played off-platform (according to the challenge rules).
• Winner submits a proof hash → this starts the silence window.
• If not contested in time → anyone can finalize → stake is settled (net stake released to the winner) + both deposits refunded.
• If nobody submits any proof → after the no-proof cancel window anyone can cancel → net stake split 50/50 + both deposits refunded.
• If contested → the contest becomes disputed → admin/governance review resolves using the submitted proof + counter-proof.

The protocol supports a no-proof cancel path to prevent funds from being stuck if nobody submits any proof.

When a contest is created (matched), it snapshots a no-proof cancel window. If no proof hash is submitted by the end of that window, anyone can call cancelIfNoProof.

• The fee is still taken from the stake pool.
• The remaining net stake is split 50/50.
• Deposits are refunded to both players.

This window is snapshotted per contest at match time (so it won’t change mid-contest if the default is updated later).

This is normal for ERC‑20 tokens like USDC:

• Transaction #1: Approve — you authorize the VSmarket contract to transfer up to a certain amount of USDC from your wallet.
• Transaction #2: Create / Join — the contract actually transfers USDC and escrows stake + deposit for the challenge/contest.

All on-chain actions cost gas. Gas is paid in ETH on Base, even when you are using USDC.

VSmarket does not control Base network congestion, wallet routing, or gas pricing. If a transaction is slow or expensive, it is usually due to network demand or RPC conditions.

Common causes of “can’t create/join” issues include: insufficient allowance (approve too low), approving the wrong spender, being on the wrong network, or having insufficient ETH for gas.

In rare cases, a token transfer can fail (for example if a token contract blocks transfers to a specific address). When that happens, VSmarket uses a push + pull fallback.

• If a transfer fails, the amount becomes claimable for your address instead of being lost.
• You can then call claim(token) to pull the funds to your wallet.

The UI can expose a “Claim” button when it detects a positive claimable balance.

VSmarket separates integrity on-chain from media off-chain:

• On-chain (smart contract): only a hash is stored (proof hash / counter-proof hash).
• Off-chain (evidence): the actual files (video, images, logs) live off-chain (e.g. IPFS or another storage location).

The hash is what provides tamper-evidence: if the file changes, the hash no longer matches.

The interface may also store or reference a URI (for example an IPFS link) to help users retrieve the underlying media later. The on-chain hash remains the source of integrity: reviewers can re-hash the content and confirm it matches what was committed on-chain.

Best practice: keep a local copy of your evidence, and use stable links (or content-addressed storage like IPFS) so you can always re-provide the proof if needed.

Proof should be strong enough for a neutral reviewer to confirm the result against the challenge rules.

• Show both participants/handles (or clear identity signals) and the final result.
• Include enough context (match/lobby screens, round scores for Bo3/Bo5, timestamps where relevant).
• Prefer continuous video or unedited capture when possible.
• Proof uploads are limited to 50 MB per file (limit enforced server-side; the UI displays it for convenience).

Examples of weak proof include: heavy crops that hide handles, edited/montaged screenshots, missing context (only a final score with no lobby/participants), or mismatched game/mode/date.

After a challenge is matched (a contest exists), you can only unwind it through the settlement paths supported by the smart contract.

If you and your opponent agree to void the match (draw/tie, cancelled match, invalid lobby, rematch accepted, etc.), the simplest option is:

• Mutual resolution (2/2, pre-proof): before any proof is submitted, either participant can propose a mutual resolution. The contest is resolved on-chain only if both participants propose (2/2). If only one side proposes, nothing is finalized and a proof is still submitable.

If mutual resolution is not available (proof already submitted) or if you disagree, the other contract-native ways to settle are:

• Admin cancel (dispute): submit a proof (even if it states “void/cancelled”), then open a dispute so an admin can resolve with Cancel (no abuse) (net stake split, deposits refunded).
• No-proof cancel: if nobody submits any proof, after the no-proof cancel window anyone can callcancelIfNoProof (fee taken from stake pool, net stake split 50/50, deposits refunded).

Note: mutual resolution is an opt-in 2/2 path. It’s useful for clean draw/void cases because it settles immediately once both players agree, without waiting for the no-proof timeout.

It depends strictly on the challenge rules. VSmarket does not invent match rules for you.

To avoid disputes, we recommend specifying in the challenge description:

• Disconnect rules (who wins, replay conditions, proof requirements).
• Draw rules (rematch, tie-breaker, or allowed outcomes).
• Rematch rules and how many attempts are allowed.
• Timeouts / pauses and what counts as a forfeit.

The challenge’s rules are the reference point. If a patch changes gameplay or settings in a way that violates the agreed rules, it can be treated as a rules violation.

In disputes, patch-related inconsistencies can be used as part of a proof/counter-proof narrative.

Only the challenge rules matter. DMs/Discord can help coordinate, but they cannot unilaterally change the challenge terms.

If an opponent attempts to change rules after matching and then claims a win based on the new rules, that is aviolation and can be raised via counter-proof.

In normal use, you should not be able to join your own challenge as the opponent.

If you ever believe you found a way to self-match (or otherwise bypass intended restrictions), treat it as a potential exploit and report it via the Contact page.

The leaderboard and PnL are derived from on-chain outcomes. “Classic collusion” (two wallets controlled by the same person) does not create net value — fees, gas, and the risk of disputes make it economically unattractive.

That said, collusion can still distort rankings (e.g. farming volume). Over time, such patterns can be flagged and down-ranked in the UI, and abusive behavior can lead to restrictions.

Today, dispute resolution is handled by VSmarket/admin operators to keep the system fast and consistent while the protocol matures.

• Goal: rapid, consistent decisions and strong anti-fraud enforcement.
• Inputs: submitted proof + counter-proof, plus contextual signals where allowed by policy.

The governance model may evolve over time (e.g. broader governance or delegated arbitration), but any such changes would be communicated via official updates and documented rules.

• Wrong network: switch your wallet to Base and refresh the page.
• Insufficient USDC: you need enough USDC for stake + deposit.
• Insufficient ETH for gas: you need ETH on Base to pay transaction fees.
• Allowance not set / too low: submit an Approve transaction (and ensure it targets the correct contract/spender).
• Pending tx stuck: check your wallet’s pending queue; you may need to wait, speed up, or cancel depending on the wallet and nonce behavior. RPC congestion can also delay propagation.
• UI not refreshed: hard refresh, reload the feed, or wait a few seconds for indexing.