Tensor is a Solana based NFT trading platform built for high frequency and programmatic trading. Unlike marketplace aggregators that batch requests through multiple protocols, Tensor operates its own onchain orderbook and automated market maker pools, allowing subminute fills and programmable bid strategies. This article covers the protocol architecture, liquidity models, fee structures, and integration considerations for traders running automated strategies or large volume operations.
Orderbook Architecture and State Management
Tensor maintains an onchain central limit orderbook (CLOB) using Solana’s program derived addresses to store bid and ask orders. Each order is a separate account managed by the Tensor program, indexed by collection, price tier, and expiration timestamp. This differs from Ethereum NFT marketplaces that typically use offchain signatures validated at settlement time.
Orders execute through program instructions that match buyers and sellers, transfer the NFT via Metaplex token metadata, and settle payment in SOL or SPL tokens. The protocol supports collection wide bids (any trait floor) and trait specific bids (filtered by rarity attributes stored in the token metadata). Fill logic prioritizes highest bid first, then earliest timestamp for identical prices.
The onchain structure creates deterministic settlement but consumes more compute units than signature based models. Large orders spanning multiple traits or collections may require transaction splitting to stay within Solana’s compute budget. The protocol does not support partial fills for individual NFTs but does allow batch fills when a single transaction can satisfy multiple orders.
Automated Market Maker Pools
Tensor introduced concentrated liquidity pools for NFT trading, similar to Uniswap V3 mechanics but adapted for discrete assets. Liquidity providers deposit SOL into a pool contract and specify a price curve (linear, exponential, or custom) along with delta parameters that define price steps after each trade.
When a user sells an NFT to the pool, they receive SOL based on the current curve position. The pool’s bid price then decreases by the delta amount. Conversely, when buying from the pool, the ask price increases after each purchase. Pool creators set the starting price, delta, and curve type at initialization. They can also define trait filters to accept only NFTs meeting specific rarity criteria.
Pool positions are tokenized as NFTs themselves, allowing secondary trading of the LP position. This creates liquidity for illiquid pool positions but introduces valuation complexity since the pool’s SOL balance and NFT inventory change dynamically. The pool contract charges a configurable swap fee (typically 0.5% to 2%) that accrues to the LP position.
Fee Model and Royalty Enforcement
Tensor charges a platform fee on each trade, calculated as a percentage of the sale price. The base fee varies by collection volume tier but generally ranges from 0.5% to 1.5%. High volume traders may qualify for reduced fees through a maker/taker model where providing liquidity (posting orders) costs less than taking liquidity (filling existing orders).
Royalty enforcement operates differently than earlier Solana marketplaces. Tensor supports optional creator royalties rather than mandatory enforcement. Collections can register a preferred royalty percentage in the Tensor program, but the protocol does not block zero royalty trades. This policy emerged after Solana ecosystem fragmentation in 2022 when competing marketplaces diverged on royalty enforcement.
Traders building automated systems should verify current royalty expectations for each collection. Some high value collections maintain social enforcement (blocking traders who avoid royalties from community benefits), while others have migrated to onchain mechanisms like Metaplex programmable NFTs that enforce royalties at the token level regardless of marketplace.
Integration Points for Automated Trading
The Tensor TypeScript SDK exposes methods for order creation, cancellation, and monitoring through both REST API and websocket connections. Websocket subscriptions provide real time updates on order fills, new listings, and pool state changes. The SDK handles transaction construction and account derivation but requires the integrator to manage signing and submission.
For high frequency strategies, monitoring Solana’s transaction confirmation status is critical. Orders submitted during network congestion may fail silently if they exceed compute limits or encounter stale account states. The SDK includes retry logic but traders should implement additional confirmation checks before assuming order state changes.
Pool interactions require calculating the expected output amount before submitting the transaction. The SDK provides a getPoolPrice method that returns the current bid/ask based on the pool’s state. However, pool prices can change between simulation and execution if another transaction fills first. Slippage protection requires setting minimum output amounts in the swap instruction.
Worked Example: Trait Sniping with Collection Bids
A trader wants to buy NFTs from a 10,000 supply collection whenever rare trait combinations appear below 50 SOL. The collection has three trait categories (background, accessory, expression) with varying rarity distributions.
The trader deploys two strategies simultaneously. First, they place collection wide bids at 45 SOL, 46 SOL, and 47 SOL to catch floor listings while staying below their target. Second, they run a monitoring script that subscribes to new listings via websocket and filters for their target trait combination (background: sunset, accessory: laser eyes).
When a matching listing appears at 49 SOL, the script constructs a buy transaction using buyNftTransaction from the SDK. The transaction includes the listing account address, buyer token account, and payment amount. Before submission, the script checks that the NFT’s metadata matches the filter criteria (Tensor does not validate trait claims beyond what’s in the token metadata).
The transaction settles in approximately 400 milliseconds. The trader’s collection bids remain active for other opportunities. If the rare trait listing had appeared at 44 SOL, the existing collection bid would have filled automatically without requiring the monitoring script, demonstrating the value of maintaining passive bids alongside active monitoring.
Common Mistakes and Misconfigurations
-
Ignoring compute budget constraints when batching multiple buys or sells in a single transaction. Tensor transactions that interact with multiple pool accounts or complex metadata may exceed default limits. Always simulate transactions before deployment.
-
Not accounting for pool delta in rapid succession trades. Buying three NFTs from the same pool in separate blocks will pay increasing prices. Calculate total cost across the full intended purchase before initiating the sequence.
-
Assuming trait filters are cryptographically enforced. Pool trait filters check against Metaplex metadata JSON but do not verify the JSON matches the actual token rendering. Malicious actors can create metadata mismatches.
-
Setting collection bids without expiration timestamps. Unexpired bids consume rent and may fill at unfavorable prices days or weeks later when market conditions change.
-
Failing to monitor for listing cancellations between API query and transaction submission. A listing that appears available may be canceled before your buy transaction processes, resulting in a failed transaction and wasted fees.
-
Using stale pool price quotes. Pool state changes with every swap. Always fetch current pool state immediately before constructing swap transactions, not from a cached value.
What to Verify Before Relying on This
- Current platform fee tiers and whether your trading volume qualifies for reduced rates
- Royalty percentage and enforcement method for each collection you trade (check both Tensor settings and token program type)
- Compute unit costs for your transaction patterns, especially when interacting with multiple pools or using complex filters
- Websocket subscription limits and reconnection behavior during network congestion periods
- Account rent requirements for limit orders and whether unfilled orders reclaim rent after expiration
- Pool delta and curve parameters before depositing liquidity or executing large swaps
- Token metadata schema version for collections using trait filters (verify the SDK parses attributes correctly)
- Current transaction prioritization fees on Solana during your intended trading hours
- Whether the collection uses Metaplex Token Metadata or a custom standard that may affect trait indexing
- API rate limits if running multiple monitoring instances or high frequency polling strategies
Next Steps
- Simulate your transaction flows on Solana devnet using Tensor’s test environment to measure compute consumption and identify bottlenecks before deploying capital.
- Build monitoring for your active orders and pool positions that alerts on unfilled expirations, unexpected fills, or pool inventory imbalances.
- Establish fallback RPCs and transaction submission endpoints to maintain uptime during Solana network congestion or provider outages.
