Skip to content

Contract Analysis

DISCLAIMER // NFA // DYOR

This analysis is based on observations of the contract behavior. We are not smart contract security experts. This document aims to explain what the contract appears to do based on the code. It should not be considered a comprehensive security audit or financial advice. Always verify critical information independently and consult with blockchain security professionals for important decisions.

⊙ generated by robots | curated by humans

Analysis Date: 2026-01-24

Metadata

Primary Contract

PROPERTY VALUE
Contract Address 0x1aa0c77d207cd2e20dc00523ee0511ac6514aeb3 (etherscan)
Network Ethereum Mainnet
Contract Type Standalone
Deployment Date 2025-11-25 19:34:59 UTC
Deployment Block 23,879,687
Contract Creator 0x8758ca21...bfd76968 (etherscan)
Creation TX 0x3d9ef3bb...9b2debbb (tx)
Compiler Version Solidity 0.8.30
Total Functions 13
External Contract Dependencies 0
Upgrade Mechanism ☒ None - Not Upgradeable
Verification Status ☒ NOT VERIFIED
Audit Status ☒ NO AUDIT FOUND
TYPE ADDRESS NOTES
Owner 0x8758ca21...bfd76968 (etherscan) Single EOA with full admin control; same owner as all Sentinel contracts
SENT Token 0xe88BAab9...5aDc304 (etherscan)
Token Allocation 0x8e1621a5...3745a0CC (etherscan) Possible consumer of day percent config
Claim Rewards 0x33184cD3...528A606D (etherscan) Possible consumer of day percent config

Executive Summary

Based on bytecode analysis and transaction patterns, this contract appears to be a day percent configuration registry for the Sentinel token ecosystem. It stores up to 100 days of parameters, with each day configured with both a percentage (in basis points, max 1,000,000 = 100%) and an amount. The owner can batch-configure multiple days or adjust individual parameters.

The contract does not hold, transfer, or interact with any tokens. It serves purely as a read-only data source that other Sentinel contracts (likely Token Allocation or Claim Rewards) query. Analysis of the first 10 transactions shows the owner configured days 1-7 during the initial deployment window (November 25-29, 2025), with multiple adjustments to individual days suggesting iterative configuration.

Key trust assumptions center on the contract owner (single EOA) who can arbitrarily modify daily parameters with immediate effect and no timelock delay. There is no multisig protection, no pause mechanism, and no configuration versioning. The unverified source code prevents independent audit, requiring trust in bytecode decompilation accuracy.

Notable risks include centralized owner control, immediate data propagation to dependent contracts, the ability to permanently freeze configuration via renounceOwnership(), and the absence of validation between configured amounts and actual allocations.

DASHBOARD INTEGRATION

This contract was identified via the Sentinel Dashboard source code, referenced by environment variable DAY_PERCENT_MANAGER_ADDRESS. Analysis of the dashboard JavaScript reveals a fetchSwarmMetrics() function that queries this contract, filtering for days where getCoreCount() == 10 (all cores active). The function interprets dayInfo.amount as total transaction amount and dayInfo.percent as profit percentage, calculating profit as amount * (percent / 100). This suggests the contract may serve as a metrics registry for all trading days, with Swarm metrics being a filtered subset where all 10 cores are used.

USE OF 'SCHEDULE' TERMINOLOGY

The contract's bytecode contains function names using "schedule" terminology: batchSetDaySchedule(), DaySchedule struct, and BatchScheduleUpdated event. The term "schedule" was originally interpreted here as "vesting schedule", however due to other research around the current state of the project's development, we do not want to dismiss the obvious coorelation that the swarm metrics/results values could be "scheduled" ahead of time for future use (e.g., to be used in simulated dashboard data).

That said, the dashboard implementation interprets this data as historical trading metrics (transaction amounts and profit percentages). Without verified source code or developer documentation, we can only call it out as-is and make note of it for future reference.

Architecture

graph TD
    Owner[Owner EOA<br/>0x8758...6968]
    Config[SENT Day Percent Manager<br/>0x1aa0...aeb3]
    Consumer[Consumer<br/>ex: Claim Rewards]

    Owner -->|batchSetDaySchedule| Config
    Owner -->|setDayPercent / setDayAmount| Config
    Consumer -.->|dayInfo / getPercentRange / getAmountRange| Config

    style Config fill:#f9f,stroke:#333,stroke-width:2px
    style Owner fill:#faa,stroke:#333,stroke-width:2px
    style Consumer fill:#eee,stroke:#999,stroke-dasharray: 5 5

System Overview

This contract functions as a centralized configuration store within the Sentinel ecosystem. Its primary purpose is to define day-indexed schedule parameters that other contracts query.

  • Stores day-indexed parameters (percent + amount) for up to 101 entries (days 0-100)
  • Does not hold, transfer, or interact with any tokens
  • No public state-changing functions exist; only the owner can modify configuration
  • Consumer contracts (inferred) query day percent data via view functions

Design Patterns Used

  • Ownable (OpenZeppelin-like): Standard single-owner pattern with transferOwnership() and renounceOwnership()
  • Batch Operations: batchSetDaySchedule() enables efficient multi-day configuration in a single transaction
  • Range Queries: getPercentRange() and getAmountRange() allow bulk data retrieval for consumer contracts

Access Control

Roles & Permissions

ROLE ASSIGNED BY REVOKABLE CALL COUNT
Owner Constructor (deployer) ☑ Yes - transferOwnership() or renounceOwnership() Unlimited
Public N/A N/A View functions only

Permission Matrix

FUNCTION OWNER PUBLIC
batchSetDaySchedule() ☑ ☒
setDayPercent() ☑ ☒
setDayAmount() ☑ ☒
renounceOwnership() ☑ ☒
transferOwnership() ☑ ☒
owner() ☑ ☑
dayInfo() ☑ ☑
MAX_PERCENT() ☑ ☑
MAX_DAY() ☑ ☑
getPercent() ☑ ☑
getAmount() ☑ ☑
getPercentRange() ☑ ☑
getAmountRange() ☑ ☑

Time Locks & Delays

ACTION TIME LOCK CAN CANCEL PURPOSE
Modify schedule None N/A ☒ Immediate, no protection
Transfer ownership None N/A ☒ Immediate, no protection
Renounce ownership None N/A ☒ Immediate, permanent, irreversible

Economic Model

This contract has no economic model. It does not hold funds, charge fees, or transfer tokens. It serves purely as a configuration registry.

Current Configuration Status

Based on on-chain queries (as of analysis date):

DAY PERCENT PERCENT (%) AMOUNT
1 43,500 4.35% 230,222
2 52,100 5.21% 334,111
3 21,000 2.10% 159,000
4 34,000 3.40% 133,000
5 44,000 4.40% 35,484
6 50,000 5.00% 28,313
7 47,000 4.70% [incomplete]

Basis Points Convention: 1,000,000 = 100%. So 43,500 = 4.35%.

Note: Days 0 and 8-100 return (0, 0). It is unclear whether these are unconfigured or intentionally set to zero.

Dashboard Calculation Discrepancy

The Sentinel Dashboard JavaScript includes code that divides the percent value by 100 rather than 1,000,000:

let profit = dayInfo.amount * (dayInfo.percent / 100);

This creates conflicting interpretations of the same stored values:

DAY STORED VALUE BYTECODE INTERPRETATION DASHBOARD INTERPRETATION
1 43,500 4.35% (43500 ÷ 1,000,000) 435% (43500 ÷ 100)
2 52,100 5.21% (52100 ÷ 1,000,000) 521% (52100 ÷ 100)

Without verified source code, we cannot determine which interpretation is correct. Possible explanations:

  • ◇ Dashboard contains a calculation bug (off by 10,000x)
  • ◇ Storage convention differs from standard basis points (values represent hundredths instead)
  • ◇ Contract has been superseded by a newer version with different encoding

The fact that the fetchSwarmMetrics() function containing this calculation is unused in production suggests the discrepancy may not have been discovered yet, or the contract is no longer actively used. The MAX_PERCENT constant (1,000,000) in the bytecode strongly suggests basis points encoding was intended, which would make the dashboard calculation incorrect.

Summary of Observations

Based on bytecode decompilation and transaction analysis, this contract appears to be a day percent configuration store deployed as part of the Sentinel token infrastructure. The contract was identified via the Sentinel Dashboard source code where it is referenced as the DAY_PERCENT_MANAGER_ADDRESS — the use of an environment variable implies this contract address is expected to change (future iterations would be deployed as new contracts).

The contract follows a standard Ownable pattern with no additional governance protections. The owner (0x8758ca21...76968) deployed and configured days 1-7 between November 25-29, 2025, with multiple revisions to days 4 and 5 suggesting iterative tuning. Since November 29, 2025, the contract has seen zero activity — no further configuration changes and no non-owner interactions.

The dual-parameter design (percent + amount per day) and the 7-day configuration window align with the Sentinel "Swarm" system which is documented as running in 7-day cycles. Dashboard source code reveals this contract is queried for metrics on days where all 10 cores are active, suggesting it may serve as a general metrics registry rather than exclusively for Swarm data. However, the function that queries this contract is not currently used on the live site, and a calculation discrepancy exists between the MAX_PERCENT constant (1,000,000, suggesting basis points) and the dashboard's divide-by-100 logic (suggesting hundredths). The incomplete configuration (only 7 of 100 possible days) and 56-day period of inactivity may indicate a development pause, contract supersession, or intentionally limited scope.

Strengths:

  • Clean, minimal design with well-defined boundaries
  • Input validation on day range (0-100) and percent max (1,000,000)
  • Batch operations reduce gas costs for multi-day setup
  • Range query functions enable efficient consumer reads

Weaknesses:

  • Single EOA owner with no multisig or timelock
  • No configuration versioning or rollback capability
  • No pause mechanism for emergency freezes
  • No cross-validation with actual token allocations
  • Source code not verified on Etherscan
  • No distinction between unconfigured and intentionally-zero days

This analysis was performed for educational purposes and should not be considered an official security audit or financial advice. We recommend independent verification of all findings and professional security review for any financial decisions.

References

RESOURCE NOTES
Etherscan - Contract Contract page (unverified)
Etherscan - Transactions Transaction history showing 10+ calls
SWARM Dashboard Analysis Frontend code analysis showing contract integration
Foundry Cast Reference Used for on-chain queries and storage reads
EIP-1967 Checked proxy slots (not applicable - standalone)
4byte.directory Function selector lookup for signature identification

Change Log

DATE AUTHOR NOTES
2026-01-24 Artificial. Generated by robots. Gas: 65 tok
2026-01-24 Denizen. Reviewed, edited, and curated by humans.