Whitepaper | TENDER

Abstract

TENDER is a non-custodial, receive-side settlement rail on Solana.

Conventional payment rails let the sender decide which asset arrives. TENDER inverts that. A receiver publishes an election against an on-chain handle - a basis-point split across eligible assets, summing to 100% - and every inbound payment is converted at receipt and delivered in exactly that mix, atomically, in a single transaction.

The sender does nothing differently: they pay a handle in whatever they already hold. No account is opened, no balance is held, and no TENDER-controlled address ever takes possession of the funds. What changes is the unit of account on the receiving end - and who gets to choose it.

THE ONE-LINE VERSION

Get paid in the assets you'd rather hold, without asking anyone to send them.

The receive side is unowned

Every rail in production optimises the sender. Nobody owns what happens the moment value lands.

CONVERSION BURDEN: A payment arrives in the sender's unit of account. Turning it into what the receiver actually wants to hold is manual, after the fact, and paid for twice - once in spread, once in attention.
TIME EXPOSURE: The gap between receipt and conversion is unhedged exposure to an asset nobody chose to hold. Across a payroll-sized flow, that gap compounds.
POLICY WITHOUT A HOME: Treasury policy - what mix of stables, tokenised equities and commodities to hold - lives in a spreadsheet, not in the rail. Nothing enforces it at the point of receipt.
CUSTODY AS THE DEFAULT FIX: The usual answer is an intermediary that receives on your behalf, converts, then forwards. That solves the mix by reintroducing exactly the counterparty risk the chain removed.

TENDER treats the receive side as the product. The election is the policy, the rail is the enforcement, and settlement is atomic - so there is never a moment where the policy is stated but not yet true.

Design laws

Part 0 of the backend spec isn't a feature list - it's the set of constraints every later decision has to satisfy.

LAW 01 · ELECTION IS LAW: The receiver's election is honoured exactly, atomically, with no custody. A settlement that cannot honour it does not silently approximate it.
LAW 02 · NEVER FILL BADLY: Never fill badly; never strand funds. A leg that breaches its slippage bound safe-settles in USDC with an on-chain notice, rather than taking the fill or failing the payment.
LAW 03 · THE FAST PATH IS FREE: Same-asset payments are a direct transfer. Nothing converts, so the rail adds nothing and charges nothing - zero fee, forever.
LAW 04 · CONSUME THE STANDARD: Consume the handle standard, don't fork it. Identity lives in the on-chain handle registry, so it stays portable outside TENDER.

Architecture

Six components sit between an inbound payment and a receiver's wallet. None of them holds funds.

HANDLE REGISTRY: On-chain identity. Resolves a handle to a receiver wallet and its current election. Standard-consuming, so a handle keeps working independently of TENDER.
ELECTION: A basis-point vector over eligible assets, summing to 100%. Updateable at any time by the handle owner; the version in force at receipt is the one that settles.
UNIVERSE GATE: The eligible-asset registry. Only listed, verified tokenised assets and stablecoins can be elected. Stakers govern what enters the universe.
QUOTE ENGINE: Dual provider - Jupiter Swap API V6 and Relay.link API V2 - producing a best route per leg under a slippage cap.
PRICE SANITY: A Pyth reference band checked before anything is signed. A quote outside the band is rejected rather than executed.
SETTLEMENT: One atomic transaction: N legs swapped and delivered straight to the receiver's wallet. Corporate actions on tokenised assets accrue afterwards through the issuer's Token-2022 Scaled UI multiplier.

  SENDER  ·  SOL / USDC / ANY LISTED SPL
     |
     v
  +-------------------------------------------------+
  |  RESOLVE   handle  ->  election (bps = 10,000)  |
  |  GATE      eligible-asset universe check        |
  |  QUOTE     Jupiter V6  ·  Relay.link V2         |
  |  SANITY    Pyth reference band                  |
  |  EXECUTE   one atomic transaction               |
  +-------------------------------------------------+
     |
     +----------+-----------+-----------------------+
     v          v           v                       v
   60% SPYx   30% USDC   10% GLDx       BREACHING LEG -> USDC
                                         (+ on-chain notice)

FIG. 1 — INBOUND PAYMENT THROUGH THE RAIL

NON-CUSTODIAL BY CONSTRUCTION

There is no step in Fig. 1 where a TENDER-controlled account holds the payment. Custody isn't a policy we promise to keep - it's a state the design never enters.

Settlement lifecycle

Four steps, sub-second finality, and no point at which the payment sits anywhere other than the sender's wallet or the receiver's.

01 · SENDER INITIATES: Pays @handle in any token they already hold. Zero conversion burden on the sender - they never see the election.
02 · ROUTER VALIDATES: Reads the election from the registry and checks every target against the eligible-asset universe.
03 · CONVERSION AT RECEIPT: Best-route quotes per leg, capped for slippage and sanity-checked against the Pyth reference band.
04 · DELIVERY: Elected assets land in the receiver's wallet. Atomic, non-custodial, one transaction.

Splits extend this lifecycle rather than replacing it: one payment resolves to N recipients, and each recipient's share settles against that recipient's own election. Payroll vaults extend it again along the time axis - a funded vault, a roster, a schedule, and a permissionless crank that anyone can trigger once a run is due.

Risk controls

What the rail does when the market, the route, or the wallet doesn't cooperate.

SLIPPAGE CAPS: Every leg carries a bound. A route that cannot fill inside it is not executed at any price.
PRICE SANITY: Quotes are checked against a Pyth reference band before signing, so a thin or manipulated venue cannot define the fill.
SAFE-SETTLE FALLBACK: A breaching leg settles into USDC and emits an on-chain notice. The payment completes; the receiver holds a stable rather than a bad fill or nothing at all.
PARTIAL-PROGRESS PROTECTION: Where a multi-leg settlement needs more than one wallet approval, on-chain progress already made is preserved if a later prompt is declined. Nothing is re-run and nothing is lost.
ELIGIBILITY GATING: Only assets admitted to the universe can be elected, which bounds the issuer and liquidity risk any election is able to express.
NO CUSTODY SURFACE: With no pooled balance and no forwarding account, there is no honeypot to compromise and no withdrawal to halt.

Fee model & value flow

Fees exist only where value is added. Where nothing converts, nothing is charged.

PATH	BASIS	RATE
SAME-ASSET FAST PATH	Nothing converts	0 BPS · FOREVER
CROSS-ASSET SETTLEMENT	Converted volume only	15 BPS · CAPPED ≤ 30 BPS / TX
SPLITS & INVOICES	Routing only	0 BPS
PAYROLL VAULT	Scheduled run	TIERED BY ROSTER
STAKING	Share of protocol fees	EARN · NOT A COST

  CONVERTED VOLUME  ->  PROTOCOL FEE  ->  OPEN-MARKET BUYBACK  ->  STAKER PAY

FIG. 2 — WHERE A BASIS POINT GOES

The fee is taken on converted volume alone and bounded per transaction, so it cannot scale away with a payment that happens to need a long route. What the rail earns flows back through the protocol: an open-market buyback funded by fees, and a share paid to the stakers who secure the parameters and the eligible-asset registry.

Interfaces

A handle is payable from any standard Solana wallet. Everything else is a small REST surface.

  GET   /health                     service status, version, timestamp
  GET   /api/v1/handles/:handle     registration + active election
  POST  /api/v1/handles/election    update target allocation (bps)
  POST  /api/v1/settle/quote        atomic route for an inbound payment

BASE — https://api.tenderrwa.com

Invoices and pay-links are Solana Pay compatible - a QR or link carrying amount, memo and expiry that any standard mobile wallet can pay. The receiver's election is applied on settlement, so a payer needs no TENDER-specific software at all.

Scope & limitations

What this document is not claiming.

INFRASTRUCTURE, NOT A SUITE: TENDER moves assets on instruction. Reporting, withholding and tax obligations remain entirely with the user - it is not payroll, tax, or investment software.
MARKET RISK IS NOT REMOVED: An election expresses exposure to tokenised assets. Issuer, market and liquidity risk sit with the holder, and conversion depends on available on-chain liquidity at the moment of receipt.
DEPLOYED VS. INTENDED: This document describes the rail as built. Anything still ahead of us lives on the roadmap, marked by phase - and the order there is a commitment while the timing is not.
NOT AN OFFER: Nothing in this document is an offer, solicitation or recommendation to buy or sell any asset, nor investment advice of any kind.

The rail,written down.