Finvesta execution layer · Chain 369

Making DeFi
Fun Again.

Opening a verified PulseChain read session…

Preparing registry0 / 16
PulseChain RPCVerifying
Native PLSWaiting
Asset registry0 settled

Token metadata is resolved directly from PulseChain. No wallet connection or approval is requested during startup.

FINVESTAV3 · PULSECHAIN

Finvesta execution layer

Swap with
clarity.

One deliberate path from intent to settlement. Live pool discovery, allowance checks, protected minimums, and a wallet-backed simulation before any swap reaches PulseChain.

PulseChain · Chain 369

Swap assets

POOL SPOT
YOU PAYBalance —
Enter a PRC-20 amount
YOU RECEIVEBalance —
0
Waiting for token pair
Spot output is indicative until the connected wallet simulates the router call. The protected minimum is derived only from that simulation.

Seamless swap transition map

From signal to
settlement.

01

PAIR

Resolve token metadata and discover every enabled V3 pool.

02

FUND

Use native PLS directly for WPLS routes, or approve a PRC-20 only when required.

03

SIMULATE

Call the router without state changes using the connected wallet context.

04

PROTECT

Apply slippage and deadline safeguards to the simulated output.

05

SETTLE

Wrap input PLS or unwrap output WPLS atomically, then confirm on PulseChain.

V3 liquidity positions

Liquidity,
under control.

Pool intelligence first. NFT controls when you need them. Compare net LP APR, TVL, and volume once per pool. Connect a wallet to reveal only your positions inside each pool or manage them in dedicated tabs.

MY POSITION NFTSConnect a wallet to scan
MY ACTIVE POSITIONSFunded NFTs, including out-of-range positions
COMBINED TVLEstimated current LP principal

Concentrated liquidity

Your positions

Loading pool intelligence

APR, TVL, and volume arrive through the independent Finvesta analytics API. A wallet is not required.

Position lifecycle map

Capital stays
legible.

01

DISCOVER

Read NFT tokens, tier, range, and pool state on chain.

02

DIAGNOSE

Compare the current pool price with the position’s active range.

03

PREVIEW

Statically simulate collection, increase, or removal parameters.

04

REVIEW

Expose exact amounts, minimums, deadline, and target contract.

05

MANAGE

Submit only after an explicit wallet confirmation.

Protocol fees

NO ADDITIONAL TRADER FEE

One pool fee.
Transparent split.

Protocol Fee: Up to 40% of the existing pool swap fee may be allocated to the protocol treasury to fund automated recursive treasury operations. The remaining 60% is distributed to liquidity providers. No additional fee is charged to traders.

Full allocation disclosure

Protocol Fee Transparency

Certain liquidity pools may allocate up to 40% of the selected swap fee to the protocol treasury, with the remaining 60% distributed to liquidity providers.

This does not increase the fee paid by traders. Every pool continues to charge only its configured fee tier. This build checks the factory's enabled 0.01%, 0.05%, 0.25%, 0.30%, and 1.00% candidates and uses only tiers confirmed live on chain. The protocol fee is simply a distribution of that existing fee after each swap.

Recursive operations

From fee to bot treasury

The protocol's share is routed to the bot treasury, where it can be deployed to execute automated protocol operations designed to create positive recursive value loops. Depending on protocol configuration, treasury activity may include liquidity support, treasury growth, buyback strategies, ecosystem incentives, reserve management, and other sustainability-focused operations.

Liquidity supportTreasury growthBuyback strategiesEcosystem incentivesReserve managementSustainability operations

For clarity

Fee-tier allocation

Maximum protocol allocation shown
Allocation of each pool's existing swap fee
Pool fee tierProtocolLiquidity providers
0.01%0.004%0.006%
0.05%0.020%0.030%
0.25%0.100%0.150%
0.30%0.120%0.180%
1.00%0.400%0.600%

The pool's configured fee remains unchanged. The table shows the split when the protocol allocation is set to its maximum 40%.

Existing fee.
No new charge.

The protocol fee is not an additional charge. It is a transparent allocation of a portion of the pool's existing swap fee to help fund automated protocol operations intended to strengthen the long-term sustainability and functionality of the ecosystem.

Deployed infrastructure

Contract registry

Reference addresses and live deployment status for the configured contracts. Factory source and compiler metadata are publicly available through Sourcify.

Technical & security documentation

Trust through
verification.

Finvesta Eco Exchange is a self-custodial, browser-executed V3 interface for PulseChain. This page documents the production constants, wallet and transaction boundaries, external read services, administrative controls, and safeguards implemented by this single-file DApp.

SELF-CUSTODIALCHAIN 369NO TRANSACTION RELAYEXPLICIT WALLET APPROVAL
INTERFACEStatic single-file clientInline UI, embedded ethers and WalletConnect runtimes, and local calldata construction.
NETWORKPulseChain · Chain ID 369Wallet network and read-RPC freshness are verified before signing flows.
CUSTODYNo operator custodyThe interface does not hold user keys or operate a custodial account system.
SIGNINGBrowser or WalletConnect providerWallet access begins only after the user chooses a connection method.
SETTLEMENTDirect to published contractsNo server-side signer or transaction-relay endpoint participates.
PUBLIC DATARPC + read-only APIsPool analytics and market references are external display inputs, not signing authorities.

01 · Scope & architecture

What this DApp is—and is not

The security boundary separates public reads, local transaction construction, wallet authorization, and on-chain settlement.

Browser client

The exchange UI, ABI fragments, chain configuration, contract addresses, validation logic, ethers 6.17.0, and the pinned WalletConnect connector runtime are delivered in this HTML file. No remote JavaScript or stylesheet is loaded by the DApp.

Read plane

Selected PulseChain JSON-RPC endpoints provide chain state. The production default analytics-api.finvesta.eco/v1 supplies read-only pool analytics. Semantically invalid or unavailable API snapshots fall back to the public Finvesta Goldsky subgraph plus independent DEX Screener token prices; unavailable fields remain visibly unavailable.

Authorization plane

A user-selected injected wallet or WalletConnect session supplies the EIP-1193 account and signer. EIP-6963 discovery may announce browser wallets, while WalletConnect is initialized only after its option is clicked. eth_requestAccounts follows that explicit choice.

Settlement plane

Approvals and state-changing calls go from the selected wallet to the reviewed token, router, position manager, or factory contract. The hosting origin does not sign, relay, batch, or custody transactions for users.

Precise backend statement: no Finvesta backend participates in authentication, custody, calldata construction, signing, or transaction relay. WalletConnect may transport an encrypted pairing/session request between this browser and the selected wallet, but the wallet remains the authorization boundary. A read-only analytics service supplies public pool metrics and does not construct transaction calldata.

02 · Production registry

Configured contracts and authority

All addresses below are hardcoded and normalized before use. Flow-specific checks verify relevant relationships immediately before a wallet prompt.

Finvesta production contract registry
ComponentAddressRole and evidence
Deployment coordinator0x75990a83Fec22e278825445202A34852BB7a6CE4Deployment topology and ownership reads. Explorer ↗
Pool deployer0x3a6d7f6cEd61fa5678EC624dE3a8bcde532ce630Factory-authorized V3 pool deployment. Explorer ↗
V3 factory0x7f5c7C5144b4B4c6e954A5b2D75C318C5467EFDcPool registry, enabled fee tiers, owner, and protocol configuration. Verified source ↗
Position descriptor0x93d0E663FD9da813e7D0F75095c964EbD60711a3LP NFT metadata support. Explorer ↗
Position manager0xEdab52594aF0763502A9D5b4975854BBbd5e9e08Pool initialization, LP NFT mint/increase/decrease/collect/burn, WPLS wrapping, and residual native refund. Explorer ↗
Swap router0x02111F79b8fd68f76cc616214fe7662f93273FEFDirect exactInputSingle swaps and native PLS/WPLS settlement multicalls. Explorer ↗
WPLS0xA1077a294dDE1B09bB078844df40758a5D0f9a27Canonical wrapped asset used for native PLS pool routes. Explorer ↗
Admin EOA0x369418f70ccE4D4FeE21934CB7a13CD009C59888Frontend gate for factory-owner controls; the factory contract remains the authoritative access-control boundary.

Factory source and compiler metadata are publicly verified through Sourcify, allowing reviewers to compare the published source with the deployed bytecode. Other registry entries link to their live PulseChain deployment records.

03 · User-authorized actions

What the interface can request

The application implements direct single-pool V3 execution, LP NFT management, and owner-restricted configuration. It contains no arbitrary destination or generic transaction composer.

Wallet action and authorization matrix
ActionTarget / spenderRecipient, authority, and protection
Connect / switch networkSelected EIP-1193 wallet providerAccount access follows an explicit browser-wallet or WalletConnect choice. Injected-wallet switching/addition targets PulseChain 0x171; WalletConnect requests eip155:369.
Swap approvalSelected token → fixed routerExact input amount by default. Unlimited allowance is an explicit advanced setting. The spender and allowance are shown before the wallet prompt.
Direct swapFixed routerRecipient is the connected account. For native output, the router temporarily receives WPLS only so the same multicall can unwrap and deliver PLS to that account.
Create pool / mint LPFixed position managerThe connected account is the LP NFT recipient. A new starting price is shown and reviewed before initialization.
Increase liquiditySelected tokens → fixed position managerNFT ownership, balances, allowances, range ratio, minimum amounts, and deadline are rechecked.
Collect feesFixed position managerCollection recipient is the connected NFT owner. The claimable amounts are refreshed before submission.
Decrease / withdrawFixed position manager multicallProtected decrease and collection settle to the connected owner. Ownership is checked before review and again before prompt.
Claim & compoundFixed manager + optional fixed routerFees first enter the user's wallet; an optional reviewed balancing swap may follow before a reviewed liquidity increase. Recovery state prevents silent duplicate progression.
Burn empty LP NFTFixed position managerAllowed only for the connected owner after zero liquidity and no-collectible-fee conditions are verified.
Dropped-nonce recoveryConnected account → itselfA compound-recovery flow may offer an explicitly reviewed zero-value self-transfer at one exact nonce to cancel a dropped journaled transaction.
Factory administrationFixed factoryOnly the configured EOA after live factory-owner verification. Calls are limited to pool protocol fee and distribution configuration exposed by the fixed ABI.

04 · Transaction lifecycle

From intent to receipt

Every state-changing path is designed around a visible review and an explicit wallet decision.

01

INTENT

The user selects tokens, amounts, range, position, or owner parameters.

02

VERIFY

Account, chain, contract relationship, ownership, balance, allowance, and current state are checked as applicable.

03

SIMULATE

A static call and gas estimate test the concrete contract method without changing state.

04

REVIEW

Target, spender, recipient, amounts, minimums, deadline, native value, and purpose are exposed before confirmation.

05

SETTLE

The wallet submits only after approval; the interface waits for a PulseChain receipt and refreshes read state.

Coverage boundary: exact submitted-calldata/target/value and replacement-transaction verification is strongest in position-management and compound-recovery paths. Ordinary swaps, swap approvals, new-position mints, and admin writes rely on fresh pre-prompt validation, the wallet's own transaction review, and receipt handling rather than the same uniform post-confirm identity checker.

05 · Defensive controls

Client-side safeguards

These checks are defense in depth. Contract authorization and the user's wallet remain the final enforcement layers.

Configuration

  • Chain ID, core contracts, WPLS, admin EOA, ABI fragments, and candidate fee tiers are fixed in source.
  • Startup requires fresh Chain 369 state and nonempty factory/position-manager bytecode.
  • Router/factory/WPLS/pool relationships are re-read where relevant to a transaction flow.

Wallet & network

  • Connection follows explicit EIP-6963, legacy-provider, or WalletConnect selection.
  • WalletConnect requests PulseChain 369 and eth_sendTransaction; QR, mobile/deep-link, and temporary copy-code pairing are available only after selection.
  • On screens up to 900px wide, compact pairing CTAs keep the wallet list unobstructed and reopen the same live code or QR view without creating a second pairing request. The visible cancel control expires the pending proposal and clears the pairing so another attempt can start without reloading the DApp.
  • On wider screens, dismissing the WalletConnect modal, desktop code helper, or its overlay/Escape route performs the same targeted cancellation. Intentional mobile code and QR transitions preserve the live pairing.
  • Automatic reconnection, email/social login, swaps, on-ramp, send/receive, history, and connector analytics features are disabled.
  • Malformed or duplicate browser-wallet announcements are ignored, and before signing the read RPC and wallet provider must be within 24 blocks.

Intent invalidation

  • Account, chain, route, amount, range, RPC, or modal changes invalidate affected snapshots.
  • Signer address must match the reviewed account and intended recipient.
  • Broadcast status remains visible when an account changes after submission.

Amounts & time

  • Protected output and LP minimums derive from static simulation and the selected slippage setting.
  • Deadlines derive from the latest on-chain block timestamp.
  • Balances and allowances are refreshed immediately before sensitive prompts.

Native PLS

  • Native value is capped to the reviewed input or WPLS desired amount.
  • A conservative gas reserve includes a 20% buffer.
  • Wrapping, unwrapping, and residual refunds occur atomically through fixed router/manager methods.

LP positions

  • Manager, pool registration, NFT ownership, token order, fee tier, and range context are checked.
  • Pending compound stages are journaled with public nonces and hashes for recovery.
  • Browser locks serialize protected compound wallet actions across tabs when supported.

06 · Data, storage & privacy

No secret collection

The DApp has no user-account database, cookie authentication, seed-phrase form, private-key form, password field, message-signature flow, server-side signer, or transaction relay.

Stored locally in the browser

  • RPC preference and last healthy preset.
  • Imported token contract addresses.
  • Slippage, deadline, and unlimited-approval preference.
  • Validated token-logo cache.
  • A validated last-good public pool-analytics snapshot for up to six hours, used only when both live analytics paths fail and always labeled as saved data.
  • WalletConnect pairing/session metadata after that transport is explicitly selected. This DApp helper holds its raw wc: copy only in memory during the active attempt and clears it when pairing settles or is canceled.
  • Public compound-recovery state: account, NFT/pool/token addresses, amounts, stages, nonces, deadlines, and transaction hashes.

Not stored by this client

  • Seed phrases, private keys, keystore files, passwords, or wallet credentials.
  • Custodial balances or Finvesta account-login sessions.
  • Server-issued auth tokens or cookies.
  • Automatic approvals, signatures, or transaction authorizations.
External request inventory
External interfacePurposePrivacy boundary
PulseChain JSON-RPCBlocks, bytecode, contract reads, balances, allowances, logs, simulations, and receipts.After connection, RPC operators can observe queried public account and contract addresses. Custom endpoints must use HTTPS and cannot embed credentials.
Browser walletAccount, chain, signer, gas context, prompts, and transaction broadcast.The wallet—not this site—holds keys and displays the final authorization prompt.
WalletConnect / ReownQR, mobile/deep-link, or copied-code pairing and encrypted session transport.The connector relay carries session messages; the selected wallet holds keys and presents the transaction prompt. The DApp never sends a seed phrase or private key through this transport.
Finvesta analytics APIPublic pool TVL, volume, fee, and estimated APR display.Requests omit browser credentials. Analytics output does not set transaction amounts, recipients, spenders, or calldata.
Finvesta Goldsky subgraphDirect public pool registry and token-denominated hourly TVL, volume, and fee fallback.Used only when the primary analytics snapshot is unavailable or semantically invalid. Requests omit browser credentials.
DEX Screener API/CDNMarket references, exact-pool TVL, USD valuation, and allowlisted token logos.Requests omit browser credentials. Token and pool addresses are public. Market data is treated as advisory and refreshed before a new-pool price prompt.

07 · Untrusted inputs

Validation and rendering boundaries

Token contracts, wallet providers, RPC responses, URLs, browser storage, and external APIs can all return hostile or malformed data.

Token metadata

Imported addresses are checksum-normalized, bytecode and decimals are required, control characters are stripped, and name/symbol lengths are capped. Dynamic text is escaped or assigned with textContent.

Images & links

Discovered logo URLs must use HTTPS on DEX Screener domains. Links to explorers and markets are constructed from normalized addresses and use noopener noreferrer.

Shared URLs

Only token addresses, amount, and native/WPLS settlement intent are restored. Addresses and decimal input are validated, and a shared link never connects a wallet or submits a transaction.

RPC responses

Chain ID, latest-block shape and freshness, timestamp skew, and required bytecode are checked. The app automatically tries preset fallbacks and permits a validated custom HTTPS endpoint.

Market references

Thin markets are labeled. A DEX Screener price chosen for new-pool initialization is refreshed during review and immediately before signing; movement above 2% aborts the flow.

Analytics

APR, TVL, volume, and USD estimates are informational. They do not alter router calldata, position-manager calldata, approvals, recipients, protected minimums, or deadlines.

08 · Administrative controls

Owner actions are verified on chain

The interface verifies live contract ownership and state before presenting an owner action; the factory contract remains the final authorization layer.

Pool protocol fee

The owner may set token0 and token1 protocol shares for a factory-registered pool, subject to deployed contract rules. The client checks pool bytecode, factory, token ordering, fee tier, registration, current packed setting, and owner before simulation and submission.

Treasury & buyback distribution

The owner may configure distribution recipients and basis-point shares exposed by the factory ABI. The client validates addresses and totals, re-reads the current configuration, simulates, estimates gas, and requires a wallet confirmation.

On-chain authority: the factory owner is the role authorized to manage the settings described above and to transfer ownership where the contracts permit it. Before presenting an administrative transaction, the interface reads the live owner, pool protocol fee, and distribution state directly from PulseChain.

09 · Embedded runtime

Locally bundled and version checked

The wallet runtime and application logic are delivered together in this static file for transparent inspection and predictable execution.

Local runtime

  • ethers 6.17.0, @reown/appkit-universal-connector 1.8.23, and WalletConnect Universal Provider 2.23.7 are embedded rather than loaded from a third-party script host.
  • The application checks the exposed ethers and connector versions before making wallet options available.
  • The production client loads no remote JavaScript or stylesheet dependency. The explicitly selected WalletConnect transport still communicates with its relay and wallet-discovery services at runtime.

Runtime verification

  • The embedded WalletConnect connector bundle SHA-256 is f29d67f7296e20192a42f7f8d65dc4cc58ac4d0d63e66d20d56d983463a6ee6d.
  • Application configuration and ABI fragments are included directly in the same file.
  • Connector email/social login, swap, on-ramp, send/receive, history, analytics, automatic reconnection, and unsupported-chain flows are disabled.
Bundled-library scope: the full upstream ethers distribution contains generic wallet, mnemonic, keystore, and key-management utilities. The Finvesta application code does not invoke those utilities or expose any form that accepts wallet secrets; it uses provider, contract, ABI, address, unit-conversion, hashing, and math functionality.
Deployment configuration: the production DApp origin must be allowlisted for this WalletConnect project, and the hosting Content Security Policy must permit the required Reown/WalletConnect HTTPS and WSS pairing endpoints. Those endpoints provide wallet discovery and encrypted session transport; they do not supply the DApp JavaScript.

10 · Architecture scope

Established V3 mechanics

Finvesta Exchange combines a familiar concentrated-liquidity design with client-side verification tailored to this PulseChain deployment.

Uniswap V3 lineage

Finvesta Exchange is a Uniswap V3 fork based on the V3 implementation used by LibertySwap.finance, adapted for the published Finvesta contracts on PulseChain. The production factory source and compiler metadata are publicly verified through Sourcify.

Token compatibility

The interface is designed for standard PRC-20 behavior. Fee-on-transfer, rebase, restrictive, or otherwise nonstandard tokens may be incompatible with some V3 swap and liquidity flows.

Wallet & RPC checks

Wallets authorize transactions and RPC endpoints provide public chain state. The interface checks Chain 369, block freshness, required contract relationships, and the wallet/read-provider block gap before sensitive actions.

Market references

DEX Screener and Finvesta analytics provide informational pricing, TVL, volume, and APR references. Transaction recipients, spenders, protected minimums, and deadlines are derived independently from wallet and on-chain context.

Direct V3 execution

Swaps use direct, single-pool V3 routes selected from fee tiers confirmed enabled by the factory. The interface does not present these routes as aggregator routing.

11 · Public verification

Published project resources

These links connect the official project surface with the verified production factory source and deployment metadata.

Verification scope: the factory's published source, compiler metadata, and configured address can be compared directly with the production DApp constants documented on this page.