# Fangorn <> Arbitrum OpenHouse

## Overview

Fangorn is programmable access control infrastructure for agents and humans. It lets you encrypt data under a condition instead of a private key. Our ethos is 'proof over permission', meaning:
- no key management
- extensible & composable conditions
- non-interactive and asynchronous between data publisher and consumer

For this hackathon, we extended our previous work and delivered something entirely brand new: FHE computations over encrypted data gated behind a payment condition, facilitator via x402. That is, it's 'pay-per-insight' over encrypted data.

This extends our previous work, where we provided mechanisms to gate full-plaintext access using payments and other conditions. In this model, data discoverability is accomplished using a combination of a custom 'data source registry' contract and the ERC-8004 registries, where each datasource has an agent card that can be used to find and query the data. While this functions as intended for large data sets, it provides no safe means to let an agent infer intelligence without exposing the entire dataset to the agent. With our latest work, agents can execute functions over private data while:
- not exposing its own private query parameters (e.g. 'How many people have blood type 'A' in the data set?')
- preserving the privacy of the data publisher

The market for this is any domain where data is sensitive but aggregate insight is valuable: healthcare, finance, identity, ML training.

Why now?
FHE has been theoretically promising for a decade and is only recently computationally viable with Fhenix being the first production FHE chain on Arbitrum. At the same time, autonomous agents are becoming real economic actors with x402 emerging as the native payment rail. These two spheres are ripe for collision, but there's no frastructure layer to connect them.

Why us:
We've spent two years building threshold cryptography infrastructure at the protocol level — timelock encryption, verifiable randomness, cross-chain key management on Polkadot. We know what actually breaks at the cryptographic layer, not just the application layer. Fangorn is us taking those hard lessons and shipping them for EVM, where the demand actually is. We're not just researchers who got excited about FHE. We're engineers who have been living in this problem space and saw the moment arrive.

We're building the composable and extensible infrastructure to impose programmable access control conditions.

## How it Works


### Data Discovery

### Contracts

| contract name | address | type |
| --------------|---------|-------|
| Datasource Registry Contract | 0x602aedafe1096004d4db591b6537bc39d7ac71a6 | stylus |
| Settlement Tracker Contract | 0x7c6ae9eb3398234eb69b2f3acfae69065505ff69 | stylus |
| Patient Evaluator Contract (FHE) | 0x1E92cF014b7a078482641136243574172d1D04eA | sol |

### Deployed Services

| service | url |
| --------| ----|
| Facilitator | https://facilitator-133282782456.us-central1.run.app |
| Server | https://server-133282782456.us-central1.run.app |

## What We Delivered

- We replaced our entire encryption implementation with FHEnix/TFHE, removing the hybrid Lit/AES encryption used previously
- modified the fangorn-cli to encrypt data under a specific schema for the sake of the demo - meaning blood types are the only types of data it supports currently (represented by integers 0-7).
- implemented e2e tests to verify that entryptions, executions, and unsealing using the contract works
- We refactored our x402f implementation (fetch + server + facilitator) to be able to handle:
- encrypting values with FHE, serializing them, and passing it along to the facilitator as part of a request body
- execution and unsealing of a computation given that a specific USDC payment has been settled on-chain
- implemented e2e example to verify functionality
- We developed and deployed a FHEnix contract to compute over private blood type data, represented as integers, where BLOOD_TYPES = ["A+", "A-", "B+", "B-", "AB+", "AB-", "O+", "O-"]
- We deployed the latest version of fangorn to npm: https://www.npmjs.com/package/fangorn-fhe-sdk
- deployed to cloudrun
- it all works
- We learned the FHEnix stack inside and out

## What it is Not

It is NOT
- a data marketplace
- a solution purely for agentic defi

## Future Work/Next Steps

# Arbitrum Openhouse Planning

## Day 1: 3/6/2026

Registration link:
https://www.hackquest.io/hackathons/Arbitrum-Open-House-NYC-Founder-House?utm_source=&utm_medium=event&utm_campaign=oh-nyc-founder-house

## Overview

Goals of the hackathon: at the end of the hackathon (sunday, noon), we aim to have enabled an erc20 token ownership gadget that allows encryption under token ownership. The token is called "Arbitrum Openhouse Builders Coin" (AOBC) with an initial supply of 1000 tokens, deployed on Arbitrum Sepolia at .

Prior to the hackathon, we have:
- fangorn with:
- payment gadget
- datasource registration w/ agent cards
- basic CLI
- x402f access server + facilitator
- basic agent tools

### Assumptions:
- 1 publisher to 1 data source

### Tech TODOs
- [ ] (OPTIONAL) Explore fhenix for private payment settlement tracking
- [ ] dao based membership gadget
- [ ] multi-gadget support for the CLI
- [ ] Graphiti Knowledge graph
- May need to incorporate a large LLM (Claude) for data inferrence
- Not sure if Anthropic also offers embedding agents (they probably do)
- [ ] MCP client/server https://hackmd.io/join/note/5U7lrV82WU
- [ ] New Agent tool (Data discovery)

#### (Bells and Whistles) B&Ws
- [ ] Resource server agent is also registered (Reputational reasons)

### Demo TODO:
- [ ] Figure out interesting data
- [ ] WE NEED TO DO A PITCH VID (2 minutes max)
- [ ] demo vid

---
## HARD PIVOT

We have gone all in on FHE.

- [ ] FHEnix contract to compute a function over some data
- [ ] deploy to arbitrum sepolia
- [ ] Modify vault entry struct to store ciphertext hash instead of CID
- [ ] facilitator -> check condition and submit tx to FHENIX contract: if we want to just do payment then we don't really need to do anything here
- [ ] integrate fhenix into fangorn

Big idea:

GIVEN I am a data owner
WHEN I want to allow someone to compute $f$ over a message $m$
THEN I specify an access control 'gadget' $g$ and an NFT $T$
AND I FHE my data and get a hash/pointer
AND I update the datasource registry TX=(g, T, pointer)

GIVEN I am a data executor
WHEN I own the NFT $T$
THEN I can fetch the output of the function $f$ over the messasge $m$

---

# 3/7/2026

NEW PLANNING

- [ ] Deploy FHE contract to Arbitrum Sepolia
- [ ] ensure only the facilitator can call the contract
- [ ] Call the FHE contract from the facilitator context
- [ ] Return sealed result to caller
- [ ] point the x402f repo at fangorn local
- [ ] deploy fangorn-arb-fork to NPM
- [ ] Send message from caller to facilitator
- [ ] Update the CLI
- [ ] Unseal results in langchain tool

WOW ok that day was wild, we got a lot done, but we didn't really document anything.

- deployed contract with real blood type data function
- deployed to npm
- deployed to cloudrun
- it all works

# 3/8/2026