https://github.com/reallyunintented/molttrade-contracts
Public contract kernel for MoltTrade, centered on bilateral settlement and policy registration.
https://github.com/reallyunintented/molttrade-contracts
defi foundry settlement smart-contracts solidity
Last synced: 12 days ago
JSON representation
Public contract kernel for MoltTrade, centered on bilateral settlement and policy registration.
- Host: GitHub
- URL: https://github.com/reallyunintented/molttrade-contracts
- Owner: reallyunintented
- License: mpl-2.0
- Created: 2026-04-08T20:05:00.000Z (3 months ago)
- Default Branch: main
- Last Pushed: 2026-04-21T00:26:30.000Z (3 months ago)
- Last Synced: 2026-04-21T02:37:04.461Z (3 months ago)
- Topics: defi, foundry, settlement, smart-contracts, solidity
- Language: Solidity
- Size: 154 KB
- Stars: 0
- Watchers: 0
- Forks: 1
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# MoltTrade Contracts
Public contracts slice for MoltTrade.
This repo is the narrow on-chain trust boundary only:
- `PolicyRegistry.sol`: owner-managed agent policy registry
- `BilateralSettlement.sol`: bilateral EIP-712 settlement contract
- Foundry tests for replay, revoke/pause, fee config, counterparty binding,
per-token sell caps, fee-on-transfer handling, and reentrancy
- Base deployment scripts, including a generic `deploy-v2` helper that writes a
public `molttx.manifest.json`
This repo does not include the relayer, hosted APIs, frontend, runtime daemon,
or alpha operations tooling. Those are intentionally excluded so the public
artifact stays focused on the part that actually enforces settlement rules.
## Scope
MoltTrade is a non-custodial bilateral settlement model for agent trading.
Core invariant:
`1 owner : 1 active agent : 1 active policy`
What the contracts do:
- owners register a bounded trading policy
- agents sign typed settlement intents with a per-intent `maxFeeBps`
- settlement checks policy validity, replay protection, counterparties, fees,
sell-token caps, and token compatibility
- tokens move directly between owner wallets
What the contracts do not do:
- custody funds
- run orderbooks
- discover counterparties
- provide hosted relaying or frontend UX
## Policy Model
The current policy shape is V2:
- `allowedSellTokens[]` defines which sell tokens are permitted
- `maxSellAmountsPerToken[]` is index-aligned with `allowedSellTokens[]`
- if a sell token is not listed, the trade is rejected
- if a listed token has cap `0`, that token is allowed but uncapped
- duplicate sell tokens are rejected on policy registration
## Fee Trust Boundary
- each signed settlement intent carries `maxFeeBps`, not a fixed `feeRecipient`
- the contract applies the current onchain `feeBps` and `feeRecipient` at settle time
- settlement is rejected if the live fee exceeds either side's signed `maxFeeBps`
- a signer therefore bounds fee magnitude onchain, but still trusts the contract owner
to choose the live fee recipient and not reroute fees in an unexpected way
Caps are enforced in raw token units. The contracts do not do any USD/notional
conversion.
## Security Assumptions
- owner key compromise is out of scope for the contracts themselves
- agent signatures are trusted only while the owner's onchain policy is active
- stale intents are invalidated by per-owner nonce and `policyNonce` checks
- settlement is bilateral and non-custodial; funds move directly between owner wallets
- open-fill settlement is not supported; counterparties must be explicit
- the fee recipient is an owner-controlled runtime parameter; only the fee ceiling
is signed inside intents
- sell caps are enforced in raw token units, not USD or oracle-priced notionals
- fee-on-transfer behavior is checked by actual post-transfer balance deltas
- the contracts are not publicly audited
## Status
This is real code, but it is still early-stage infrastructure.
- intended first chain: Base-style deployment environments
- intended first usage: narrow invited-alpha style operation
- audit status: not publicly audited
## Deployment Status
- current public release line: `v0.2.0`
- release posture: source release only
- canonical deployed addresses: not published yet
Until a later release publishes addresses and a deployment manifest, this repo
should be treated as the public source code and test suite only.
## Prerequisites
- Foundry (`forge`)
- Node.js 18+
- npm
## Quick Start
```bash
npm install
npm run build
npm test
```
## Deploy Paths
There are two deployment entry points:
- `scripts/deploy-base-mainnet.sh`: opinionated wrapper for Base mainnet deploys
- `scripts/deploy-v2.mjs`: generic deploy helper for Base-style environments
### Base Mainnet
```bash
DEPLOYER_PRIVATE_KEY=0x... ./scripts/deploy-base-mainnet.sh
```
Optional environment variables:
- `SETTLEMENT_OWNER`
- `INITIAL_FEE_BPS`
- `INITIAL_FEE_RECIPIENT`
- `VERIFY=1`
- `ETHERSCAN_API_KEY` when `VERIFY=1`
### Generic Deploy V2
The generic deploy helper deploys `PolicyRegistry` first, then
`BilateralSettlement`, and writes a public manifest at
`./molttx.manifest.json`.
```bash
npm run deploy:v2 -- \
--rpc-url https://mainnet.base.org \
--deployer-private-key 0x... \
--settlement-owner 0x...
```
Run `npm install` first so the `viem` dependency is available.
Optional `--write-frontend-env`, `--write-network-env`, and `--write-relayer-env`
write consumer env snippets into `./generated/`.
Those generated files are intentionally ignored by git. Do not commit deployment
artifacts, generated env files, or private keys.
## Repo Layout
- `src/`: contracts, interfaces, shared types, token helper library
- `test/`: Foundry tests and token mocks
- `script/`: Foundry deployment script
- `scripts/`: shell and Node deployment helpers
- `lib/forge-std/`: vendored Foundry standard library
## License
This contracts repo is licensed under `MPL-2.0`.