DOCK and the 3% trading fee
Our proposed token model: using trading fees to build USDG lending capacity, support liquidation operations, and fund defined holder benefits.
Dockyard needs USDG to lend, capital to liquidate unsafe loans, and people and software to keep those operations running. Our proposed DOCK token would help fund that work through trading fees and give holders defined benefits within the borrowing platform.
We are keeping a 3% combined trading fee in this proposal. Dockyard is early in its development, with operational and security work still to complete. Lending income alone does not yet support the system we want to run. A fee budget can pay for that work, but paying a higher fee does not make a protocol safe.
This article describes a token design, not a token launch announcement. The fee-routing contract, locking system, holder benefits and governance described below are not live. DOCK remains the proposed name and ticker until launch details are confirmed.
The borrowing product comes first
Dockyard lends existing USDG against supported Stock Tokens on Robinhood Chain. A borrower deposits collateral, receives USDG from the funded vault, and repays the debt to recover the remaining collateral. If the position becomes unsafe, a liquidator can repay debt and receive collateral.
Stock Tokens back the loan. USDG is the asset supplied, borrowed and repaid. DOCK would provide optional benefits around that activity. Borrowers would not need DOCK to repay their loans or recover collateral, and this proposal does not make DOCK an accepted collateral asset.
The current credit vault is deployed and has completed a small real-wallet borrowing and repayment cycle. That is evidence that the tested flow worked, not an audit or proof that every market condition is covered. Liquidation operations and monitoring are still being developed and verified. Our project brief describes the vault's mechanics and verification gaps.
What 3% means
The proposal is a 3% combined ordinary trading fee on DOCK buys and sells through the intended Pons V2 launch venues. It is not a 3% fee on borrowing USDG or trading Stock Tokens.
With the factory configuration checked on September 2, 2026, that means:
| Fee component | Rate |
|---|---|
| Standard Pons trading fee | 1% |
| Dockyard creator fee | 2% |
| Combined ordinary trading fee | 3% |
Dockyard would receive its creator fee and eligible share of the standard fee, not the entire 3%. Gas, price impact and any opening anti-sniping charge are separate. We must verify the final launch parameters. Pons V2 fee documentation
For a 1,000 USDG buy subject to the ordinary 3% rate, the trading fees would be 30 USDG before gas and price impact. Selling also incurs a fee. Frequent trading can become expensive; this cost should be visible before someone buys DOCK.
Pons documents the launch's fee rates as immutable. Our early-stage funding needs explain the proposed rate, but we are not promising a temporary fee or a reduction once Dockyard matures. Pons launch terms
Why we need more than borrowing fees
The deployed vault charges a one-time 0.5% origination fee and does not accrue ongoing interest. One million USDG of new borrowing would create 5,000 USDG in gross origination fees, assuming those fees are repaid. That figure excludes expenses and losses. It is an arithmetic example, not a forecast of borrowing demand.
Fees added to outstanding debt are not cash available to spend. We need to distinguish borrower principal, collected income, money reserved for losses and any surplus available for other uses.
At this stage, trading-fee receipts could provide another source of capital. They would not be dependable income: DOCK trading activity could decline sharply or stop. Liquidation operations must have a funded operating budget without relying on the next token trade to pay for gas or debt repayment.
Where Dockyard's receipts would go
We propose the following starting allocation of the fees Dockyard actually collects. These percentages apply to Dockyard's receipts, not total trading volume or the full fee charged to traders. The allocation remains a design proposal; no contract currently enforces it.
| Share of Dockyard receipts | Proposed use |
|---|---|
| 60% | Additional USDG lending capital |
| 25% | Liquidator capital, monitoring and security work |
| 15% | A capped budget for defined token-holder benefits |
For every 1,000 USDG received by the Dockyard treasury, this proposal assigns 600 USDG to lending, 250 USDG to liquidation and security operations, and 150 USDG to the holder-benefits budget. This example does not assume that Dockyard will collect that amount.
The 25% operating allocation needs its own accounting: liquidator inventory, loss reserves and money spent on services are different things. They cannot all be reported as an untouched reserve. USDG lent to borrowers cannot simultaneously be counted as spendable liquidator capital.
If reserves or operating funds fall below the reviewed minimums, benefits should stop accruing before essential operations run out of money. The final routing contract needs to define that priority, the minimums and the treatment of benefits already earned. An allocation on a blog page is not an enforceable commitment.
The proposed DOCK/USDG pairing would let Dockyard receive launch fees in USDG. Bonding-curve purchase proceeds are different: they seed the graduated trading pool, rather than becoming spendable lending capital. Pons launch lifecycle and custom pairs
What holding DOCK would do
Our first proposed benefit is a borrowing-fee rebate for qualifying DOCK lockers. Eligibility would need to begin before borrowing, and the rebate would be paid only after the relevant fee is actually repaid. Every rebate would be subject to an explicit budget and claim rules.
For example, a 20% rebate on a 0.5% borrowing fee would reduce the effective fee to 0.4%. That is an illustrative benefit, not an active offer. Borrowing and immediately repaying must never earn rewards worth more than the fee paid.
The discount also has to be worth the cost of obtaining DOCK. At a 3% trading fee, a 1,000 USDG purchase costs 30 USDG in entry fees. A 0.1-percentage-point borrowing rebate would require 30,000 USDG of eligible borrowing to offset that entry cost alone, ignoring token-price changes, selling fees and gas. We should not present a small rebate as an automatic reason to buy the token.
Limited governance could let holders influence development priorities and bounded ecosystem budgets. It should not allow a token vote to take borrower collateral, drain reserves or immediately weaken oracle protections. Those boundaries need to exist in code before we describe governance as a live benefit.
Any later USDG reward or buyback program would require separate implementation, security review and legal assessment. Rewards sourced from token trading fees must be described as trading-fee rewards, not lending yield. We are not proposing a fixed APY, a guaranteed token price, or a promise that holders can redeem DOCK for the vault's USDG.
The treasury needs enforceable limits
The current vault owner can withdraw idle USDG and controls borrowing pauses, market enables and debt ceilings. Sending token-fee receipts into that vault would not, by itself, make the funds community-owned or permanently committed.
Before making that commitment, we need reviewed treasury permissions, secure key custody and rules separating lending capital from distributable income. Reports should show collected fees, actual allocations, available liquidity, outstanding debt, operating expenses and losses. Token holders need to be able to compare those records with what we said the money would fund.
USDG that has already been borrowed is not immediately withdrawable. Liquidations may fail to recover the full debt, particularly during price gaps, oracle disruptions or poor collateral liquidity. Reserves cannot eliminate these risks or replace independent review.
What must exist before the token launches
The next work is concrete: finish and verify liquidation operations; build fee collection and treasury accounting; specify the locking and rebate rules; and review the contracts, owner permissions and eligibility requirements. The launch documentation then needs the actual token address, fee configuration, recipient contracts, holder rights and any team acquisition or vesting arrangements.
We are keeping 3% in the design because Dockyard needs capital and operating capacity while the protocol is still being built. The case for DOCK will depend on delivering those systems and reporting their use of funds. Until then, these are proposed uses and benefits, not features someone can buy today.