The Standards That Keep the Catalog Trustworthy
The quality of the BitcoinEra catalog depends entirely on the quality of what’s in it. A platform that lists every submitted bot without meaningful standards quickly becomes a place where users can’t tell a well-designed strategy from a poorly-constructed one — or worse, from an outright misrepresentation.
Every moderation decision BitcoinEra makes — every requirement, every standard, every enforcement action — is designed to protect one thing: the ability of users to make genuinely informed decisions about the bots they connect to their exchange accounts.
This guide is the complete reference for all moderation standards and listing requirements. It covers what’s required for initial listing, what’s required to maintain a listing in good standing, what triggers review or suspension, and exactly what happens when violations occur.
This guide is primarily for authors — but it’s also useful for users who want to understand how the catalog is maintained and what standards every listed bot has met.
The Three Pillars of Moderation
Every moderation decision on BitcoinEra is evaluated against three fundamental principles:
Pillar 1 — Transparency
Users must be able to make genuinely informed decisions. This means:
- Performance data must be accurate and complete — not cherry-picked
- Strategy descriptions must accurately reflect actual trading behavior
- Risk factors must be honestly disclosed — not minimized or obscured
- Authors must be identifiable and accountable
Transparency violations are among the most serious on the platform — they directly undermine users’ ability to make informed decisions.
Pillar 2 — Safety
Users’ financial security must be protected. This means:
- No bot may ever require withdrawal permissions
- Risk levels must be accurately assessed and disclosed
- Minimum capital requirements must be correctly calculated
- Strategy design must not create risks users cannot reasonably anticipate
Safety violations are treated with maximum severity — any risk to user funds is an immediate trigger for suspension.
Pillar 3 — Accountability
Authors must be present, responsive, and responsible. This means:
- Authors must respond to user messages within required timeframes
- Authors must communicate proactively when their strategy is experiencing difficulties
- Authors must maintain their documentation as strategies evolve
- Authors must not abandon listed bots without formally withdrawing them
Accountability standards reflect the reality that a bot listing is an ongoing relationship with users — not a one-time product sale.
Initial Listing Requirements — Complete Reference
These requirements must be met before a bot is approved for listing. They are non-negotiable — no exceptions are made regardless of track record length or author reputation.
Performance Requirements
Minimum Live Track Record
Requirement: 60 calendar days of live trading on a supported exchange.
Verification method: Direct API read from exchange — not self-reported data.
What constitutes live trading:
- Real capital deployed — minimum $100 equivalent
- Trades executed at real market prices
- On a supported exchange (Binance, Bybit, or OKX)
What does not qualify:
- Paper trading or simulation results
- Backtesting results regardless of methodology
- Results from unsupported exchanges
- Results from test or sandbox environments
Enforcement: Submissions with less than 60 days of verified live trading are automatically returned. No manual review exceptions.
Minimum Trade Count
Requirement: Minimum 30 completed trades (opened and closed) during the track record period.
Why 30 trades: Statistical significance requires a meaningful sample. 30 trades is the minimum for performance metrics to have any meaningful predictive value. A 5-trade history with 5 winners has a 100% win rate — but tells you almost nothing useful.
Implications by strategy:
- Scalping bots typically exceed this requirement within days
- Grid bots typically exceed within 1–2 weeks
- Trend following bots with monthly timeframes may need their full 60-day period to reach 30 trades — and in some cases may need a longer track record period
- Low-frequency strategies: authors may be asked to extend their track record period to demonstrate adequate trade count
Positive Net Return
Requirement: The bot must demonstrate positive net return (after all exchange fees) over the complete track record period.
Calculation method:
Net Return = (Final Value - Initial Capital) / Initial Capital × 100Fees deducted at the trade level — gross returns are not accepted.
Edge cases:
Bot broke even exactly: A net return of 0.00% does not meet the positive return threshold. Minimum acceptable is any positive value — even 0.01%.
Positive return during unfavorable conditions: If the track record period coincided with a particularly difficult market phase — reviewers may consider context. A bot showing +0.5% net return during a -30% Bitcoin correction demonstrates meaningful risk management. A bot showing +0.5% during a +30% Bitcoin bull run may indicate underperformance.
Recent underperformance after initial strong period: The full 60-day period is evaluated. A bot that returned +15% in the first 30 days and -14.5% in the second 30 days shows net positive — but the trajectory is a concern reviewers will note.
Maximum Drawdown Below 50%
Requirement: Maximum drawdown during the track record period must not exceed 50%.
Why 50%: A strategy that has experienced 50%+ drawdown has demonstrated the capability to destroy half a user’s capital — requiring a 100%+ return to recover. This represents an unacceptable risk profile for catalog listing.
Measurement: Maximum drawdown is measured from peak equity to trough equity during the track record period — using actual trade-by-trade capital values, not just entry and exit prices.
Strategies with inherently high drawdown: Martingale-type strategies often experience significant drawdowns by design. Authors of high-drawdown strategies must:
- Accurately label risk as High
- Provide explicit drawdown disclosure in the strategy description
- Demonstrate through documentation that users have sufficient capital to withstand the maximum drawdown scenario
- Show that the strategy’s returns justify the drawdown risk
Strategies approaching the 50% threshold receive additional scrutiny during review.
Documentation Requirements
Strategy Description Standards
Minimum length: 300 words for the strategy description section.
Required sections: Every strategy description must include all of the following:
How it works: Specific explanation of entry and exit logic. The review team tests this against actual trade data — if the described entry conditions don’t match when trades actually opened, the submission is returned.
Performance conditions: Specific market conditions where the strategy performs best and worst. Vague language like “performs well in all markets” will trigger a revision request.
Risk disclosure: Specific risks of this specific strategy — not generic cryptocurrency trading risks that apply to everything. A grid bot’s risk disclosure must specifically address what happens during a sustained downside breakout. A DCA bot must address extended bear markets. A Martingale bot must explicitly address ruin risk.
Minimum and recommended capital: Must be mathematically derived, not estimated. The review team verifies minimum capital calculations against the bot’s actual position sizing behavior.
Setup instructions: Sufficient detail for a user with basic technical knowledge to successfully connect the bot. Authors who assume excessive user knowledge receive revision requests.
Risk Level Accuracy
Requirement: The proposed risk level must accurately reflect the strategy’s actual risk profile based on historical performance and strategy characteristics.
Risk level criteria:
Low Risk:
- Maximum drawdown below 15% in track record
- Strategy design does not use leverage
- Position sizing conservative relative to capital
- No mechanisms that could produce rapidly accelerating losses
Medium Risk:
- Maximum drawdown 15–30% in track record
- May use moderate leverage or aggressive position sizing
- Strategy has clear downside scenarios but they are well-defined and bounded
High Risk:
- Maximum drawdown above 30% in track record
- Uses leverage, Martingale-type mechanics, or other mechanisms that can produce large losses
- Has scenarios where losses could exceed 40% of allocated capital
Author-proposed vs review-assigned: Authors propose a risk level in their submission. The review team independently assesses and may adjust upward (never downward — authors cannot underrate their own risk). If the review team increases a risk level, the author is notified and given the option to withdraw the submission if they disagree.
Minimum Capital Accuracy
Requirement: The stated minimum capital must be the actual mathematical minimum for the strategy to function — not a conservative suggestion or a marketing-friendly round number.
Verification method: The review team calculates the minimum capital from the documented configuration parameters and verifies it matches the stated minimum.
Common calculation errors:
DCA bots: Minimum = Base order + (Safety order size × Safety order count) Not: Base order only, ignoring safety orders
Grid bots: Minimum = (Number of grid levels × Minimum exchange order size) × 1.2 safety buffer Not: An arbitrary round number
Trend following bots: Minimum = Maximum position size × Maximum simultaneous positions × 1.5 buffer Not: Estimated based on typical rather than maximum position
Consequences of incorrect minimums: Users who connect with less than the actual minimum will experience configuration errors, inability to execute trades, or risk management failures. This generates support burden and user complaints — and is grounds for listing suspension.
Author Profile Completeness
Requirement: Author profile must contain:
- A background description of at least 100 words
- A credible description of relevant trading experience
- A realistic response time commitment
What’s not acceptable:
- Placeholder text (“Author description coming soon”)
- Completely anonymous profiles with no background
- Unrealistic response time commitments (promising 1-hour response when you can’t actually maintain that)
Technical Requirements
API Permission Compliance
Requirement: The bot must function completely with Read + Trade API permissions only. It must never require, request, or suggest enabling Withdrawal permissions.
This is an absolute requirement with zero exceptions.
Any bot that requests withdrawal permissions — for any stated reason — is immediately rejected and permanently barred from listing. This is not negotiable under any circumstances.
Verification: The review team tests API permission requirements by connecting the bot to a test account with only Read + Trade permissions enabled and verifying full functionality.
Supported Exchange Verification
Requirement: Every exchange listed as “Supported” must have been genuinely tested with live trades — not just assumed compatible.
Verification: For each claimed exchange — the review team verifies that live trade history exists on that exchange during the track record period.
Consequences of false exchange claims: Users who connect the bot to an untested exchange may experience connection errors, incorrect order execution, or strategy failures. This generates user harm and is grounds for immediate suspension.
Order Type Compatibility
Requirement: All order types used by the bot must be supported on every exchange the bot is listed as compatible with.
Common compatibility issues:
- OCO orders not available on all exchanges in all regions
- Trailing stop orders have different implementations across exchanges
- Post-Only order types have different availability
The review team verifies order type compatibility for each claimed exchange.
Ongoing Listing Requirements
Initial approval is not a permanent status. Maintaining a listing in good standing requires continuous compliance with ongoing requirements. These are evaluated on an ongoing basis — not only at annual review periods.
Performance Standards
Minimum Ongoing Performance
Requirement: Listed bots must maintain performance above minimum thresholds on a rolling 90-day basis.
Minimum thresholds for continued listing:
- Net return above -30% over any rolling 90-day period
- Maximum drawdown in any rolling 90-day period does not exceed 1.5× the historical maximum drawdown stated at listing
What happens when thresholds are approached: When a bot’s rolling 90-day performance approaches the minimum threshold — the author receives an automatic warning notification at 70% and 90% of the threshold limit.
What happens when thresholds are breached: The listing is automatically suspended — not deleted. The author is notified immediately with:
- Specific metrics that triggered suspension
- 14-day window to respond
- Options for resolution (see Suspension section below)
Why these specific thresholds: They’re designed to catch genuine strategy failure — not normal difficult periods. A trend following bot losing 15% during a choppy sideways market is experiencing normal adverse conditions. The same bot losing 40% over 90 days is experiencing something beyond normal — warranting review.
Track Record Continuity
Requirement: The bot must maintain continuous live trading activity. A gap in trading activity exceeding 30 days without author notification constitutes an abandonment signal.
Acceptable gaps:
- Scheduled maintenance announced in advance to users and the platform
- Exchange-side outages documented externally
- Market condition-driven pauses communicated to users
Unacceptable gaps:
- Silent inactivity without communication
- Repeated unexplained trading gaps
- Author inaccessible during inactive period
Author Conduct Standards
Response Time Requirements
Requirement: Authors must respond to user messages within 72 hours — measured from message receipt to first response.
Monitoring: Response times are automatically tracked. Authors with consistent response times above 72 hours receive warnings.
Escalating consequences:
- First warning: Notification + 14-day improvement period
- Second warning: Listing visibility reduced (not shown in “Top Bots” sections)
- Third warning: Listing suspended until response time compliance is demonstrated
- Persistent failure: Listing removed
Response quality: Response time alone is not sufficient. Responses must actually address the user’s question. Generic non-responses (“We’re looking into it”) that don’t answer the question are flagged in the moderation system.
Communication During Adverse Periods
Requirement: When a bot experiences a drawdown exceeding 50% of its historical maximum drawdown — the author must communicate with active users within 48 hours.
What communication must include:
- Acknowledgment that the bot is experiencing a difficult period
- Explanation of what market conditions are causing it
- Assessment of whether conditions are temporary or indicate strategy change is needed
- What action (if any) users should consider
What communication must not include:
- Guarantees that performance will recover
- Pressure to increase capital allocation
- Encouragement to disable risk parameters
Communication channel: Through the BitcoinEra author messaging system — sent as a broadcast to all active users of that bot. Authors cannot claim to have communicated via external channels.
Documentation Currency
Requirement: Strategy documentation must accurately reflect the current state of the strategy at all times.
Trigger for mandatory update:
- Any change to the strategy’s core entry or exit logic
- Any change to the supported exchanges or trading pairs
- Any change to the minimum capital requirement
- Any change to configuration parameters
- Any significant new information about strategy risk factors discovered through live trading
Update timeline: Documentation must be updated within 7 days of any material strategy change. Changes must be clearly marked as updates with the date of change — users can see the update history.
Strategy Change Notification
Requirement: When making material changes to the strategy — authors must notify active users at least 7 days before the change takes effect.
What constitutes a material change:
- Change to entry or exit logic
- Change to position sizing methodology
- Change to stop loss or take profit logic
- Addition or removal of indicators
- Change to trading pairs or exchanges
What does not require advance notification:
- Parameter adjustments within existing documented ranges
- Bug fixes that don’t change strategy behavior
- Infrastructure updates with no user-facing impact
User notification format: Through the platform’s broadcast messaging system. Must clearly explain what is changing and why, and give users the ability to disconnect before the change takes effect if they choose.
Content Standards
Honest Performance Representation
Requirement: All performance figures referenced in listing content — description, FAQ, promotional materials — must be accurate and not cherry-picked from favorable periods.
Prohibited representations:
- “Consistent 20% monthly returns” when monthly returns vary significantly
- Highlighting a specific month’s exceptional return without context
- Referencing total return without disclosing the period’s length
- Comparing performance to market benchmarks using different timeframes
Required context for performance claims: Every performance figure must be accompanied by:
- The time period it covers
- Whether it’s gross or net of fees
- The market conditions during that period (bull, bear, sideways)
No Guarantee Language
Requirement: No listing content may contain language that implies guaranteed returns, risk-free outcomes, or assured profitability.
Prohibited language examples:
- “Guaranteed profits”
- “Risk-free returns”
- “This bot never loses”
- “Always profitable”
- “100% win rate” (even if technically true for a very short period)
Required disclaimer: Every listing must display the standard BitcoinEra risk disclaimer. Authors cannot remove or obscure this disclaimer in any section of their listing.
Accurate Strategy Classification
Requirement: The strategy type selected during submission must accurately represent the primary trading mechanism.
Common misclassification issues:
- Labeling a Martingale-based strategy as “DCA” (these are different — see strategy guides)
- Labeling a mean reversion strategy as “Trend Following”
- Labeling a speculative high-risk strategy as “Grid Trading” for the lower-risk association
Consequence of misclassification: Users make strategy selection decisions based partly on strategy type. Misclassification leads users to choose strategies that don’t match their risk profile expectations. This is a transparency violation.
Review and Moderation Actions
When a listing violates requirements — the moderation team takes one of four actions depending on severity.
Action 1 — Warning
When it’s issued:
- First occurrence of minor violation
- Performance approaching (but not breaching) minimum thresholds
- Documentation lag (outdated but not materially misleading)
- Response time consistently near but not exceeding 72-hour limit
What it means: Formal notification that a specific standard is not being met, with a defined improvement period (typically 14–30 days). No impact on listing visibility yet.
Author response required: Acknowledge receipt and provide a specific remediation plan within 7 days.
Action 2 — Listing Modification
When it’s issued:
- Risk level requires adjustment upward based on new performance data
- Minimum capital requirement requires correction
- Strategy description contains inaccurate claims that must be corrected
What it means: The review team makes specific changes to your listing — typically adding risk disclosures, adjusting risk level, or correcting factual inaccuracies. You are notified of all changes and can discuss them through the author support channel.
Why direct modification rather than waiting for author update: Some modifications are necessary to protect users immediately — waiting for author response is not always possible when user funds may be at risk based on misleading information.
Action 3 — Listing Suspension
When it’s issued:
- Performance falls below minimum ongoing thresholds
- Author response time consistently above 72 hours after warnings
- Material strategy change without required user notification
- Documentation significantly outdated (30+ days after material change)
- Strategy experiencing unusual behavior under investigation
What it means: The listing is hidden from the catalog — new users cannot discover it. Existing users with the bot connected are not affected — their connections remain active. The author is notified with specific reasons and options.
Suspension options for authors:
Option A — Remediate and reinstate: Address the specific issues identified. Provide evidence of remediation. Request reinstatement review. Typical reinstatement review: 5 business days.
Option B — Temporarily withdraw: Formally withdraw the listing while addressing performance or strategy issues. Can be resubmitted when ready — goes through an abbreviated re-review rather than full initial review.
Option C — Permanent withdrawal: Close the listing entirely. Existing users are notified that the bot author has discontinued the listing and given a 30-day notice period.
Action 4 — Permanent Removal
When it’s issued:
- Fraudulent performance data — fabricated or manipulated trade history
- Withdrawal permission requirement — any bot requiring withdrawal access
- Malicious strategy design — bot designed to harm users rather than trade effectively
- Persistent violation after multiple warnings and suspension
- Author identity fraud — misrepresentation of identity or credentials
What it means: The listing is permanently removed from the catalog. The author’s BitcoinEra account is suspended. The author is barred from submitting new listings.
Existing user impact: Users with the bot connected receive immediate notification. Their API connections to the bot are terminated. Any open positions remain on their exchange — they are not affected by the removal itself but need to manage their positions manually.
No appeal for fraud: Removal decisions based on verified fraudulent performance data or withdrawal permission requirements are not subject to appeal. These are absolute violations with predetermined consequences.
User Reporting System
Users can report concerns about listed bots through a formal reporting mechanism. Reports feed directly into the moderation review system.
What Users Can Report
Performance misrepresentation: Bot is performing significantly differently from what the listing describes — not just a bad period, but fundamentally different behavior than documented.
Strategy description inaccuracy: The bot is making trades that don’t match the documented entry and exit logic.
Author unresponsiveness: More than 72 hours with no response to a reasonable question.
Risk level mismatch: The bot is experiencing drawdowns that seem inconsistent with its stated risk level.
Suspicious behavior: Any behavior that seems designed to harm users rather than trade effectively.
How Reports Are Processed
Step 1 — Receipt and Acknowledgment: The reporting user receives an acknowledgment within 24 hours. Not a resolution — an acknowledgment that the report is in the system.
Step 2 — Initial Assessment: The moderation team reviews the report within 3 business days. They determine whether it warrants investigation or can be addressed through existing information.
Step 3 — Investigation: If investigation is warranted — the team reviews the bot’s live trade data, listing content, author communication records, and any additional context. Authors are not notified of investigations in progress — to prevent evidence manipulation.
Step 4 — Outcome: One of three outcomes:
- No action required — report doesn’t reflect a genuine violation
- Warning or listing modification issued to author
- Suspension or removal if violation is confirmed
Step 5 — Reporter notification: The reporting user is notified of the outcome — not the specific action taken (to protect author privacy) — but whether the report resulted in any action.
Appeals Process
Authors who believe a moderation action was made in error have a formal appeals process.
What Can Be Appealed
- Warning issuance
- Listing modification
- Listing suspension
- Performance threshold interpretation
What Cannot Be Appealed
- Removal for fraudulent performance data (fraud is not an error)
- Removal for withdrawal permission requirements (absolute policy)
- Removal for malicious strategy design
How to Submit an Appeal
Timeline: Appeal must be submitted within 14 calendar days of the moderation action notification.
Submission: Email: [email protected] Subject: Appeal — [Your Author ID] — [Action Type] — [Date]
Required content:
- Specific action being appealed
- Specific grounds for appeal — not general disagreement but specific factual or procedural error you believe occurred
- Supporting evidence — data, timestamps, communications that support your position
- Requested resolution
Appeal review: Conducted by a senior moderation team member not involved in the original decision. Timeline: 10 business days.
Appeal outcomes:
- Action upheld — original decision stands
- Action modified — specific aspect of the decision changed
- Action reversed — original decision overturned
Final decisions: Appeal decisions are final. There is no second appeal mechanism.
Catalog Quality Metrics — How the Platform Monitors Health
BitcoinEra continuously monitors catalog health metrics to identify systemic issues before they affect users.
Bot-Level Metrics Monitored
For every listed bot — continuously:
- Rolling 30/60/90-day returns vs historical averages
- User disconnection rate (unusual disconnection spikes signal user dissatisfaction)
- Support ticket volume related to specific bots
- Author response time trends
- Documentation update frequency
Catalog-Level Metrics Monitored
Across the entire catalog:
- Average maximum drawdown by strategy type
- Distribution of performance across market conditions
- Author retention and engagement rates
- User satisfaction indicators
These metrics feed into ongoing moderation prioritization — bots that generate unusual patterns receive earlier attention than those performing within normal parameters.
Summary
Here’s everything we covered in this guide:
- The three pillars of moderation — transparency, safety, and accountability
- Complete initial listing requirements — performance, documentation, technical, and author profile standards
- Ongoing listing requirements — performance standards, author conduct, documentation currency, and communication requirements
- Content standards — honest performance representation, no guarantee language, accurate classification
- The four moderation actions — warning, listing modification, suspension, and permanent removal — with triggers and procedures for each
- The user reporting system — what can be reported and how reports are processed
- The appeals process — what can be appealed, how to submit, and what outcomes are possible
- Catalog quality metrics — how the platform monitors health at both bot and catalog level
⚠️ Moderation Policy Notice: BitcoinEra’s moderation policies are subject to change as the platform evolves and as the cryptocurrency market matures. Authors will be notified of any material policy changes with appropriate notice periods. Current policy version and last updated date are displayed in the Author Portal.
