Current caveats
Limits and support
Fees, safety assumptions, admin routing workflow, testnet limits, degraded data states, and short answers to the questions users hit most often.
Reading progress
Navigate this topic
Current section
Fees
Reading mode
Focused route with anchored sections
Quick section jump
Within this topic
Protocol economics
Fees
Current public fees, pool fee tiers, creator support, and the difference between swap fees, sale fees, and reward APR.
Fees are shown separately because they are easy to confuse with price impact, creator support, LP rewards, or APR. Users should be able to understand the fee before they sign.
Public fees
Review the fees that matter to end users before they sign.
| Surface | Current value | Plain meaning |
|---|---|---|
| Fixed-price sale | 1.25% buy fee and 1.25% sell fee before finalization. | The fee is taken from live buy or sell-back transactions. Failed-sale redemption uses net reserve, not a refund of paid fees. |
| Bonding curve | 1.25% buy fee and 1.25% sell fee before migration, with 100% of those trade fees routed to protocol. | The quoted curve amount and the fee are separate. Users should read preview values before signing. |
| DEX pool | Standard fee tier is 0.30%. Other standard tiers are 0.01%, 0.05%, and 1.00%; custom fees are advanced. | The pool fee is paid inside swaps and affects route quotes and LP fee earnings. |
| Fixed-price creator support | Optional 0%, 10%, or 15% of final net DOGE reserve. DOGE only, no free creator token allocation. | Creator support is a visible budget taken only on successful settlement when configured. |
| Farm and staking APR | APR is not a protocol fee. It depends on reward rate, reward duration, token prices, and TVL. | Very high APR can simply mean low TVL or incomplete pricing data, not a safe yield. |
Safety model
Security assumptions
Wallet signing, network checks, official surfaces, routing and trust labels, analytics freshness, and what the UI cannot guarantee.
DogeFactory can reduce signing mistakes, stale data, and risky token actions, but the UI cannot make a token safe by labeling it. Read labels, approvals, and warnings as guidance for users, not as guarantees.
Within this section
Status labels
See what Route usable, Verified, Review, Blocked, Live, and Curve mean for the public.
| Label | Plain meaning | What it does not mean |
|---|---|---|
| Trusted | The token has an official or curated DogeFactory trust mark. | It is not a promise of profit, deep liquidity, or independent safety review. It only means DogeFactory has recorded a clearer context label. |
| Verified | The token is known through the current approved app path or a reviewed data source. | It is not a promise of profit, deep liquidity, or independent safety review. |
| Needs context | The app can see the token, but some price, route, sale, or trust details still need a clearer explanation. | It is not a ban and it does not mean the asset is invalid. It is a context label before users take action. |
| External | The token or pool is known outside the normal core launch path. | External context does not make it endorsed automatically. A token can exist on the network without being trusted by DogeFactory. |
| Watchlist | The token is visible for follow-up review. | Watchlist visibility is not endorsement and should not be treated as a trading recommendation. |
| Blocked | A critical risk was detected or recorded, so the public app should block swaps and new liquidity actions. | The token can still exist on the blockchain network, but the UI should not encourage users into it. |
| Live | The token has live DEX liquidity or an executable market path in the app. | It does not guarantee good depth, good price, or a safe exit. |
| Curve | The token is still in bonding-curve launch mode and may be visible before normal DEX trading. | It does not mean the token is already swappable through the public DEX route. |
- Always check the active network before signing. Testnet and mainnet must never be visually interchangeable.
- A transaction preview should show intent in plain language: action type, token, amount, approval target, recipient, minimum received, deadline, and any fee.
- Routing and trust labels are guardrails, not endorsements. Unreadable checks should block public swap and liquidity actions until the app can explain the status.
- Official DogeFactory surfaces can show known tokens or pools while still refusing the public action until route state is clear.
- Public labels should describe user action status, not rank supported contract generations.
- Blocked is stronger than Review. It means the public app cannot safely offer the action, even if the token still exists on the blockchain network.
- Analytics numbers can lag because they depend on supporting data services. Degraded, stale, or missing data must not be presented as exact market truth.
- Public documentation should explain user-facing behavior. Internal operational material belongs in private documentation.
- Do not trust unofficial links or pasted destinations. If the page and wallet preview disagree, do not sign.
- SUPPORTED, VERIFIED, LIVE, NEEDS CONTEXT, BLOCKED, and CURVE are app labels. None of them replaces independent review, liquidity review, or user due diligence.
Approval risks
Review the wallet approval checks that users should still read carefully.
Blocked or review warnings
Understand why some tokens stay hidden, blocked, or marked for review.
Operator workflow
Admin Support
How the admin Support page groups route registry review, review inbox intake, partner gateways, guarded actions, sorting, and redacted exports.
Admin Support is the operator review workspace for routing and trust decisions. It helps separate review inbox intake, route registry rows, partner gateways, guarded follow-up, and review exports so operators do not have to treat every routing task as the same job.
Within this section
What the page is for
Understand why Admin Support separates route registry review, intake, partner gateways, and guarded actions.
| Area | Purpose | How to use it | Limit |
|---|---|---|---|
| Subtabs | Split Support into Route registry, Review inbox, Partner gateways, and Guarded actions. | Pick the subtab that matches the job before changing filters or preparing an action. | A subtab is a workspace view, not a separate permission level or safety guarantee. |
| Route registry | Review observed, routed, review-state, and blocked rows with category, source, route state, and visible risk flags. | Filter, sort, inspect details, select rows, and prepare one-token or batch follow-up. | A visible token or pool is not automatically routed or recommended by DogeFactory. |
| Review inbox | Keep user-submitted route requests and scan triage separate from the route registry. | Read the request, compare it with visible token context, then choose review accepted, manual review, or emergency block follow-up. | A request does not make a token routed or recommended by itself. A clear triage result is not a contract approval or a public safety promise. |
| Partner gateways | Prepare controlled partner gateway setup without mixing partner context into the core route registry. | Review the entry, check visible readiness, and keep partner context attached to the row. | Partner context improves organization; it does not replace routing review. |
| Guarded actions | Group the final review, readiness status, confirmation text, and wallet action into one guarded sequence. | Load a reviewed target, confirm the intent, keep an audit note, and only proceed when the page shows readiness. | If the page shows locked, unclear, or failed status, stop rather than guessing. |
| Exports | Produce filtered reports for review while keeping redaction enabled by default. | Export only the relevant filtered or selected rows, then keep the report tied to the review context. | Exports are review aids. They do not perform routing or trust-state changes. |
Route registry, filters, and sorting
See how operators narrow the token list and choose a readable sort order.
The route registry can be narrowed by search, category, source, routing state, and quick filters. Sorting changes only the review order; it does not change routing or trust status.
| Sort option | Meaning | When to use it |
|---|---|---|
| Category | Groups rows by practical review category first, then by token name. | Use it for a normal registry pass. |
| Routing state | Groups Blocked, Review, Unknown, and no-blocker states together. | Use it when the priority is cleanup or routing triage. |
| Alphabetic: A to Z | Sorts token labels from A to Z. | Use it when searching a known name in a long list. |
| Alphabetic: Z to A | Sorts token labels from Z to A. | Use it as the reverse alphabetical view. |
| Last added | Shows the most recently added registry rows first. | Use it to inspect the newest entries added to the registry list. |
| First added | Shows the oldest registry rows first. | Use it to audit the original baseline list. |
| Newest created | Shows tokens with the newest available creation date first; rows without a date stay after dated rows. | Use it to review recent indexed creations. |
| Oldest created | Shows tokens with the oldest available creation date first; rows without a date stay after dated rows. | Use it to review older indexed creations. |
Review inbox and partner gateways
Review how intake requests and partner gateway entries stay separate from the main route registry.
Review inbox
Requests are intake items. They should be read, compared with visible token context, and closed with a short review outcome. A request does not make a token routed or recommended by itself.
Partner gateways
Partner gateways keep external or imported pool context grouped away from the core route registry. They still need normal review before users should rely on them.
Guarded actions and exports
Understand the safe operator sequence without exposing private implementation detail.
Safe operator sequence
- Start from the correct subtab: review inbox, token registry, partner gateways, and final guarded actions should not be mixed together.
- Use filters to reduce the visible set before selecting rows. Bulk actions are easier to review when the selected set is small and intentional.
- Keep redaction enabled for shared reports unless there is a clear internal reason to show full values.
- Treat Trusted, Review, Blocked, and Unknown as action states, not as endorsements.
- A row can be visible because the app knows about it; that does not mean it is endorsed for liquidity actions.
- Partner or external context helps organize review, but trust marks and blacklist changes only move after the decision is clear.
- Do not proceed from a locked, failed, or unclear state. Write a short review note and resolve the visible issue first.
- Use exports for review and handoff only. A report does not change blacklist or trust state by itself.
Known limits
Testnet notes
Degraded data behavior, empty states, known deployments, and current network caveats.
Testnet means two things here: the protocol is not in its final environment, and the UX still depends on supporting services, the explorer, and live network settings.
Missing or delayed data
See why testnet pages can look empty or partial even when the network is up.
- Token search can still show a deployment starter list when live token data is delayed.
- Pools, Farm, and Stake can show degraded states when public data or reward sources are not available yet.
- The Wallet page groups farm and stake modules, but it inherits the same public data availability limits.
- Public services can lag behind the network, so users should treat empty or stale states cautiously.
- The public swap searches available routes and fee tiers when they improve execution.
- Lists refresh periodically, not as an instant stream. A token or pool can appear with a short delay.
- A reboot of the frontend or backend should not delete tokens on the blockchain. If existing launches disappear from a page, the usual cause is missing indexed data or a missing deployment registry link.
- New deployments can become the active creation path while existing known deployments stay visible when they are still indexed.
- Public swap and add-liquidity screens use the current public liquidity path.
- Signed limit-order creation should remain unavailable until user-facing settlement and status reporting are ready.
- If you are still seeing an older frontend build, new watchlists, new docs links, or recent fixes may not appear until the frontend is rebuilt or restarted.
Empty or incomplete data
The swap token list can still show a deployment starter list while live token data is delayed. If DOGE and the starter watchlist are visible but recent tokens are not, public data is probably late. If Farm or Stake look empty, the reason can still be missing reward data, incomplete availability, or a service delay.
Common questions
FAQ
Short direct answers to the most common user questions.
What do Trusted, Review, and Blocked mean?
Trusted means DogeFactory has recorded a clearer official or curated context label. Review means context is incomplete, observed externally, or waiting for a clearer explanation. Blocked means a critical risk was detected or recorded and public actions should stay unavailable until policy changes. None of those labels is an audit or endorsement.
Does VERIFIED mean the token is safe?
No. VERIFIED is an app-level curation or indexing signal. It does not replace independent review, due diligence, or liquidity review.
Why can an existing token disappear after a reboot or redeploy?
A reboot does not delete tokens on the blockchain. If a launch disappears from a page, the page probably lost indexed data or the deployment registry link that tells the app where to read it.
What is the deployment registry?
It is the app list that connects each launch or pool to the DogeFactory deployment that created it. In simple words, it helps the app remember old and new versions at the same time.
What is the difference between visible and blocked?
Visible means the app can display indexed information. Blocked means a stronger risk policy applies and the public app should block swaps or new liquidity actions.
Can a pool exist without being endorsed by DogeFactory?
Yes. A token can exist on the network without carrying a DogeFactory trust mark. A pool can also exist without endorsement. The official app can still block critical-risk tokens and should only execute paths it can explain clearly.
When is a curve counted as Near migration?
In the current Launches page, Near migration starts at 75% progress. It means close to the migration target, not already migrated.
Why does the docs page talk about both fixed price and bonding curve?
Because DogeFactory exposes both paths. The fixed-price side has one active market-sale implementation, while the bonding-curve side is a separate live pre-migration trading model. The page separates the two so users can see which risks belong to which model.
Can a bonding curve be mathematically correct and still be a bad public launch?
Yes. A curve can be internally coherent while still concentrating value in early buyers, exposing later buyers to worse average pricing, or using parameters that make migration unattractive.
Why can a token appear in search while swap says No route available?
Because token visibility, pool existence, and live swappability are different. A token can exist in the merged token list, or even have a pool, while still lacking usable liquidity, fresh route data, a suitable fee tier, or a non-blocked executable path.
Why can search return nothing?
The app token search checks the list already loaded in the frontend. If the token is not loaded yet, or if no title, symbol, public identifier, alias, or team metadata matches, the result stays empty.
Why can a Farm or Stake pool be missing?
Because those pages depend on eligible reward sources being available and publicly discoverable. An existing token alone is not enough.
Why can I still withdraw from Stake after rewards stop?
Because the end of rewards should not lock principal. Withdraw, claim, exit, and supported safety withdrawals remain available according to the visible pool rules.
Does high slippage mean the trade is better protected?
No. High slippage means you are allowing worse execution before the transaction reverts. It increases execution tolerance, not user protection.