Authored scenarios; no live network data
| Day | New Accounts | Active DAU | Daily Transactions | Req. Avg TPS | TPS Saturation | Illustrative Daily USD Cost |
|---|
How do assumed account arrivals and retention become transaction demand, and what remains unmeasured?
This local model adds the same number of new accounts each day, applies exponential activity decay to each cohort, and multiplies the summed active-account estimate by an assumed transaction frequency. Its presets are authored scenarios, including the TRON-labeled example; they are not live network observations or forecasts. No account, transaction or fee data is fetched.
Accounts are not unique people, and estimated activity is not measured DAU. Capacity changes a capped demand ratio and a fee assumption; it does not limit simulated transactions, create a queue or execute blocks. USD fee estimates do not implement TRON Bandwidth/Energy charging, TRX burn or exchange rates. This model cannot establish adoption, congestion or investment outcomes.
At 30 days, the default adds 150,000 accounts daily with a 14-day activity half-life. Rounded modeled activity is 2,402,147 accounts. At 3.5 transactions per active account, modeled daily demand is 8,407,514.5 transactions: about 97.31 average TPS and 145.96 assumed peak TPS. Against 2,000 assumed TPS capacity, the peak ratio is 7.30%, and the authored $0.025 fee gives $210,187.86 daily cost. These values come from the formula, not a TRON measurement.
For day d, sum A × 2^(−(d−c)/H) over acquisition days c = 1 through d, then round once to an integer. A is daily arrivals and H the activity half-life. The newest cohort contributes its full size; a cohort aged H days contributes half. There are no pre-existing accounts, reactivation, seasonality or different cohort behaviors.
The activity-share caption divides the last-day modeled active accounts by A × d, all accounts added so far. It mixes cohorts of different ages and is not the retention rate of a single cohort. TRON documentation distinguishes externally owned and contract accounts, and account activation from local address creation. None of those lifecycle steps is modeled here. TRON: Accounts and keys
Daily demand equals rounded modeled activity × transaction frequency. Average TPS divides by 86,400; peak TPS multiplies that average by an authored 1.5. Saturation displays min(100, peak TPS / chosen capacity × 100). Headroom displays max(0, round(capacity − peak TPS)). Ratios above 100% are clipped; inspect exported peak TPS to quantify unmet assumed capacity.
The warning starts above 85% of the displayed ratio, which is a chosen warning threshold rather than proof of exceeding capacity. Even at a capped 100%, the model retains every demanded transaction and charges for all of them. There is no throughput throttling, backlog, latency or failed-transaction model.
Base USD cost per transaction is 0.025 × the fee multiplier. Above 70% displayed saturation, multiply by 1 + 4 × ((saturation − 70)/30)^2. Daily cost multiplies that fee by modeled transaction demand; cumulative cost sums daily estimates. Since saturation is capped, the congestion factor stops increasing at five times the base fee.
Actual TRON transactions consume Bandwidth, and smart-contract execution additionally consumes Energy. Available resources, staking or delegation, fallback TRX charging and fee limits affect payment. This USD polynomial models none of those details and is not a protocol burn estimator. TRON: Resource model
The topology always draws 140 decorative circles. The active-circle count is clamped between 20 and 120 after dividing final modeled activity by 10,000; random circle sizes and force-layout positions are visual choices, not accounts or network connections. The time series independently scales activity and transaction demand to their own maxima. Its left axis shows activity only; the transaction curve does not share those numerical units. The right axis shows the capped percentage.
JSON includes assumptions and every daily result, plus an explicit model scope. CSV contains the daily results with rounded TPS and cost fields, but no input-parameter block; keep the matching JSON when comparing scenarios. Presets and Reset restore five assumptions while retaining the chosen duration. Only the duration input leaves the current preset marker unchanged. Exports contain scenario records, not live measurements or completed network trials.
Account types and activation; does not validate arrivals, unique users or activity retention.
Bandwidth/Energy and resource-payment distinctions; does not support this USD cost polynomial.