Aragon as Technical Signer for 3F

Executive Summary

3F engaged Aragon as an independent technical signer for its multisig operations. The largest body of work, and the focus of this case study, was support for Grunt, 3F's bridge financing protocol, plus hosting for Guardian, a 3F-developed secure signature service.

Grunt's repayment workflow depends on accurate attestations that bridge loans have been repaid according to the terms agreed with lenders. These attestations sit across 3F's loan exposure. At the time of this draft, 3F's public site reported $17.2M in total exposure (3f.xyz, July 21, 2026).

Aragon's role was to provide a signer function with technical controls around it. Aragon reviewed the relevant Grunt contracts, worked with 3F to define fund-level repayment policies, built a production repayer service, hosted supporting signature infrastructure, and operated the AWS environment around the signing path.

At a high level

1. 3F proposes a repayment attestation through its Safe.
2. Aragon's repayer service verifies the proposal, request, repayment evidence, and agreed fund policy.
3. If the proposal is valid, Aragon signs through an AWS KMS-backed signer.
4. If the proposal is incorrect, incomplete, stale, or not yet ready, Aragon does not sign and escalates the case through dedicated channels for manual review with the 3F team.

This case study details the work required to support accurate attestations for a business-critical signing workflow: core requirements, architecture, rollout, monitoring, and escalation.

Core Requirements

Business-critical financial automation requires more than custody of a signer key. For 3F, the signer had to support five requirements.

Architecture

Aragon operated the signing path through a layered multisig architecture and a separate AWS runtime environment.

The multisig setup separates 3F's Safe from Aragon's signer controls. 3F proposes and approves through its own Safe. Aragon's signer seat is backed by an automated repayer service and an Aragon team multisig. The automated path handles the standard repayment flow when the repayer verifies the proposal. The team multisig provides a manual review path staffed by Solidity and security reviewers.

The cloud setup separates public visibility from private signing infrastructure. The dashboard is the only public surface. The repayer, database, KMS signer path, Guardian service, and supporting tasks are not externally reachable.

Secure Infrastructure

1. AWS network and key isolation

   The repayer runs in private subnets with no inbound path. The only public surface is the read-only dashboard, which sits behind TLS and Google sign-in and has no KMS permissions. The signing key never leaves the KMS HSM, and IAM restricts signing to the repayer's task role alone. Each component is granted only the access it needs.

2. AWS KMS-backed signing

   The signer private key is never known to the service operator. It is held in AWS KMS, and the repayer verifies that the configured KMS key derives to the expected EOA address before signing. This gives the system a controlled attack surface around key use, instead of exposing raw key material.

3. RPC quorum reads

   Repayment evidence is read from chain through quorum RPC checks at a pinned block. This reduces reliance on a single RPC provider for correctness-critical reads.

4. Envio indexing with onchain verification

   Envio indexing gives the service fast access to relevant events and transaction pointers. The repayer then re-verifies those pointers against onchain data, which adds redundancy against indexing errors and stale data.

5. Policy-based repayment validation

   Fund-level repayment policies are configured explicitly in agreement with 3F. The service evaluates repayment proposals against those policies before signing. Examples are covered below.

6. At-most-once signing

   The database records a final verdict for each Safe transaction hash. A signed verdict is inserted before broadcast, which prevents duplicate signing even if service instances race or a process restarts mid-flow.

7. Guardian hosting

   Aragon also hosted Guardian, the 3F-developed secure signature service used to generate signatures consumed by onchain transactions. This put the repayment signer and related signature infrastructure under a consistent operational model.

Repayment Policy Work

A major part of the engagement was turning fund-level commercial terms into precise signer policy.

Aragon worked with 3F to define how repayment should be evaluated for different funds and interest treatments. The service supports policies such as daily, monthly, and annualized repayment calculations, with policies mapped to funds in agreement with the 3F team.

This gives the signer a deterministic basis for its decision. If a repayment proposal does not match the agreed policy for that fund, the service does not sign and the case is escalated for manual review.

Example policy considerations

1. Which fund the Request belongs to.
2. Which interest treatment applies to that fund.
3. Whether the proposed repayment amount matches the agreed calculation.
4. Whether small rounding differences are within the expected tolerance.
5. Whether live onchain balances support the proposed attestation.

Rollout

Aragon and 3F rolled out the repayer in stages.

1. Contract and flow review

   Aragon reviewed the Grunt contracts and the repayment path with Solidity experts to understand the signing surface and the consequences of an incorrect attestation.

2. Policy agreement

   Aragon and 3F agreed the repayment policies that should apply at the fund level, including how timing, interest, and rounding should be handled.

3. Dry-run mode

   The service first ran without signing authority. It evaluated proposals and wrote telemetry, allowing decisions to be compared against manual review.

4. Armed mode

   Once the decision path was confirmed, the service was moved into armed mode. Armed mode requires explicit configuration and AWS KMS access. A deployment without KMS cannot be armed by changing one flag.

5. Production monitoring and escalation

   Signed, rejected, and unresolved proposals are visible through the dashboard, logs, Slack alerts, Better Stack, and PagerDuty. Rejections and unresolved cases are escalated for manual review with 3F.

Operations And Reporting

The repayer includes live operational visibility for routine monitoring, incident response, and auditability.

The OAuth-gated dashboard shows the current service mode, latest activity, aborted ticks, signed and rejected verdicts, indexer status, proposal state, and per-proposal event history.

Logs and alerts are routed through the production monitoring stack, including Better Stack, Slack, and PagerDuty. Rejections and unresolved cases are surfaced through dedicated escalation channels so Aragon and 3F can evaluate them manually.

Operators can see what happened, why a proposal did or did not get signed, and what needs human attention.