Written by: Candy@TEDAO
Introduction | Can the 'Commercial Ledger' Behind Transactions Be Made Public?
In the DeFi world, every transaction is recorded on an immutable public ledger that anyone can audit. We are used to seeing every swap on decentralized exchanges like Uniswap, but the information often stops at the level of 'this transaction has occurred.'
Where does this transaction come from? Which KOL recommended it, or was it brought by a certain trading tool? For a long time, such attribution has relied on internal project systems or centralized back-end processing, known as the 'growth black box': the transaction itself can be verified on-chain, but promotion sources are often counted off-chain. This is not accidental but a consideration of technology and cost—adding extra identifiers to each transaction on Ethereum and other mainnets would significantly increase gas fees and may also pose security challenges, leading many projects to choose to store 'commercial ledgers' off-chain.
Hyperliquid is a decentralized trading platform operating on a self-developed underlying blockchain network (self-researched L1), where users can trade perpetual contracts. Unlike other platforms, it chooses to make key business data and trading logic public on-chain, achieving comprehensive transparency from financial transactions to growth attribution, making the exchange's 'back-end' more intuitively present as a traceable growth map.
I | Public 'Commercial Ledger': See Where Growth Comes From
Hyperliquid's data dashboard (provided by third-party data analysis platform Allium) functions like a real-time 'war room.' It not only shows macro trends, but also reveals who (wallet address) is using which tool and when to drive market changes. The approach is to structure source information into the protocol path, first clarifying two dimensions:
Builder (Order Level): Recording the tools used for placing orders in the order parameters (like the builder field). This allows for comparison of transactions, fees, and retention by tool and for source attribution.
Referral (Account Level): Binding 'who referred you' on the account side, with discounts and commissions settled on-chain according to protocol rules. This allows for on-chain settlement and verification of promotional additions and transactions against official/third-party panels, facilitating budget and ROI assessments.
Figure 1: Hyperliquid Ecosystem Overview provided by Allium. Data source: Allium: https://hyperliquid.allium.so/
Simplified example: How to connect transactions with growth?
Scenario A (Builder | Order Level)
Trader Bob places an order using developer David's 'TradePro' tool, and the order carries David's address (builder parameter); the protocol automatically records that address and the corresponding fees on-chain and completes revenue sharing according to the rules.
Scenario B (Referral | Account Level)
Trader Alice registers through KOL Emma's referral code, establishing a verifiable referral binding on-chain between Alice's account and Emma; thereafter, Alice's every transaction enjoys a fee discount, and the system automatically calculates discounts at the account level and allocates commissions to Emma.
Figure 2&3: Overview of Revenue and User Growth of Different Builders and Referrals. Data source: Allium
II | When Growth Contribution Becomes Trustless
When 'growth attribution' moves from off-chain to on-chain, the entire value chain changes—let's look at it from the three dimensions of rules, settlement, and data:
1. Rules: From 'Variable Interpretation' to 'Protocol Layer Rules'
Critical logic is solidified into contracts, executed collectively by the network; using code constraints instead of temporary interpretations enhances the neutrality and predictability of rules.
2. Settlement: From 'Manual Approval' to 'Automatic Clearing'
Taking Builder (Order Level) as an example: Users first set a 'Maximum Fee Authorization' (ApproveBuilderFee) for the developer's address, and each subsequent order carries the builder parameter. The protocol completes revenue sharing and settlement on-chain without any manual intervention.
3. Data: From 'Promotional Reports' to 'Traceable Ledgers'
All key actions—placing orders, canceling orders, liquidations, discount applications—are recorded on-chain, allowing anyone to independently verify in the public ledger without just listening to promotions.
This brings direct impacts:
For developers (Builder) and promoters (Referral): Returning to contribution itself
Automatic settlement based on on-chain contributions, not relying on relationships or offline statistics; value creation is visible. Outstanding developers and promoters can 'vote with code' rather than 'lobby with PPT.'
On Project Operation and DAO Governance: From Subjective to Data Consensus
Making decisions around unified metrics (e.g., 'promoter contribution × retention × ARPU') and discussing cost reduction.
For example, the 'Builder User Retention Rate' dashboard can show the differences in user quality brought by different tools: some attract users aggressively but have high next-week churn; others attract fewer users but have steady retention, making incentive directions clearer.
Figure 4: Builder User Retention Rate Dashboard, tracking new customers and subsequent retention weekly. Data source: Allium
For ordinary traders: Using facts to cut through the noise
Can independently identify 'who is leading, which tools are effective', and is less affected by pump and dump schemes and opaque information.
III | The Price of Transparency and the Boundaries of Privacy
However, any technological paradigm is a double-edged sword. When transparency is pushed to the extreme, new risks and challenges also arise:
Strategy leakage and Alpha decay: The evaporation of trade secrets
For professional traders and developers, once their trading patterns and tool logic are clearly tracked, their profit Alpha is exposed to scrutiny and may be easily copied and imitated, leading to rapid strategy failure.
Precise targeting and market manipulation: A transparent hunting ground
The intentions behind large transactions become apparent, which may lead to malicious following or being exploited by competitors using position information, increasing the risks of large capital operations.
Financial privacy spillover: Public 'wealth exposure'
Users' trading histories and profit and loss (PnL) status are fully public, for example, ecosystem dashboards (like Allium) aggregate liquidation events to form rankings; but this also exposes addresses and nominal losses, which may attract hackers, phishing, or even offline security threats.
Figure 5: Liquidation Leaderboard, displaying addresses that have been liquidated and their losses. Data source: Allium
Solutions on the Way
To address these risks, the industry has turned its attention to verifiable privacy technologies represented by zero-knowledge proofs (ZKP). Its core goal is to prove to the protocol that a certain contribution was indeed generated by a specific promoter or tool without disclosing the trader's identity or strategy details, and to complete on-chain settlement based on this.
This path provides a clear technical direction towards achieving an ideal state of 'verifiable yet protective.' However, challenges in terms of cost, latency, and anti-witch-hunting still require significant engineering refinement.
Conclusion | Beyond Financial Transparency, It's a Reconstruction of Business
Hyperliquid's attempt extends the principle of 'trustless' in DeFi from the transaction level to the source level, demonstrating what protocol-native growth is: it places the closed loop of 'user acquisition—transaction—revenue sharing' entirely on-chain, making it both traceable and verifiable, laying the foundation for a fairer incentive mechanism.
However, this design of attributing growth on-chain also brings up a core challenge: how to better protect individual strategies and privacy without sacrificing verifiability. Only when 'traceable ledgers' and 'anonymity rights' coexist harmoniously can the growth mechanism be considered to have completed its thorough migration from off-chain to on-chain.
