Credit Mathematics

Credits determine your share of CreditTokens. After the market operator submits point weights on-chain, the contracts automatically issue CreditTokens period by period rather than as a single lump sum at the end of a series. This page explains how credits work, why periods exist, and how GCI lets the protocol track credits on-chain. Prerequisites: What is ArcX?, vToken, Series Lifecycle

---

​

Why Credits Exist

Without credits, CreditToken distribution would be trivially gameable. A naive design that distributes CreditTokens proportional to token balance right before a distribution lets anyone deposit one second before distribution and claim the same share as a day-one holder. Credits prevent that by tracking not just what you hold, but how long you held it for.

---

​

Series and Credit Periods

A series is a fixed-maturity market built on top of a vToken. Each series has a maturity date and its own ST and EPT tokens. Each series is divided into credit periods. Their schedule is configured to reflect the measurement or reporting cadence of the underlying program. The main purpose of periods is to give credits different weights over time. Without periods, an early user and a late user with the same final balance could end up with the same points exposure, even though the early user contributed for longer. For a points program with weekly reporting, for example, ArcX can use weekly credit periods. Each finalized period preserves the credit share earned during that interval.

---

​

Program Cadence and Finalization

The on-chain credit schedule and an underlying program’s reporting schedule do not have to finalize at the same moment. A program can report activity later, use a different cutoff, or revise its own schedule. The vault’s configured credit periods determine when ArcX measures holder participation. After the information needed for a period is available, the market operator submits that period’s point weight on-chain. The contracts then automatically issue CreditTokens from the finalised credit shares. ArcX credit periods will likely align with the underlying program’s calendar, but this is not guaranteed. Always use the schedule shown for the vault or series to determine ArcX credit eligibility.

---

​

How Credits Are Calculated

Credits are a way to track what share of total CreditTokens you should receive at the end of every period. From the protocol’s perspective, the fair way to allocate credits is to measure: $$\text{capital} \times \text{time}$$ An underlying protocol can use its own undisclosed or changeable points formula. ArcX does not attempt to reproduce that formula for each user. Within ArcX, position value multiplied by time is the basis for allocating each period’s CreditTokens.

---

​

Calculating Credits

The value of a position may or may not change over time:

• in a zero-yield vault, NAV remains constant
• when vToken yield is reflected through NAV, NAV changes to reflect that value
• yield reflected solely in the input token’s own price does not change a NAV denominated in that token

So mathematically, capital multiplied by time becomes: $$\text{area under the capital-time curve}$$ With constant NAV, this area is a rectangle. When NAV changes, the protocol uses the average of the starting and ending NAV, producing a trapezoid. That area is what credits are trying to track. We cannot recompute area-under-the-curve for every user on-chain as time passes. So instead, the protocol tracks a global accumulator called GCI.

---

​

What GCI Is

GCI stands for Global Credit Index. GCI is the amount of credits earned per credit-bearing token unit over time. The point of tracking GCI is that the protocol does not need to store a full capital-time history for every user. Instead, when a user’s balance changes, credits can be computed from: $$\text{balance} \times (\text{new GCI} - \text{previous GCI})$$ This is the key simplification:

• GCI tracks credits earned per share globally
• each user only needs their balance and the last GCI checkpoint relevant to them

For credit purposes:

• 1 vToken earns credits at the same rate as 1 EPT
• both contribute equally to period credit accumulation

---

​

How GCI Is Calculated

For any time interval: $$\text{GCI increment} = \frac{\text{NAV}_{start} + \text{NAV}_{end}}{2} \times \text{days}$$ This is the average NAV over the interval multiplied by the duration. Equivalently: $$\text{GCI increment} = r_1 \times \Delta t + \frac{1}{2} \times \Delta t \times (r_2 - r_1)$$ where:

• $r_1$ = NAV at the start of the interval
• $r_2$ = NAV at the end of the interval
• $\Delta t$ = time elapsed in days

Geometrically, this is the area of a trapezoid under the capital-time curve.

​

Constant-NAV Vaults

If a vault has no underlying APY, then: $$\text{NAV}_{start} = \text{NAV}_{end} = \text{NAV}$$ The same GCI formula reduces to: $$\text{GCI increment} = \text{NAV} \times \text{days}$$ If NAV is constant at 1, user credits reduce to: $$\text{your credits} = \text{your balance} \times \text{days}$$ This is not a separate credit model. It is the constant-NAV case of the same NAV-based GCI formula.

---

​

How User Credits Are Calculated

Your credits over any interval are: $$\text{your credits} = \text{your balance} \times \text{GCI increment}$$ More generally, whenever your balance changes, the protocol can settle the credits earned since your last checkpoint by multiplying your balance by the change in GCI over that interval. That is why GCI is useful: it turns a continuous capital-times-time problem into a simple checkpointing problem.

---

​

Fresh Credits on Transfer

When tokens change hands, the new holder starts fresh from that moment.

• Orderbook purchase: you buy EPT and start with zero prior credits
• Minting: you deposit the vault’s supported input token and receive freshly minted vTokens that start from zero prior credits
• No credit inheritance: the buyer does not receive the seller’s previously accumulated credits

Credits are non-transferable. Only future holding time counts for the new owner.

---

​

Period-by-Period CreditToken Distribution

CreditTokens are issued automatically period by period: $$\text{yourCreditTokens} = \sum_{p=1}^{P} \frac{\text{yourCredits}_p}{\text{totalCredits}_p} \times \text{periodWeight}_p$$ where:

• $P$ = number of credit periods
• $\text{yourCredits}_p$ = your credits during period $p$
• $\text{totalCredits}_p$ = all credits during period $p$
• $\text{periodWeight}_p$ = the point weight submitted on-chain by the market operator for that period

This is why early participation matters. If earlier periods carry higher weights, early holders get that upside. Later entrants do not dilute those earlier periods. For protocols with points programs, you can think of period weights as proportional or equal to the points received for the corresponding period. If one week generates more points than another, that week can receive a higher CreditToken weight.

---

​

Worked Example

The objective of this example is to show that an early holder can keep a large advantage even when a later user brings in enough capital to match the same total capital x time. Setup: 10-week series.

• Alice holds 100 vTokens from week 1
• Bob buys 250 EPT at week 7
• Weeks 1-6 have a period weight of 800 per week
• Weeks 7-10 have a period weight of 200 per week

Bob brings in more capital later so that his capital x time is the same as Alice’s:

• Alice: 100 x 10 weeks = 1,000 token-weeks
• Bob: 250 x 4 weeks = 1,000 token-weeks

Weekly distribution: CreditTokens: Even though Bob contributes the same total capital x time as Alice, Alice gets far more CreditTokens because the earlier weeks were richer and those periods are locked in to the early holder.