← The evidence ledger
Evidence row 3956565
Observed , by probe.mcp/1.
- Kind
- mcp.tools
- About
- endpoint 5998d6ba-d709-4350-8f9c-54bb4f86da04
- Recorded
- Previous row
- #3694407
- Body SHA-256
- 2f8059f8d1ff7b90142d02d2bad1b29263b55c1eca896fbff2049219f95fddce
- Leaf
- 0x6f57e688becef44e4ff973cf8be1843cb3228e8dd9fec93e90e9aaa557b179d9
What was observed
{
"count": 15,
"tools": [
{
"description": "Axis③ (Order/Execution) — closes (or partially reduces) an existing position through DECKER'S OWN execution engine (see decker.place_order for what that means — same account-linkage requirement applies here for real positions). Unlike place_order, there is no crypto-6 restriction — this reduces risk, not adds it, so any symbol you actually hold (including HL-synthetic/KRX paper positions) can be closed. Mode is NOT chosen by the caller — this looks up whatever position(s) actually exist for the symbol (real via live exchange query, virtual via the paper ledger) and closes whichever are open; if both a real and a virtual position exist for the same symbol, both are closed and the response reports execution_mode as 'mixed'. No open position for the symbol = a clean not-found response, not an error — safe to call speculatively.",
"inputSchema": {
"properties": {
"close_fraction": {
"default": 1,
"description": "Fraction of the current position to close, 0 < x <= 1. Default 1.0 = full close. E.g. 0.5 closes half.",
"exclusiveMinimum": 0,
"maximum": 1,
"type": "number"
},
"symbol": {
"description": "e.g. BTCUSDT, XYZ_GOLDUSD — whatever symbol you hold. Aliases resolve like other tools.",
"type": "string"
}
},
"required": [
"symbol"
],
"type": "object"
},
"name": "decker.close_position"
},
{
"description": "THE answer for 'what is the situation and what do I do on this symbol now' — one verdict per symbol, built from the per-timeframe judgment state (CR1); no scores or weights. READ IN THIS ORDER: (1) verdict = state (direction · phase) + action: 진입 enter now (a new signal) | 유지 hold the existing stance, NOT a new entry | 청산 exit | 대기 wait; `reason` says why, `condition` = the nearest closes that would change it (below/above the price; full what-if text `until` is detail only). (2) summary_ko = ready-to-show Korean lines. (3) entry / stop / target / rr = the prices (entry.mode says whether it is a new entry or on hold — when the action is not 진입 it never says 'now'; target may be null with target.reason, e.g. no coordinate at least 2% from the entry price; rr mixes the entry timeframe's stop with the target timeframe's target). (4) as_of = the bar this answer is based on. Default = the answer only (summary_ko = state, action, condition, coordinates); with `symbol` also `readings`/`events` (get_market_state lines). Pass detail=true for the structured detail: path (nearby prices and what a close there means), watch (upcoming bar closes in time order and the question each decides), story (this / last signal), ladders, matrix_summary (every timeframe's row incl. gate), tf_states (EVERY timeframe's own state: judgment stage, open reversal test with its confirm price, engine action, next-bar label chain, recently missed targets — none folded by direction), knots (every timeframe's decision prices by distance from the price — the ORDER they would be reached, not a probability). `reason` may end with '반대 방향 판정 진행 중: …' = timeframes testing against the stance (a fact; never changes the action). Omit `symbol` for all 14 symbols. Roles: theme = the highest timeframe whose current bar has reached its target and is being judged there — the answer (state · action · coordinates) is that timeframe's; `grade` = the theme's phase (test | confirm | null when no theme). head_horizons_ko = per-horizon lines: a timeframe whose latest bar is GO is a piece — an entry for anyone trading that timeframe or a higher horizon, not the symbol answer; 1w is a horizon (direction/target) only, never an entry. Caveats: action 진입 ≠ every timeframe's gate GO (see matrix_summary[].gate); entry.mode '지금' ≠ a new event this bar. Narrate or filter the result — do not re-decide coordinates.",
"inputSchema": {
"properties": {
"detail": {
"description": "Include path / watch / story / ladders / matrix_summary (about 20KB per symbol). Default false: the answer only.",
"type": "boolean"
},
"symbol": {
"description": "Optional symbol or alias (BTC, 비트코인, GOLD, 테슬라...). Omit for all 14 symbols.",
"type": "string"
}
},
"type": "object"
},
"name": "decker.get_assembly"
},
{
"description": "Price-axis EPISODE history — answers 'where did I buy/sell last time, what was the target value and the event chain then, and where did price move WITHOUT a signal (and which target values it passed = missing points)'. Read-only from the persisted event ledger (no recompute). `episodes` (newest first) = one target selection until the next: target {price, from_price, reason}, chain (primary-unit judgment events), signals {ts, side, entry, targets, resolved{status, close, bar_low, bar_high}}, left (target_left: MISSING = a target value price passed through with no judgment; MOVED), missing, signal_gap (no signal in that episode), move {start_close, end_close, pct}. `signal_gaps` (ascending) = the interval between consecutive signals with its price move and the missing points inside (last one is open). Missing points carry `sign` and `position` (price below/above the target at the pass) — classify on the read side; do not re-decide coordinates. History starts at the first persisted event of this generation.",
"inputSchema": {
"properties": {
"limit": {
"default": 5,
"description": "number of episodes",
"maximum": 20,
"minimum": 1,
"type": "integer"
},
"symbol": {
"description": "e.g. BTCUSDT",
"type": "string"
},
"timeframe": {
"enum": [
"30m",
"1h",
"4h",
"8h",
"1d",
"1w"
],
"type": "string"
}
},
"required": [
"symbol",
"timeframe"
],
"type": "object"
},
"name": "decker.get_episodes"
},
{
"description": "PER-TIMEFRAME judgment state of a symbol — the evidence behind decker.get_assembly's single verdict (call get_assembly first for 'what do I do'). DEFAULT (detail=false): per timeframe (top→short) `reading` = one Korean line: target (touch kind, touch bar time) · phase (대상선정 / 테스트 국면 / 확인 국면 with hold count / outcome) · bar role now and what the next bar makes it · latest signal and its outcome (signal bar time, close) · action · price vs target · next close and what confirms or fails it; `chain` = the last 3 targets: selected → judge bar·signal bar results → outcome; `events[].line` = one line per state change, newest first, each timeframe's latest included; `assembly_summary_ko` = the symbol's answer (same lines as get_assembly); `head_reading` = theme line: the highest timeframe whose own target is under judgment now, with that timeframe's one signal (entry·target·invalidation); `head_horizons` = one line per horizon timeframe: its target · next cell up/down · action · pieces (just-born signals at or below it, goal = that horizon's next cell). Read these as-is. detail=true: the full structured state (consumer contract CR1) — stage (target_selected | pending | confirmed | failed | none), side, signal_bar {time, low, high}, entry (= close at the signal), stop, target (take-profit, else null + target_reason), unit_target (the price being judged — NOT the take-profit), units, reverse_pending, standing, label_next, levels, ladder, events (structured). as_of = the latest closed bar among the returned timeframes. Read as persisted (no recompute); no scores, weights or probabilities. A state reading, NOT a trade instruction. Crypto, Hyperliquid synthetics and KRX stocks (005930.KRX or the Korean name — daily/weekly timeframes only, evaluated after the 15:30 KST close). Before placing any order, check the intent with decker.validate_intent.",
"inputSchema": {
"properties": {
"detail": {
"default": false,
"description": "false (default) = per timeframe only `reading` (one Korean line: target, phase, bar role and what the next bar makes it, latest signal, action, next close and what confirms/fails) + `chain` (recent targets' transition chains) + `events[].line`. true = the full structured state (units, levels, ladder, label_next, reverse_pending, …) for reasoning over raw values.",
"type": "boolean"
},
"events_limit": {
"default": 10,
"maximum": 50,
"minimum": 0,
"type": "integer"
},
"symbol": {
"description": "e.g. BTCUSDT, XYZ_GOLDUSD",
"type": "string"
},
"timeframe": {
"description": "Alias for a single-element `timeframes` (backward compatible).",
"enum": [
"30m",
"1h",
"4h",
"8h",
"1d",
"1w"
],
"type": "string"
},
"timeframes": {
"description": "Subset to return. Omit for all timeframes.",
"items": {
"enum": [
"30m",
"1h",
"4h",
"8h",
"1d",
"1w"
],
"type": "string"
},
"type": "array"
}
},
"required": [
"symbol"
],
"type": "object"
},
"name": "decker.get_market_state"
},
{
"description": "Axis③ (Order/Execution) — this user's actual exposure (each open row carries vs_verdict: does the held side match the current symbol verdict, plus `knots` = the decision prices nearest to the price above and below, with which timeframes sit on each — the ORDER in which transactions would be reached, not a probability; `exit_levels` only when the held side matches): real open futures positions (execution_mode=real, with live sl_price/tp_price), virtual (paper) open positions, and the last 10 closed round-trips per mode. This is what your money actually did, distinct from decker.get_signals (axis②, what the engine recommends) — use this before deciding whether to place another order (avoid duplicate/over-exposure) and to check current protective stop/target on a real position.",
"inputSchema": {
"properties": {},
"type": "object"
},
"name": "decker.get_positions"
},
{
"description": "How ONE timeframe looks right now, in plain language: state (phase, this timeframe's key direction, posture GO/WATCH/HOLD — a stance, not an order), mtf.by_tf (the same for other timeframes), narrative, plus `assembly` = the symbol's single verdict (the same one decker.get_assembly returns: direction, action 진입/유지/청산/대기, entry/stop/target). ⚠ `state.direction` is only this timeframe's direction and can differ from `assembly.direction` — for the decision use `assembly` (direction_basis says which is which). For the full detail call decker.get_assembly with detail=true; for the structured per-timeframe judgment use decker.get_market_state. Engine-native raw fields are not exposed here.",
"inputSchema": {
"properties": {
"include_tfs": {
"description": "Comma-separated additional TFs (e.g. '1h,4h,1d').",
"type": "string"
},
"symbol": {
"description": "e.g. BTCUSDT",
"type": "string"
},
"tf": {
"default": "4h",
"enum": [
"15m",
"30m",
"1h",
"4h",
"8h",
"1d",
"1w"
],
"type": "string"
}
},
"required": [
"symbol"
],
"type": "object"
},
"name": "decker.get_reading"
},
{
"description": "Active trading signals for the current user (with Skill Overlay applied), in customer-facing shape: coordinates (entry/target/stop), decision (ENTER/WAIT/SKIP — is_actual_trigger=true only for ENTER; WAIT/SKIP are standing candidates, not executed triggers), action_gate posture (GO/WATCH/HOLD — a stance, not an order command), progress, MTF verdict, and a plain-language summary_ko line. risk_reward_ratio is computed on the DISPLAYED coordinates (after overlay). Signals are retained rather than cut when they age (turn-retention policy) — read freshness_state (open|aged) / age_bars / freshness_sec before treating an old PENDING row as current. Filtered by symbols / min_progress / action_gate — action_gate here filters the CURRENT-MOMENT representative state, it does not search history (almost always 0 rows unless a gate is GO right now); for past GO events with their entry/target/stop and realized performance use decker.get_trigger_history instead. Before placing any order through any execution tool, check the intent with decker.validate_intent.",
"inputSchema": {
"properties": {
"action_gate": {
"description": "Engine action gate filter (3-layer grammar: gate = transition posture, not an order command). Rows where the engine emitted no gate for this bar (effective_action_gate null, e.g. KRX daily) are excluded when this filter is set.",
"enum": [
"GO",
"WATCH",
"HOLD"
],
"type": "string"
},
"limit": {
"default": 20,
"maximum": 100,
"minimum": 1,
"type": "integer"
},
"min_progress": {
"description": "Minimum progress_pct (0-100).",
"maximum": 100,
"minimum": 0,
"type": "number"
},
"symbols": {
"description": "Symbol filter (e.g. ['BTCUSDT','ETHUSDT']). Omit for all.",
"items": {
"type": "string"
},
"type": "array"
},
"timeframe": {
"description": "Signal horizon filter (30m=scalp, 1h=swing, 4h/8h/1d=position). The same symbol can hold OPPOSITE directions on different horizons — omit to get the latest active signal regardless of horizon (its timeframe field says which one you got; when a specific symbols[] was requested, a row's other_horizon_conflict field flags it if another horizon is ACTIVE with the opposite direction). Prefer decker.get_assembly for the composed cross-horizon judgment instead of guessing which horizon to pass here.",
"enum": [
"30m",
"1h",
"4h",
"8h",
"1d"
],
"type": "string"
}
},
"type": "object"
},
"name": "decker.get_signals"
},
{
"description": "ACTION axis — actual historical GO triggers (not standing WATCH/HOLD candidates) for a symbol, with entry/target/stop coordinates and realized performance (mfe_pct/mae_pct/exit_reason/exit_price from trigger_performance, null = still open). Distinct from decker.get_signals (which reflects only the current-moment state, not a searchable history — its action_gate filter answers 'what does symbol×tf look like right now', not 'when did this last fire'). Use this to answer 'what did the engine actually trigger recently and at what price' — decker.get_signals/get_market_state cannot answer that. direction is judgment_signals-native vocabulary (\"long\"/\"short\"), distinct from the \"+\"/\"-\" convention used by other tools — read as-is, no translation.",
"inputSchema": {
"properties": {
"limit": {
"default": 20,
"maximum": 50,
"minimum": 1,
"type": "integer"
},
"since": {
"description": "ISO8601 lower bound on trigger time (exclusive). Optional.",
"type": "string"
},
"symbol": {
"description": "e.g. BTCUSDT",
"type": "string"
},
"timeframe": {
"description": "Optional — omit for all timeframes.",
"enum": [
"30m",
"1h",
"4h",
"8h",
"1d"
],
"type": "string"
}
},
"required": [
"symbol"
],
"type": "object"
},
"name": "decker.get_trigger_history"
},
{
"description": "Trading skill catalog + currently active overlay for this user. Returns 8 published skills (conservative_v0/standard_v0/aggressive_v0/default_v0/scalp_v0/tight_v0/wide_v0/swing_v0) and the user's selected one. Also returns symbol_skills: the symbols where this user's paper account turns the symbol verdict's entry event into an order (turn on/off with decker.set_symbol_skill or REST /auto-order-rules/symbol-skills).",
"inputSchema": {
"properties": {},
"type": "object"
},
"name": "decker.get_user_skills"
},
{
"description": "Ready-to-show Korean status card for a symbol — the same card the daily briefing sends, built from the same consumer contract (CR1) as decker.get_market_state, so direction and prices always agree with it. Shows the timeframes grouped 상위/중간/단기 with one line each (direction + stage + the price that decided it), the nearby prices to watch, and a short explanation of the chosen timeframe (tf, default 4h): what closed beyond what, whether the signal flips the previous one, entry/target/stop. Also returns direction (+/- only while that timeframe's signal is pending or confirmed; a failed or absent signal gives no direction — failure does not assert the opposite side), wait_target, invalidation, ref_price and recent self-scoring verdicts. Use this when you want text to show as-is; use decker.get_market_state when you want structured values to reason over. layer=STATE_VIEW: a market-state reading, NOT a trade instruction. The response carries TWO readings: the timeframe card (`lines`, top-level `direction`/`phase` — that one timeframe's own state, its action words are about that timeframe) and `verdict` (the symbol's single judgment across timeframes — the one to act on). They can differ (e.g. card direction null / '매도 유지' while verdict is '진입'); `direction_basis` says which is which and `direction_basis.differs` flags it. Before placing any order through any execution tool, check the intent with decker.validate_intent.",
"inputSchema": {
"properties": {
"symbol": {
"description": "e.g. BTCUSDT, XYZ_GOLDUSD (crypto + HL TradFi synthetics; KRX daily lineage not yet covered by view v1)",
"type": "string"
},
"tf": {
"description": "Optional view timeframe — the grounded narrative is composed on this TF's bar (e.g. '1h' when the user asks about the 1-hour picture). Omit for the engine's default action TF (usually 4h, same as the daily briefing card).",
"enum": [
"30m",
"1h",
"4h",
"8h",
"1d"
],
"type": "string"
}
},
"required": [
"symbol"
],
"type": "object"
},
"name": "decker.get_view"
},
{
"description": "Axis③ (Order/Execution) — unlike every other tool here, this one moves money. It places a market order through DECKER'S OWN execution engine (same path as the decker-ai.com chat trading UI, source='mcp') — it does NOT hand off to your own broker connection or exchange account; Decker executes using whatever exchange credentials this user has separately linked to their Decker account on the website. execution_mode (virtual|real) is NOT chosen by the caller — it is resolved server-side from this user's account settings (user_settings.execution_mode) AND the platform's real-trading kill switch; a real-money order requires both an explicit user opt-in AND role/tier eligibility (PRO/ENTERPRISE or admin) AND passing the tier's hard notional/leverage/daily-count caps (checked here before dispatch — violation blocks the order, does not downgrade it to virtual). The response always states which mode actually executed — treat 'virtual' in the response as authoritative even if you expected real. Restricted to the crypto-6 universe (BTCUSDT/ETHUSDT/SOLUSDT/BNBUSDT/XRPUSDT/DOGEUSDT) for this MCP path — HL-synthetic and KRX symbols are read-only via other tools. Call decker.validate_intent first to read the engine's current stance; this tool does not check it for you. Positions are tracked as ONE net row per user+symbol+mode, not per order — if you already hold a position on this symbol, this order nets into it and the response's pre_existing_position field says so. A later close_position call closes the combined total, not just what this call added.",
"inputSchema": {
"properties": {
"notional_usd": {
"description": "Order size in USD (quantity = notional_usd / current price). This is the value checked against the account's tier notional cap.",
"exclusiveMinimum": 0,
"type": "number"
},
"side": {
"description": "Order direction (buy/long or sell/short).",
"enum": [
"buy",
"long",
"sell",
"short"
],
"type": "string"
},
"symbol": {
"description": "Crypto-6 only for this MCP write path.",
"enum": [
"BTCUSDT",
"ETHUSDT",
"SOLUSDT",
"BNBUSDT",
"XRPUSDT",
"DOGEUSDT"
],
"type": "string"
}
},
"required": [
"symbol",
"side",
"notional_usd"
],
"type": "object"
},
"name": "decker.place_order"
},
{
"description": "Change active trading skill overlay for this user. Immediately affects all subsequent get_signals calls and downstream channels.",
"inputSchema": {
"properties": {
"skill_id": {
"description": "trading_skills.id (e.g. 'aggressive_v0').",
"type": "string"
}
},
"required": [
"skill_id"
],
"type": "object"
},
"name": "decker.set_skill_overlay"
},
{
"description": "Turn the per-symbol integrated skill on or off for this user's paper (virtual, default) or live (execution_mode=real, quantity required) account. When on, the symbol verdict's entry event (decker.get_assembly) opens an order and the same verdict's exit / opposite-entry events close it — same algorithm in both modes; per-timeframe rules never close a position this skill opened. Defaults: paper notional quantity, engine stop/target. replace_timeframe_rules=true pauses this user's paper per-timeframe rules for the symbol and hands their open positions to the skill (adopted_position_ids); paused_rule_ids restore the rules via enabled=false + restore_rule_ids. Current state: decker.get_user_skills → symbol_skills.",
"inputSchema": {
"properties": {
"enabled": {
"description": "true = on (idempotent), false = off (rule kept, paused).",
"type": "boolean"
},
"execution_mode": {
"description": "virtual (default) = paper account; real = live exchange (Binance USDT-M futures / Hyperliquid), same verdict→order→exit algorithm. With enabled=false: turn off only that mode's skill.",
"enum": [
"virtual",
"real"
],
"type": "string"
},
"horizon": {
"description": "Horizon timeframe to hold: orders every just-born signal at or below it toward that timeframe's next cell (≥2%), exits on that timeframe's action. own (default) = each signal's own timeframe. Omitted = keep.",
"enum": [
"own",
"30m",
"1h",
"4h",
"8h",
"1d",
"1w"
],
"type": "string"
},
"quantity": {
"description": "Optional order size. Omitted = paper default notional. Required when execution_mode=real.",
"type": "number"
},
"replace_timeframe_rules": {
"description": "Pause this user's paper per-timeframe rules for the symbol (default false).",
"type": "boolean"
},
"restore_rule_ids": {
"description": "With enabled=false: re-activate these paused per-timeframe rules.",
"items": {
"type": "string"
},
"type": "array"
},
"symbol": {
"description": "e.g. BTCUSDT, XYZ_GOLDUSD (a symbol with an engine verdict).",
"type": "string"
}
},
"required": [
"symbol",
"enabled"
],
"type": "object"
},
"name": "decker.set_symbol_skill"
},
{
"description": "Axis③ (Order/Execution) — modifies the stop-loss and/or take-profit on an EXISTING open position. There is no cancel_order tool because Decker only places market orders (there is no resting order to cancel) — the actual gap this fills is modifying protective stops on a position you already hold. real: cancels the old exchange stop/take-profit order(s) and places new ones at the given price(s) (new order placed first, old one canceled only after — no unprotected window). virtual: updates the paper position's stop_loss/take_profit columns directly (polled by the paper monitor). Provide at least one of sl_price/tp_price — the other side, if omitted, is left at its current value. If both a real and a virtual position are open for this symbol, pass mode explicitly or the call is rejected asking which one.",
"inputSchema": {
"properties": {
"mode": {
"description": "Only required when both a real and a virtual position are open for this symbol — says which one to modify.",
"enum": [
"real",
"virtual"
],
"type": "string"
},
"sl_price": {
"description": "New stop-loss price. Omit to leave the current stop unchanged.",
"exclusiveMinimum": 0,
"type": "number"
},
"symbol": {
"description": "e.g. BTCUSDT — must be a symbol you currently hold.",
"type": "string"
},
"tp_price": {
"description": "New take-profit price. Omit to leave the current target unchanged.",
"exclusiveMinimum": 0,
"type": "number"
}
},
"required": [
"symbol"
],
"type": "object"
},
"name": "decker.update_protective_stops"
},
{
"description": "Pre-trade gate check for a proposed order intent. Call this BEFORE placing any order through any execution tool (e.g. a broker MCP's review→place flow). Checks the intent (symbol + side) against Decker's deterministic market state: engine action_gate (GO/WATCH/HOLD — a transition posture, not an order command), current structural state, and the active signal's direction / invalidation (stop) coordinates. Returns a stance reading, NOT an approval or rejection: the vocabulary is the engine gate as-is plus a mechanical tf_signal_alignment (aligned/opposed vs the active signal's direction). covered=false means the engine does not emit state for this symbol — treat as unknown, not as HOLD. top-level action_gate can be null even when covered=true — this is not a missing field, it means the current bar has no fresh trigger reading; check gate_null_reason ('no_gate_available' = neither the current bar nor the carried-forward signal had a gate at all, vs 'signal_stale' = a value existed but the underlying signal exceeded the staleness threshold and was deliberately suppressed rather than served as a confident-but-old answer). The order decision and responsibility remain with the calling agent/user. Every check is persisted to an auditable decision ledger (check_id). READ verdict_check FIRST: it compares the intent with the symbol's single verdict (the same one decker.get_assembly returns — direction, action 진입/유지/청산/대기, entry/stop/target, what would change it) and says in summary_ko whether a NEW entry exists now (entry_now) or the stance is only being held. The timeframe-level gate/signal fields below describe one timeframe (default: your open position's) and can be stale. When the symbol verdict is not an entry right now, `signal.is_actual_trigger` is false even if that one timeframe's own signal is ENTER: the timeframe's call is kept in `signal.tf_decision` and `signal.superseded_by` names the verdict action that overrides it. ",
"inputSchema": {
"properties": {
"order_type": {
"description": "Optional, informational (market/limit/…) — recorded in the ledger, does not change the state verdict.",
"type": "string"
},
"side": {
"description": "Proposed order direction (buy/long = +, sell/short = -).",
"enum": [
"buy",
"long",
"sell",
"short"
],
"type": "string"
},
"symbol": {
"description": "e.g. BTCUSDT, SILVER, 테슬라 — aliases resolve to the engine symbol (XYZ_SILVERUSD, XYZ_TSLAUSD, …).",
"type": "string"
},
"timeframe": {
"description": "Gate horizon. Omit = your open position's entry TF if you hold one on this symbol, else decker.get_assembly's entry TF (the single judgment authority's current best-path TF), else the engine's default action TF (4h).",
"enum": [
"30m",
"1h",
"4h",
"8h",
"1d"
],
"type": "string"
}
},
"required": [
"symbol",
"side"
],
"type": "object"
},
"name": "decker.validate_intent"
}
]
}What the leaf hashes
{"body":"2f8059f8d1ff7b90142d02d2bad1b29263b55c1eca896fbff2049219f95fddce","id":3956565,"kind":"mcp.tools","method":"probe.mcp/1","observed_us":1794072365987735,"prev":3694407,"subject":"5998d6ba-d709-4350-8f9c-54bb4f86da04","subject_kind":"endpoint"}Proof
Fold these into the leaf in order, hashing each sorted pair with keccak256, to reach the root of (195826 rows).
- 0x6f576590a26489a1b7bde0ad3abbe76c23c03a3e517788ca0493aae4b2368649
- 0xfb5bc5a82aa6a7680eba28397df87711d149508ad2fc8133f8ea419789152015
- 0x10302eb1eb9b90327fce70f57982b925f294231f2b64c3fcc19df1c47c0e3d2f
- 0xc90821edadd220afb658e539b7d443fae0141eee49d026716e6dd3ed2201ab7a
- 0xbc09db9fe29d1881992602eb131e913ee8959ee22f7030c879df86c4b9e745e9
- 0x677b1c4137a9922633b4869c4fbf63499252d10de239b42d45b91e9236262bac
- 0xcb08e12dfad65ff36fff589d63e011b40503796b78e272abb2c56438bb10e89f
- 0x9b1630ccd577ded521ace77db3571529d369f44435be9d2d02a333b3cee93522
- 0x5f5299e2e99c3baefe965c474771a08afc74102cf6af363864ee5e9d3d35b32e
- 0x11845dc05ec80641edfba51715e03a148eb601ba6b802ec9c987b3ef97f556f1
- 0x92260b40dbcc3226d2f07de6f22b399da222b9c7ae7021642647a255c98cf650
- 0xfa36737101abe14146c268d253e370e1d86682cd81189576035d256a42039c9a
- 0xe5801f2d98f2783a9d774362088619c8104163c840e21fbf269ac5c455e9df78
- 0xe10968763bf5f376ed7bef52309abc0adc0394947582477a2899a3f332842d95
- 0xdda41bf8f8b807884588170276b0203d24918e4a5c47ba7f4d5d0217f85e0cf7
- 0x9108c80d13a11b7549b554924410a7c5d215a2cd03aee9659ca627cb099f1a2e
- 0x3b69f6d98c91b21287021db092e52491474f0d08438393ac130d6a3c273bcd4a
- 0xff23fa8a9de3f957315ef0dfe7e8d8f6b1a51dae05fef7615c59794e019ff05c
- Day root
- 0x17da9e85e1b138541355d33543ff34e3503cd3a49d37728fb53643e2a0416a2d
- Chained
- 0xed34bd4af17282643de8cb9591c84d0aa1b39e1e9ae9864941e543f5a15718cb
- Published
- On Arc Testnet, block 71280839: 0xc3f6784179e0ca32236ba89472473e882a81d03fcc5ce27ca58ded2e01e112aa