DEV Community: N DIVIJ

The agent I trust is the one that distrusts itself

N DIVIJ — Tue, 25 Aug 2026 14:18:23 +0000

What building a contract-cancellation agent taught me about memory, deterministic gates, and auditable autonomy

I created Reaper and wrote this article for the purposes of entering the All Things Agentic Hackathon.

"Have we seen this before?"

It's one of the most useful questions an experienced person can ask. A lawyer remembers a clause that caused trouble. An accountant remembers a vendor that kept billing after cancellation. An engineer remembers the deployment that failed under eerily similar conditions.

So when I added memory to Reaper — an agent that carries auto-renewal cancellations to completion — I assumed retrieval would be the easy part.

Embed the current clause. Search for similar ones. Show the closest matches. That took a morning.

Deciding what memory was allowed to do took the rest of the week.

Because an agent that remembers past decisions can also inherit past mistakes. Worse, it can quietly convert resemblance into authority:

This clause looks 97% like one we blocked before, so I blocked this one too.

That sounds like judgment. In a system that acts on contracts, it's closer to superstition.

The fix wasn't better prompting. It was architecture.

The expensive difference between "similar" and "the same"

A contract costs $540 a month and renews for another year unless written notice arrives 60 days before the term ends. Miss that window and a small administrative failure becomes a $6,480 mistake.

Reaper's job is to prevent it: read the renewal clause, compute the deadline, sleep until the notice window opens, ask for one human signature, send the notice, then check whether billing actually stopped.

But the model is not permitted to schedule anything just because its answer sounds confident.

Gemini proposes a deadline. A separate deterministic engine — regex and calendar arithmetic, no language model inside — derives the date independently from the same text. The decision is deliberately boring:

model_deadline  = model.read(clause)
engine_deadline = date_engine.derive(clause)

if engine_deadline is ambiguous:
    block("the clause cannot be derived safely")
elif model_deadline != engine_deadline:
    block("the two readings disagree")
else:
    schedule(engine_deadline)

This gate has already caught a real one-day error from the model, live. In contract work, "only one day" is another year of fees.

It also refuses clauses like this one:

written notice no later than sixty (90) days before renewal

A model can invent a plausible reading of that. Reaper can't. The contradiction becomes the result.

That was the original trust boundary: the model may propose, deterministic code decides whether the proposal is safe to act on.

Then I added precedent memory and nearly broke it.

Why useful memory can make an agent less trustworthy

The memory stores clause shapes and what happened to them:

Did the deterministic gate accept or block the clause?
Did the vendor stop billing?
Was a dispute opened?
Did the contract require email, registered post, certified mail, or a portal?
Was this a real obligation, or a labelled test fixture?

Each clause is embedded with gemini-embedding-001 into a 768-dimension vector in BigQuery. At intake, native VECTOR_SEARCH surfaces clauses with similar meaning even when the wording differs — a blocked contradiction, a clean cancellation the vendor honoured, a valid notice the vendor ignored, a contract where email was only ever a courtesy copy.

That's genuinely valuable context. It's also perfectly capable of contaminating the current decision.

Suppose the clause in front of you cleanly says "sixty (60) days," but a highly similar prior clause said "sixty (90) days" and was blocked. Feed that precedent to the model before the gate rules, and the old contradiction anchors the new interpretation. The system starts reasoning by analogy when it should be reading the document in front of it.

So Reaper enforces an ordering rule:

CURRENT CONTRACT
      ↓
DETERMINISTIC GATE
      ↓
VERDICT IS FIXED          ← nothing after this line can change it
      ↓
PRECEDENT LOOKUP
      ↓
ADVISORY CONTEXT FOR THE HUMAN

Memory arrives after the verdict. And a test makes that boundary executable rather than aspirational: a 97%-similar blocked precedent is deliberately returned for a clean clause, and the clean clause must still schedule.

The warning is allowed to say:

A near-identical clause was blocked before because its words disagreed with its numerals. This is prior history, not a verdict.

That last sentence isn't interface copy. It's the permission model, written down.

Store outcomes, not just documents

A vector database full of text answers what looks similar?

An institutional memory has to answer what happened next?

That distinction reshaped the BigQuery schema. Every row keeps the clause and its structured outcome: gate verdict, notice method, final status, whether billing stopped, whether a dispute opened, and the terminal receipt hash where one exists.

The embedding finds the neighbours. The structured fields explain why those neighbours matter — which is how the system tells apart two contracts with nearly identical renewal language:

one was cancelled, and billing stopped;
the other was cancelled correctly, and the vendor charged anyway.

The text is similar. The operational lesson is the opposite.

This generalises. Building memory for a support agent? Store whether the resolution actually worked. A deployment agent? Store whether the rollout was rolled back. A collections agent? Store whether the promised payment arrived.

Retrieval without outcomes is recollection without learning.

Provenance has to survive retrieval

Reaper ships with a labelled corpus of synthetic clause shapes so the memory system can be tested reproducibly. Those rows must never masquerade as customer history.

So every precedent carries its source — fixture, or a real ledger-backed obligation. A seeded example may demonstrate that registered post is required; the product must never imply a real customer previously hit that vendor.

This sounds like metadata housekeeping. It's a trust boundary. Once retrieved text is condensed into a sentence, provenance evaporates — and "a similar contract was blocked before" means something very different from "a synthetic test clause of this shape is expected to be blocked."

If your agent mixes fixtures, simulations, generated data and production history, provenance has to travel with the memory, not live in a README nobody opens.

A missing memory is also a result

Here's a tempting three lines:

try:
    matches = search_memory(clause)
except Exception:
    matches = []

Now "BigQuery was unavailable" and "no similar precedent exists" are indistinguishable. They are not the same fact.

Reaper's lookup fails open: if the table is disabled, expired, unreachable, or the embedding call fails, the contractual verdict is untouched. But the evidence chain records that memory was unavailable, and why. The system distinguishes four states:

memory was consulted, nothing passed the threshold;
memory was disabled;
the embedding could not be created;
BigQuery could not be reached.

An advisory system going down should never block a valid cancellation. It should also never quietly pretend history was checked.

Failure transparency is part of memory design.

The evidence should include restraint

Every material action lands in an append-only SHA-256 hash chain: extraction, precedent consultation, the gate verdict, unprompted wakes, approval, delivery, invoice verification, dispute creation.

But the more interesting receipts describe what the agent didn't do.

The mailbox pipeline reads headers first. Messages that fail its admission rules stay unopened — and those refusals are recorded. When the system declines to inspect a bank statement from an unrelated sender, the refusal becomes evidence of restraint.

The same discipline applies to memory:

memory cannot change the gate;
a failed lookup cannot become "no history";
fixture data cannot become customer history;
raw vectors never enter the operational evidence ledger.

A trustworthy agent should be able to prove not just what it did, but which powers it deliberately declined to use.

Long-running agents spend most of their lives doing nothing

Cancellation exposed a less glamorous problem: waiting.

The agent may read a document today and need to act six months from now. It must not burn tokens, hold a process open, or depend on someone remembering to restart a chat.

So Reaper persists the obligation and sleeps. When the notice window opens it wakes and writes a receipt showing that calendar time — not a human pressing continue — triggered the action. It then pauses at the single point where authority is genuinely required: signing and sending.

That pause survives a process restart, because the invocation and its resume pointer live in persistent state rather than RAM. Killing the server doesn't manufacture a new approval or lose the pending one.

And then production breaks the whole mechanism.

Reaper runs on Cloud Run, which stops the container between requests. An in-process timer works beautifully on my laptop and does precisely nothing on a service that has scaled to zero. An agent whose autonomy depends on a container happening to still be alive is not autonomous.

So the heartbeat comes from outside: Cloud Scheduler calls a /tick endpoint once a minute, and that endpoint runs the same function the local loop runs. Not a second implementation — a separate "scheduled" code path drifts from the one you demo, and then the thing you showed isn't the thing that ships. The alternative was paying for an always-on instance to preserve an illusion the architecture didn't need.

Which leads to a rule I'd carry anywhere:

Human approval should be a durable state transition, not a conversational moment.

If an approval disappears when the process dies, it was never part of the workflow. It was part of the demo.

Five rules I'd reuse in any high-consequence agent

1. Separate proposals from permissions.
The model can recommend an action without holding the authority to execute it.

2. Run deterministic checks before advisory retrieval.
Memory should explain a decision or warn a human — never rewrite facts already established from the current input.

3. Store outcomes with memories.
Similar text is only useful paired with what actually happened.

4. Preserve provenance and failure states.
"Fixture," "production history," "no match," and "search unavailable" are four different facts.

5. Test the boundaries, not the happy path.
The important test isn't whether memory returns a match. It's whether an alarming match can improperly change the verdict.

The agent I trust is the one that distrusts itself

We usually describe capable agents by listing what they can do. I've become more interested in the opposite list:

The model cannot schedule its own date.
A contradictory clause cannot be resolved by confidence.
Similar history cannot overrule current evidence.
A missing lookup cannot pretend to be an empty result.
A process restart cannot erase a pending human decision.
A scaled-to-zero container cannot excuse a missed deadline.
An unread message cannot quietly become a read one.

That negative space is where trust comes from.

Memory makes an agent more experienced. Boundaries stop that experience from hardening into prejudice.

Determinism is not the opposite of agency. It is what makes agency defensible.

Reaper is my solo entry for the All Things Agentic Hackathon.

Live: https://reaper-t2w3ltp6fa-uc.a.run.app
Code: https://github.com/N-45div/Reaper

Built with Google ADK · Gemini 3.5 Flash · Gemma 4 · gemini-embedding-001 · gemini-3.5-transcribe · Cloud Run · Firestore · Cloud SQL · BigQuery · Cloud Scheduler

Building Missio: An Evidence-Bound Remediation Agent with SigNoz

N DIVIJ — Sun, 26 Jul 2026 11:51:55 +0000

A production error is exactly when an AI agent should be least creative.

That sentence became the design rule behind Missio, a terminal mission control system I built for the Agents of SigNoz hackathon. Missio starts with a real incident reported in Slack, reconstructs what happened from SigNoz, finds the exact source revision that produced the failure, asks an agent for a tightly bounded change, and opens a draft pull request only after a human approves the action.

The entire journey stays visible in one Rust TUI:

SIGNAL → EVIDENCE → CODE → PATCH → HUMAN → PR → CI → HANDOFF

This is not a dashboard with an AI summary beside it. Every stage represents something the system has actually observed or completed. If evidence is missing, the mission stops. If GitHub cannot
resolve the production revision, it stops. If the model returns an unsafe patch, it stops.

Why Incident Agents Need Evidence, Not Confidence

Observability tools are already good at showing that a request failed. The harder question is what an agent should be allowed to do next.

An error message alone does not establish which code was deployed. A repository's default branch may have moved since the failure. A model can produce a convincing explanation using the wrong version of a file. It can also quietly fill missing context with assumptions.

I wanted the opposite behavior. Missio should be useful only when it can build a chain from a production signal to a specific piece of source code. The agent's job is to reason inside that chain, not invent one.

That made SigNoz the evidence system of record rather than a decorative integration.

Turning a Real Checkout Failure Into a Mission

For the demo, I use an instrumented checkout service. A bad discount request reaches a real HTTP endpoint and produces a failing OpenTelemetry span. The span is exported to SigNoz with the normal service and error fields, plus the details Missio needs to connect runtime behavior to source:

The affected resource;
The environment;
The code file and function;
The repository URL;
The full Git commit running in production.

Then an operator opens the incident from an allowlisted Slack channel:

/missio-sev SEV1 service production/checkout checkout requests are failing

Slack is only the admission point. The message does not tell the agent what the root cause is, and Missio does not treat the wording as evidence. It uses the resource and incident window to query the corresponding telemetry in SigNoz.

The Indexing Delay That Changed the Design

The most useful lesson from building Missio did not come from reading documentation. It came from a demo that failed even though every individual component appeared healthy.

The checkout service successfully exported its span. SigNoz accepted the telemetry. But Missio queried immediately and received no matching rows. A short time later, the same query returned the failure exactly as expected.

Ingestion acceptance and query availability are not the same moment.

That distinction sounds small, but it changes the behavior of an autonomous workflow. If an empty first response means “there was no incident,” the agent can discard a genuine production failure.

If the system waits forever, the operator cannot tell whether it is making progress.

Missio now performs bounded evidence acquisition and makes the wait visible in the TUI. It retries for a limited period while SigNoz indexes the span. If a valid evidence bundle still cannot be formed, the EVIDENCE stage fails closed. It never replaces missing telemetry with a fabricated
incident just to keep the animation moving.

This was also why I kept the signal horizon at the bottom of the interface. The operator can see whether Missio is listening, acquiring evidence, or holding because the observation is incomplete.

Letting Telemetry Choose the Source

Once the trace is available, Missio extracts the repository and the full deployed commit from the span. That commit matters more than the current state of the default branch: it identifies the code that actually produced the observed failure.

Missio reads the repository tree at that immutable revision and selects source linked to the observed code location. In a monorepo, it can keep the investigation inside the affected service. Only that bounded context reaches the agent.

This gives the model a much more honest question:

Given this observed failure and the exact source that produced it, is there enough evidence for a small fix?

The model can either hold the mission or propose replacement content for source it was given. It cannot add an unrelated file, edit the CI workflow, reach outside the service boundary, or claim that an external action succeeded. Those decisions are enforced by Rust after the model responds.

Missio uses Rig for the agent runtime and an explicitly configured model through OpenRouter. The model never receives Slack, SigNoz, or GitHub credentials.

Making the TUI an Authority Boundary

I originally thought of the interface as the visual identity of the project: a mission-control orbit instead of another grid of cards and tables. While building the real workflow, it became something more useful.

The TUI shows who currently has authority.

SigNoz can provide evidence. The agent can propose a patch. Neither can create a pull request. When a proposed change passes policy, the mission pauses at HUMAN and shows the target repository. The operator must explicitly approve one draft-PR attempt.

That approval is deliberately narrow. It does not authorize a merge or deployment. If GitHub rejects the request, Missio preserves the mission and returns control to the human instead of silently repeating a mutation.

Ending at Handoff, Not Pretending Recovery

After approval, Missio creates a branch and draft pull request from the production revision identified by SigNoz. The evidence digest travels into the pull request, connecting the proposed change back to the incident that caused it.

Missio then watches GitHub CI for the exact draft commit. When the checks pass, the final state is HANDOFF.

That wording is intentional. Missio does not pretend that a green check means production has recovered. It tells the operator that an evidence-bound draft is ready for normal review, merge, and deployment. The pull request remains the place where engineers can inspect the change and make
the final call.

I considered extending the demo through automatic deployment, but it would have weakened the product's trust model. A hackathon animation should not manufacture authority that the real system
does not have.

What SigNoz Made Possible

Without SigNoz, this would be a code agent triggered by a Slack message. With SigNoz, the agent is grounded in an observed resource, time window, trace, code location, repository, and deployed revision.

That context affects every later step:

It decides whether a mission exists;
It decides which source can be read;
It constrains what the agent can change;
It binds the draft pull request back to production evidence.

The deepest lesson for me was that agent observability is not only about tracing what a model did. Observability can also control what the model is allowed to do next.

Missio still leaves the final operational decision with a person. Its job is to turn a noisy incident into a reviewable, evidence-bound change without hiding the gaps along the way.

You can explore Missio on GitHub.

If you want to trace the pieces I built on, the most useful references were the SigNoz guides for

Building CanopySplit: A Deep Dive into Octant V2 Yield Donating Strategies

N DIVIJ — Sun, 09 Nov 2025 22:02:34 +0000

Introduction

CanopySplit is a multi-layer DeFi protocol that transforms idle capital into climate impact. Users deposit WETH, earn yield through Aave v3, and automatically split 100% of profits among climate recipients—all while keeping their principal withdrawable at any time.

This technical deep-dive covers:

Octant V2 Yield Donating Strategy architecture
ERC-4626 vault integration with Aave v3
Epoch-based donation splitting mechanics
Custom Uniswap v4 hook for swap fee donations
Production deployment challenges on Sepolia

Live on Sepolia:

Strategy: 0x0D1d8AE2dD0e4B06ca0Ef2949150eb021cAf6Ce9
Splitter: 0xda5fA1c26Ec29497C2B103B385569286B30EC248
Asset (WETH): 0xC558DBdd856501FCd9aaF1E62eae57A9F0629a3c

Architecture Overview

┌─────────────┐
│ User Wallet │
└──────┬──────┘
       │ deposit WETH
       ▼
┌──────────────────────────────┐
│ Aave4626YieldDonatingStrategy│ (ERC-4626 vault)
│ - Deposits to Aave v3        │
│ - Mints shares to users      │
│ - Reports profit → splitter  │
└──────────────┬───────────────┘
               │ mint donation shares
               ▼
┌──────────────────────────────┐
│ TriSplitDonationSplitter     │
│ - Holds strategy shares      │
│ - Epoch-based allocation     │
│ - 3 climate recipients       │
└──────┬───────────────────────┘
       │ distribute()
       ▼
┌─────────────────────────────────┐
│ Recipients (50% / 30% / 20%)    │
│ - Planters                      │
│ - MRV (Monitoring/Verification) │
│ - Maintenance                   │
└─────────────────────────────────┘

Part 1: Octant V2 Yield Donating Strategy

The Core Concept

Octant V2 introduces Yield Donating Strategies (YDS), which extend ERC-4626 with donation mechanics:

interface IYieldDonatingStrategy is IERC4626 {
    function report() external returns (uint256 profit, uint256 loss);
    function setDonationSplitter(address splitter) external;
}

Key innovation: When report() is called:

Calculate profit = currentAssets - lastRecordedAssets
If profit > 0: Mint shares to splitter (not to users!)
If loss > 0: Burn donation shares first, protecting user capital

This means:

Users keep 100% of principal
Donations absorb losses first
No performance fees

Implementation: Aave4626YieldDonatingStrategy

We built an ERC-4626 wrapper around Aave v3:

contract Aave4626YieldDonatingStrategy is YieldDonatingTokenizedStrategy {
    IERC4626 public immutable vault; // ATokenVault

    constructor(
        IERC20 asset_,
        IERC4626 vault_,
        string memory name_,
        address management_,
        address keeper_
    ) YieldDonatingTokenizedStrategy(asset_, name_, management_, keeper_) {
        vault = vault_;
        asset_.forceApprove(address(vault_), type(uint256).max);
    }

    function totalAssets() public view override returns (uint256) {
        uint256 shares = vault.balanceOf(address(this));
        return vault.convertToAssets(shares);
    }

    function _deployFunds(uint256 amount) internal override {
        vault.deposit(amount, address(this));
    }

    function _freeFunds(uint256 amount) internal override {
        vault.withdraw(amount, address(this), address(this));
    }
}

Why ERC-4626?

Composability: Any ERC-4626 vault can plug in
Non-rebasing: Fixed shares, yield in convertToAssets()
Safety: Vault enforces supply caps and liquidity checks

The report() Flow

function report() external onlyKeepers returns (uint256 profit, uint256 loss) {
    uint256 currentAssets = totalAssets();
    uint256 lastAssets = lastRecordedAssets;

    if (currentAssets > lastAssets) {
        profit = currentAssets - lastAssets;

        // Mint shares to splitter (donation\!)
        uint256 sharesToMint = convertToShares(profit);
        _mint(donationSplitter, sharesToMint);

        emit Reported(profit, 0);
    } else if (currentAssets < lastAssets) {
        loss = lastAssets - currentAssets;

        // Burn donation shares first
        uint256 splitterShares = balanceOf(donationSplitter);
        uint256 splitterAssets = convertToAssets(splitterShares);

        if (splitterAssets >= loss) {
            uint256 sharesToBurn = convertToShares(loss);
            _burn(donationSplitter, sharesToBurn);
        } else {
            _burn(donationSplitter, splitterShares);
            // Remaining loss socialized across all shares
        }

        emit Reported(0, loss);
    }

    lastRecordedAssets = totalAssets();
}

Critical insight: Minting shares (instead of transferring assets) means donations continue earning yield until distributed.

Part 2: Aave v3 Integration

ATokenVault: ERC-4626 Wrapper for Aave

contract ATokenVault is ERC4626, Ownable {
    IPool public immutable aavePool;
    IERC20 public immutable aToken;

    constructor(
        IERC20 asset_,
        IPoolAddressesProvider provider
    ) ERC4626(asset_) ERC20("Aave WETH Vault", "aWETHv") {
        aavePool = IPool(provider.getPool());
        aToken = IERC20(aavePool.getReserveData(address(asset_)).aTokenAddress);
    }

    function totalAssets() public view override returns (uint256) {
        return aToken.balanceOf(address(this)); // aTokens auto-accrue
    }

    function _deposit(address caller, address receiver, uint256 assets, uint256 shares) 
        internal override 
    {
        SafeERC20.safeTransferFrom(asset(), caller, address(this), assets);
        SafeERC20.forceApprove(asset(), address(aavePool), assets);

        aavePool.supply(address(asset()), assets, address(this), 0);

        _mint(receiver, shares);
        emit Deposit(caller, receiver, assets, shares);
    }

    function _withdraw(address caller, address receiver, address owner, uint256 assets, uint256 shares) 
        internal override 
    {
        if (caller \!= owner) {
            _spendAllowance(owner, caller, shares);
        }

        _burn(owner, shares);
        aavePool.withdraw(address(asset()), assets, receiver);

        emit Withdraw(caller, receiver, owner, assets, shares);
    }
}

Deployed on Sepolia:

Vault: 0x6938238e57CBe1b4B51Eb3B51389cEf8d3a88521
Asset: WETH (0xC558DBdd856501FCd9aaF1E62eae57A9F0629a3c)
Aave Provider: 0x012bAC54348C0E635dCAc9D5FB99f06F24136C9A

Part 3: TriSplit Donation Splitter

Epoch-Based Allocation

struct Recipient {
    address addr;
    string role;
}

struct Policy {
    uint256 epoch;
    uint256[3] basisPoints; // [5000, 3000, 2000] = 50%, 30%, 20%
}

contract TriSplitDonationSplitter {
    Recipient[3] public recipients;
    Policy public currentPolicy;
    Policy public upcomingPolicy;
    IERC4626 public vault;

    function distribute() external {
        uint256 shares = vault.balanceOf(address(this));
        uint256 assets = vault.redeem(shares, address(this), address(this));

        uint256[3] memory amounts;
        for (uint256 i = 0; i < 3; i++) {
            amounts[i] = (assets * currentPolicy.basisPoints[i]) / 10_000;
            IERC20(vault.asset()).safeTransfer(recipients[i].addr, amounts[i]);
        }

        emit Distributed(currentPolicy.epoch, amounts, recipients);
    }

    function rollEpoch() external onlyOwner {
        currentPolicy = upcomingPolicy;
        upcomingPolicy.epoch++;
        emit EpochRolled(currentPolicy.epoch);
    }

    function setUpcomingPolicy(uint256[3] calldata bps) external onlyOwner {
        require(bps[0] + bps[1] + bps[2] == 10_000, "Must sum to 100%");
        upcomingPolicy.basisPoints = bps;
        emit UpcomingPolicySet(upcomingPolicy.epoch, bps);
    }
}

Why epochs?

Recipients know their allocation in advance
Owner can adjust future weights without disrupting current distributions
Full on-chain transparency via events

Current allocation:

Planters: 50% (0xF9b2eFCAcc1B93c1bd7F898d0a8c4b34aBD78E53)
MRV: 30% (0x9261432cab3c0F83E86fa6e41E4a88dA06E7ecc6)
Maintenance: 20% (0x89C13e8e5a81E775160322df9d7869893926A8Cc)

Part 4: Uniswap v4 Hook (Local PoC)

Extending Donations to Swap Fees

contract TriSplitDonationHook is BaseHook {
    struct HookConfig {
        address donationTarget;
        uint256 donationBps; // 100 = 1%
    }

    mapping(PoolId => HookConfig) public configs;

    function afterSwap(
        address,
        PoolKey calldata key,
        IPoolManager.SwapParams calldata params,
        BalanceDelta delta,
        bytes calldata
    ) external override returns (bytes4, int128) {
        PoolId poolId = key.toId();
        HookConfig memory config = configs[poolId];

        if (config.donationTarget \!= address(0)) {
            Currency currency = params.zeroForOne ? key.currency0 : key.currency1;

            uint256 amountIn = params.zeroForOne 
                ? uint256(int256(-delta.amount0())) 
                : uint256(int256(-delta.amount1()));

            uint256 donation = (amountIn * config.donationBps) / 10_000;

            poolManager.take(currency, config.donationTarget, donation);

            emit DonationExecuted(poolId, donation, config.donationTarget);
        }

        return (this.afterSwap.selector, 0);
    }
}

Testing on Anvil:

# Deploy v4 infrastructure
forge script script/00_DeployV4.s.sol --broadcast --rpc-url http://127.0.0.1:8545

# Deploy hook
forge script script/00_DeployHook.s.sol --broadcast --rpc-url http://127.0.0.1:8545

# Initialize pool
forge script script/05_EnsureInitialized.s.sol --broadcast --rpc-url http://127.0.0.1:8545

# Add liquidity
forge script script/02_AddLiquidity.s.sol --broadcast --rpc-url http://127.0.0.1:8545

# Configure hook (1% donation)
forge script script/04_SetHookConfig.s.sol --broadcast --rpc-url http://127.0.0.1:8545

# Execute swap (triggers donation\!)
forge script script/03_Swap.s.sol --broadcast --rpc-url http://127.0.0.1:8545

Part 5: Frontend Architecture

Dynamic Asset Detection

Instead of hardcoding USDC/WETH, we read the asset dynamically:

export function useAssetInfo(strategyAddress: Address) {
  const { data: assetAddress } = useReadContract({
    address: strategyAddress,
    abi: StrategyABI,
    functionName: 'asset',
  });

  const { data: symbol } = useReadContract({
    address: assetAddress,
    abi: ERC20ABI,
    functionName: 'symbol',
  });

  const { data: decimals } = useReadContract({
    address: assetAddress,
    abi: ERC20ABI,
    functionName: 'decimals',
  });

  return { assetAddress, symbol, decimals };
}

Benefits:

Works with any ERC-20 asset
No frontend redeployment needed
Correct decimal formatting

Role-Based Access Control

function AppPage() {
  const { address } = useAccount();
  const { data: management } = useReadContract({
    address: ADDRS.sepolia.strategy,
    abi: StrategyABI,
    functionName: 'management',
  });

  const isManagement = address === management;

  return (
    <>
      <DepositForm />
      <WithdrawForm />

      {isManagement && (
        <Button onClick={handleReport}>Report Profit/Loss</Button>
      )}
    </>
  );
}

Event Tracking

export function useLifetimeDonations(splitterAddress: Address) {
  const { data: logs } = useContractEvent({
    address: splitterAddress,
    abi: SplitterABI,
    eventName: 'Distributed',
    fromBlock: 0n,
  });

  const totalDonated = useMemo(() => {
    if (\!logs) return 0n;
    return logs.reduce((sum, log) => {
      const [epoch, amounts] = log.args;
      return sum + amounts.reduce((a, b) => a + b, 0n);
    }, 0n);
  }, [logs]);

  return { totalDonated, eventCount: logs?.length ?? 0 };
}

Real-World Challenges

Challenge 1: Sepolia Gas Cap (16.7M)

Problem: Contract creation bytecode exceeded Sepolia's per-tx gas limit.

Solution:

# foundry.toml
optimizer = true
optimizer_runs = 1
via_ir = false
bytecode_hash = "none"
cbor_metadata = false

forge clean && forge build
forge create YieldDonatingTokenizedStrategy --gas-limit 0xFD0000 --legacy

Challenge 2: WETH Pivot

Problem: Aave v3 Sepolia USDC had supply cap issues.

Solution: Switched to WETH (18 decimals, no supply cap).

export USDC_UNDERLYING=0xC558DBdd856501FCd9aaF1E62eae57A9F0629a3c  # WETH\!

Challenge 3: Permit2 Allowance

Problem: Swaps reverted with InsufficientAllowance.

Root cause: Granted allowance to PoolManager, but Router calls transferFrom().

Solution:

// Grant allowance to Router, not PoolManager
permit2.approve(address(token0), address(swapRouter), type(uint160).max, type(uint48).max);

Challenge 4: Token Decimals

Problem: USDC (6 decimals) vs WETH (18 decimals) mismatches.

Solution: Created patching script for local testing:

FakeUSDC fake = new FakeUSDC(); // decimals() = 6
vm.etch(token0Addr, address(fake).code);

Key Innovations

Epoch-Based Splits: Unlike single-recipient YDS, we route to 3 recipients with dynamic weights
Multi-Adapter Support: Idle, Aave v3, and ERC-4626 strategies all feed the same splitter
Dynamic Asset Detection: Frontend works with any ERC-20 without hardcoding
Hooks Integration: Extended YDS concept to Uniswap v4 swap fees
Loss Protection: Donation shares burn first, protecting user capital

Conclusion

CanopySplit demonstrates how Octant V2's Yield Donating Strategies can be extended with:

Multi-protocol integrations (Aave v3, Uniswap v4)
Flexible donation mechanics (epoch-based splits, loss protection)
Production-ready UX (dynamic asset detection, role-based access)

The architecture is composable, transparent, and gas-efficient. All code is open-source and ready for judges to test.

Key takeaways for builders:

ERC-4626 is the perfect abstraction for yield strategies
Epoch-based policies provide flexibility without disrupting current operations
Dynamic asset detection makes frontends future-proof
Testnet gas limits are real—optimize aggressively
Always verify contract addresses exist on-chain before trusting deployment logs

Resources

GitHub: https://github.com/N-45div/CanopySplit
Sepolia Strategy: 0x0D1d8AE2dD0e4B06ca0Ef2949150eb021cAf6Ce9
Sepolia Splitter: 0xda5fA1c26Ec29497C2B103B385569286B30EC248
Octant V2 Docs: docs.octant.app

Built with ❤️ for the Octant V2 hackathon. Questions? Reach out on Twitter @godlovesu_n

Introducing "Resilient Response" - Empowering Disaster Relief and Management

N DIVIJ — Wed, 16 Aug 2023 08:14:21 +0000

Hey there, fellow developers and enthusiasts of this beautiful Dev Community

I'm thrilled to introduce you to a project that's very close to my heart - "Resilient Response", an open-source application designed to revolutionize disaster relief and management efforts. 🚀

🔗 Links:

Website: https://resilient-response.vercel.app/
GitHub:

N-45div / Resilient-Response

Our team is excited to announce the development of a cutting-edge web application both for mobile and desktop for the GDSC Solution Challenge 2023. With a mission to empower communities to withstand and recover from natural disasters, our app focuses on building resilience through innovative technology.

Resilient Response

Resilient Response is a web application developed to foster connectivity and provide vital information during periods of crisis. This application was conceived as part of the 2023 Solution Challenge, which aligns with the overarching mission to address the United Nations' 17 Sustainable Development Goals by leveraging Google technology. The Resilient Response web app offers users the ability to register and access chat interfaces to stay informed about events occurring in their geographic area. In addition to real-time weather updates, the application also displays the locations of available shelters during times of emergency.

Our video presentation Live Demo

Our team is excited to announce the development of a cutting-edge web application both for mobile and desktop for the GDSC Solution Challenge 2023. With a mission to empower communities to withstand and recover from natural disasters, our app focuses on building resilience through innovative technology.We believe that by harnessing the…

View on GitHub

Project Overview:
Disasters can strike unexpectedly and wreak havoc on communities. The key to minimizing their impact lies in effective coordination and rapid response. This is where Resilient Response comes in. It's a powerful application that combines cutting-edge technology with a user-friendly interface to streamline disaster relief operations.

Key Features:

🗺️ Geolocation Integration: With the integration of geolocation services, "Resilient Response" allows responders to locate the nearest available shelters relative to the user's current position. This functionality ensures efficient utilization of resources and quicker response times.

📱 Mobile Compatibility: In disaster scenarios, being able to access vital information on-the-go is crucial. Resilient Response is designed to work seamlessly on mobile devices, ensuring that responders can stay connected and informed, even in challenging environments.

💡 Open Source Collaboration: Resilient Response is an open-source project, driven by collaboration and community involvement. Developers from all backgrounds can contribute to its growth, enhancing its capabilities and extending its reach.

🎨 Design and User Experience: Create intuitive interfaces that empower users to navigate through critical information effortlessly, even in stressful situations.

Innovative Hand Gesture Recognition: Utilizing TensorFlow, a powerful machine learning framework, we've developed an intelligent algorithm that can identify and interpret hand gestures even in low-light or dark environments. This allows survivors to communicate their presence and condition to rescuers without relying solely on verbal communication, which might not be feasible in noisy or chaotic situations.

Why Hand Gestures?
Hand gestures are a universal form of communication that transcends language barriers. By incorporating this technology into "Resilient Response," we're enabling survivors, including those who might be injured or unable to speak, to make themselves understood and request assistance in a clear and intuitive way.

🤖 Machine Learning Enthusiasts: If you have expertise in machine learning, TensorFlow, or computer vision, your insights and skills can help us refine and enhance the hand gesture recognition algorithm.

🧩 Testing and Feedback: We're actively seeking individuals who can test the hand gesture recognition feature in various environments and provide valuable feedback for improvements.

Current Status and Future Vision of "Resilient Response"

Current Status:
As of now, the "Resilient Response" project has reached a significant milestone. The core features that form the foundation of the application are in place and have been rigorously tested. Our team has poured countless hours into refining the user interface, optimizing performance, and ensuring the application's reliability, even in challenging scenarios.

We've received valuable feedback from early users and collaborators, which has helped us fine-tune the user experience and identify areas for improvement. The project's GitHub repository has been bustling with activity, showcasing the collective efforts of developers who believe in the mission of enhancing disaster relief and management.

Looking Forward:
While we've come a long way, there's still much to be done. Our vision for the future of "Resilient Response" is bold and ambitious, and we're excited to share some of the key areas we're focusing on:

🌐 Real-time Communication: Resilient Response provides a platform for real-time communication between first responders, volunteers, and affected individuals. Whether it's sending alerts, sharing critical information, or coordinating rescue missions, the application ensures that everyone is on the same page.

🌟 Enhanced User and Community Customization: We're working on expanding the application's customization options, allowing different organizations and regions to tailor the platform to their specific needs. Flexibility is key, as each disaster scenario is unique.

🗺️ Geospatial Mapping: With integrated geospatial mapping, Resilient Response enables responders to visualize affected areas, assess damage, and plan their actions more efficiently. The map-based interface enhances decision-making and resource allocation.

🔗 Integration with Emergency Services: Our goal is to forge partnerships with emergency services and governmental agencies to seamlessly integrate "Resilient Response" into their operations. This collaboration can lead to more coordinated and efficient disaster response efforts.

🔮 Predictive Analytics: Leveraging the power of data, we aim to develop predictive models that can forecast disaster trends and help communities prepare in advance. This proactive approach can save lives and resources.

📚 Comprehensive Documentation: As the project evolves, we understand the importance of clear and comprehensive documentation. We're investing in creating resources that make it easy for developers to understand and contribute to the project.

Join Us in Shaping the Future:
I'm extending an open invitation to all of you to be a part of this exciting journey. Your skills, insights, and passion can contribute to the success of "Resilient Response" in ways that are beyond measure. Whether you're a seasoned developer, a creative designer, a data aficionado, or someone who simply cares deeply about making a positive impact, there's a role for you here.

Let's continue collaborating on GitHub, engaging in discussions, and pushing the boundaries of what technology can achieve in disaster relief and management. Together, we can make a tangible difference in the lives of people around the world.

If you have any questions, ideas, or suggestions, please don't hesitate to reach out. Together, we can make a significant impact!

Once again 🔗 Links:

Website: https://resilient-response.vercel.app/
GitHub: Resilient Response

Thank you for reading the post .. Have a great day ahead !

DEV Community: N DIVIJ

The agent I trust is the one that distrusts itself

What building a contract-cancellation agent taught me about memory, deterministic gates, and auditable autonomy

The expensive difference between "similar" and "the same"

Why useful memory can make an agent less trustworthy

Store outcomes, not just documents

Provenance has to survive retrieval

A missing memory is also a result

The evidence should include restraint

Long-running agents spend most of their lives doing nothing

Five rules I'd reuse in any high-consequence agent

The agent I trust is the one that distrusts itself

Building Missio: An Evidence-Bound Remediation Agent with SigNoz

Why Incident Agents Need Evidence, Not Confidence

Turning a Real Checkout Failure Into a Mission

The Indexing Delay That Changed the Design

Letting Telemetry Choose the Source

Making the TUI an Authority Boundary

Ending at Handoff, Not Pretending Recovery

What SigNoz Made Possible

Building CanopySplit: A Deep Dive into Octant V2 Yield Donating Strategies

Introduction

Architecture Overview

Part 1: Octant V2 Yield Donating Strategy

The Core Concept

Implementation: Aave4626YieldDonatingStrategy

The report() Flow

Part 2: Aave v3 Integration

ATokenVault: ERC-4626 Wrapper for Aave

Part 3: TriSplit Donation Splitter

Epoch-Based Allocation

Part 4: Uniswap v4 Hook (Local PoC)

Extending Donations to Swap Fees

Part 5: Frontend Architecture

Dynamic Asset Detection

Role-Based Access Control

Event Tracking

Real-World Challenges

Challenge 1: Sepolia Gas Cap (16.7M)

Challenge 2: WETH Pivot

Challenge 3: Permit2 Allowance

Challenge 4: Token Decimals

Key Innovations

Conclusion

Resources

Introducing "Resilient Response" - Empowering Disaster Relief and Management

N-45div / Resilient-Response

Resilient Response