Current production snapshot
Production configuration
Live read-only values from the deployed Base contracts, separated from the broader capabilities implemented by their bytecode. Mutable state can change after this snapshot; the contracts remain authoritative.
Snapshot scope
- Network
- Base Mainnet · Chain ID 8453
- Read at
- September 9, 2026 at 20:25:23 UTC
- End-of-read reference block
- 51,098,088
- Block hash
0xd01a7e78cfdd63b034b54bc0be0258535bce32450f7ecf6d5e4f1d0b40b41b70- Paused
- No
Account-specific balances, allowances, grants and suspensions are not global configuration and are not published here. Aggregate counters are included only where the contracts expose them safely.
Subscription configuration
Contract capability. The core supports up to 60 billing periods per purchase. One contract month is exactly 31 days. The owner can change tier prices, discount thresholds, discount rates and tier availability.
| Current tier | Monthly price | Long-duration discount | Active |
|---|---|---|---|
| Strategic · Tier 1 | 120 USDC or USDS | 20% from 12 months | Yes |
| Sovereign · Tier 2 | 250 USDC or USDS | 20% from 12 months | Yes |
- Accepted USDC
- USDC · 6 decimals · 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913
- Accepted USDS
- USDS · 18 decimals · 0x820C137fa70C8691f0e44Dc420a5e53c168921Dc
- Core-held USDC treasury balance
- 0 USDC
- Core-held USDS treasury balance
- 0 USDS
Prices are normalized to 18 decimals on-chain, then converted to the selected token decimals with upward rounding. The same nominal values therefore apply to USDC and USDS.
Current module wiring
Contract capability. Each module slot in the core can be assigned only once. The contracts are not proxies and expose no bytecode upgrade function.
- Bulk access
- 0x5Ff1f2533E8A1dc26D16795aC6c03C7F03a3A57b
- Payment preview
- 0xffF583910A87e39C418813FEc3869E9FB823202c
Commission configuration
Current production snapshot. The active module is a Direct Match plan at configuration version 1. It has two upstream match levels, a configured maximum payout of 57.5% of gross payment, and requireQualifiedChain = false.
| Recipient | Strategic rate | Sovereign rate | Current qualification |
|---|---|---|---|
| Direct referrer | 25% of gross payment | 50% of gross payment | Active eligible tier |
| G1 · first upstream | 0% | 10% of the direct pool | Active Sovereign; no additional requirement |
| G2 · second upstream | 0% | 5% of the direct pool | Active Sovereign and at least 3 active direct customers at Strategic or higher, checked among up to 20 candidates |
- G1 and G2 rates are percentages of the direct commission pool, not percentages of the gross payment.
- G2 does not require G1 to have qualified because the current qualified-chain flag is disabled.
- Neither level requires qualified direct leaders or previous-level qualification in the current configuration.
- Maximum gross payout is 28.75% when the direct referrer is Strategic and 57.5% when the direct referrer is Sovereign.
Actual payment distribution
A subscription payment first moves the exact token amount from the payer to the core. The core asks the commission module for recipient decisions and immediately transfers each qualified commission to that account's configured commission receiver.
gross payment
→ qualified direct commission
→ qualified G1/G2 match commissions
→ all undistributed remainder to treasury- There is no commission claim step for successful payouts.
- A missing referrer, inactive or unqualified recipient, suspended recipient, zero rate or failed token transfer does not redirect the amount to another network participant.
- Every amount not successfully distributed is included in the treasury remainder in the same transaction.
- If the treasury transfer itself fails, the core records that token balance for later owner withdrawal.
- Bulk purchase payments bypass this commission plan and go entirely to treasury.
Numeric payment examples
These examples use the current 250 USDC Sovereign monthly price. Actual recipients depend on the purchaser's live referral path and qualification state.
| Scenario | Direct | G1 | G2 | Treasury |
|---|---|---|---|---|
| No referrerAll commission decisions retained | 0 | 0 | 0 | 250 USDC |
| Fully qualified Sovereign pathDirect pool = 250 × 50% | 125 USDC | 12.50 USDC | 6.25 USDC | 106.25 USDC |
In the second example, G1 receives 10% of the 125 USDC direct pool and G2 receives 5% of that pool. Total network payout is 143.75 USDC, or 57.5% of gross payment.
Auto-renew configuration
Contract capability. Auto-renewal is an explicit per-account opt-in. A renewal can add one 31-day period only during the three days before paid expiry. The configured payment token must remain accepted, the tier active and the monthly amount no greater than the stored per-renewal maximum.
- Frontend default
- Off
- Renewal window
- 3 days before paid expiry
- Renewal duration
- 1 × 31-day period
- Current observed state
- No enabled auto-renew configuration observed
- Token spender
- 0x422fb47edDf129FC76EaE68B515609e23c6B9230
The production subscription form leaves auto-renew disabled by default. The current frontend does not expose a self-service control for disabling an existing on-chain auto-renew configuration. Revoking the ERC-20 allowance remains a separate wallet action that prevents future token pulls without changing that configuration.
Bulk access configuration
Current production snapshot. The Bulk module is connected, but nextBulkTypeId = 1 and nextBulkId = 1. No Bulk plan type and no Bulk subscription has been created in the deployed module.
Contract capability. The owner can create plan types with a tier, seat limit, monthly price, duration discount, purchase expiry, commission mode, owner split and match-base mode. Purchases support 1 to 60 periods, allow batches of up to 100 seat assignments and settle the full purchase amount to treasury. There is currently no live numeric Bulk price or commission configuration to report.
Recovery configuration
Current production snapshot. Recovery requires at least five total votes, a seven-day voting period and strictly more yes than no votes. nextRecoveryProposalId = 1, so no recovery proposal has been created in this deployment.
Contract capability. Only the core owner can open or cancel a proposal. Eligible voters must have existed before the proposal, hold active access and cannot vote on their own recovery. After the deadline, any address may execute a proposal that satisfies quorum, majority and wallet-state checks.
Economically relevant controls
| Control | Authority / condition | Current production value |
|---|---|---|
| Pause state | Core owner | Unpaused |
| Tier pricing and discounts | Core owner | 120 / 250; 20% from 12 periods |
| Accepted payment tokens | Core owner | USDC and USDS |
| Treasury destination | Core owner | 0x9a7d4e92a6cC0915090eCd5209EB51CEE39d746a |
| Commission rates and qualification | Core owner, only while paused | Direct Match version 1 as detailed above |
| Bulk plan configuration | Bulk module owner | No plan types configured |
| Auto-renew preference | Individual account owner | No enabled configuration observed at snapshot |
| Recovery quorum | Constructor value; no setter | 5 votes |
| Ownership | Two-step transfer | 0x9a7d4e92a6cC0915090eCd5209EB51CEE39d746a; no pending owner |