Silver Glen Protocols

Documentation

The fastest way to start a pool. Quick mode fills in sensible governance defaults and asks you only for the essentials.

Before you start

  • A wallet. On desktop, a browser extension like MetaMask, Coinbase Wallet, or Rabby. On a phone, open Siloam inside your wallet app's built-in browser.
  • Gas, on the pool's network. You need a little ETH on the same network the pool runs on to pay for transactions. Networks are separate — ETH on Base is not the same balance as ETH on Ethereum.
  • The deposit token, on that same network. A pool is denominated in one ERC-20. You need some of it, on the pool's network, to contribute.

Create a pool

  1. Open Create a pool and stay on the Quick tab.
  2. Choose the deposit token — type a symbol to pick from the list, or paste any ERC-20 address (it's confirmed on-chain).
  3. Set the minimum and maximum contribution, in that token's own units (e.g. 10 and 1000 USDC, or 0.01 and 1 WETH).
  4. Pick a governance template and add a short description.
  5. Sign the transaction. You're taken to your new pool's page.

Using a pool

  • Contribute. The first contribution asks for a one-time token approval, then the deposit. Your balance and standing update on their own.
  • Make a claim. Request a payout to a destination address with an amount, category, and description. Members vote on it.
  • Vote. On claims and proposals, while you're a member in good standing, according to the pool's rules.

The Advanced tab exposes every setting Quick mode chooses for you. Most are immutable once the pool is created, so set them deliberately.

Membership & contributions

  • Deposit token and min / max contribution — as in Quick mode, in the token's own units.
  • Open vs. closed. Open pools let anyone join by contributing. Closed pools require a current member to nominate a newcomer, who must then be approved by vote.
  • Cycle length — the contribution period, in days.
  • Grace period & grace limit — a window of leniency for late contributions, capped at the grace limit.

Voting & governance

  • Who can vote — members, or only governors.
  • Voting style and basis — how votes are weighted (e.g. one-member-one-vote vs. weighted by contribution).
  • Claim approval threshold and member approval threshold — the share of votes needed to pass a claim, and to admit a member.
  • Voting window — how long a vote stays open, in days.

Disbursements & governors

  • Disbursement range — the smallest and largest a single claim may pay out, as a percentage of pool value.
  • Governors — optional privileged members. Set the initial governors and the maximum the pool may ever have.

Yield (optional)

You may attach a yield adapter so idle pool funds earn yield through a vetted venue (e.g. an ERC-4626 vault). The adapter is fixed at creation; whether yield is on, and the share routed to it, are governed afterward.

Experimental. Yield routing is newer and far less battle-tested than the rest of Siloam. It stacks the smart-contract risk of an external venue on top of your pool, and a loss at the venue is a loss to the pool. Treat it as experimental, prefer vetted adapters, and start small.

A yield adapter lets a pool's idle funds earn yield by routing the deposit token into an external venue — for example an Aave V3 market or an ERC-4626 vault. The pool keeps custody of its own position; the adapter is just the plumbing that moves funds in and out of the venue.

Chosen once, at creation — and only then

The yield adapter is immutable. You pick it when you create the pool, in the Advanced tab, and it can never be changed, added, or removed afterward. If you create a pool without an adapter, that pool can never use yield — its funds stay fully liquid for its entire life. So this is a decision to make before you create, never after.

The address you paste is the adapter — not the venue

This is the part that trips people up: a Siloam pool does not take an Aave or Morpho address directly. It takes a Siloam adapter — a small contract that speaks the venue's interface on one side (an Aave market, or an ERC-4626 vault such as a Morpho MetaMorpho vault) and Siloam's on the other. "Adding Aave" or "adding Morpho" means pointing your pool at the adapter that is wired to that venue for your deposit token. The venue lives inside the adapter; you never enter the venue address into Siloam.

Step by step: adding a venue (Aave, Morpho, …)

  1. Find the venue for your deposit token, on the pool's network. It must accept the exact ERC-20 your pool is denominated in. For Aave V3, locate the market for that token in Aave's official address book; for Morpho, find a MetaMorpho vault whose underlying asset is that token in the Morpho app. Confirm the address on the block explorer.
  2. Get the matching Siloam adapter address. Vetted adapters are whitelisted in the factory itself — the safe set is exactly those the factory owner has approved. You can see them from the factory's AdapterApproved events, or check approvedAdapters(adapter) directly. A pool built on a whitelisted adapter is recorded as vetted on-chain; a pool built on any other adapter is permanently flagged (see below). If no vetted adapter exists for your token and venue yet, one has to be built and deployed first — see the Builders tab. Either way, what the pool stores is the adapter address.
  3. Sanity-check it before you commit. The adapter's resolved venue for your deposit token must be the venue from step 1, and that venue's underlying asset must equal your pool's deposit token. If the asset doesn't match, the adapter is built for a different token — do not use it.
  4. Paste the adapter address into the Yield adapter field on the Advanced create tab — the adapter, not the venue. Leave it blank for a pool with no yield.
  5. Set the maximum yield allocation (the largest share of pool value that may ever be routed), then create and sign. The adapter is now fixed for the life of the pool.

Using it after creation

Once a pool has an adapter, governance controls the rest by vote: whether yield is currently on or off, and what share of funds is actively routed, up to the maximum set at creation. The adapter address itself never moves — only the on/off switch and the active share do.

Vetted vs. non-standard. An adapter that isn't whitelisted can still be used — but only if it implements the IYieldAdapter interface. The factory checks for that, and if it passes it creates the pool while emitting NonStandardAdapterUsed and recording the pool as non-whitelisted: a permanent, public signal that the adapter was never vetted. That puts the venue's risk entirely on the pool with no review — only choose it if you fully understand the adapter and its venue. An adapter that doesn't implement the interface is rejected outright.

Siloam's contracts are source-available under the Business Source License 1.1. You're free to build whatever you like on top of them — your own frontend, an agent, integrations, tooling — with one condition: keep the protocol fee structure and fee address intact. Don't fork to remove, lower, or redirect the fee.

See the Business Source License 1.1 for the full terms and the additional-use grant.

Building a yield adapter

A yield adapter is a standalone contract you deploy and wire to your venue — an Aave market, a Morpho or other ERC-4626 vault, however you like. The factory never sees the venue; it only sees the adapter. To be accepted, the adapter must implement the IYieldAdapter interface and answer supportsInterface(type(IYieldAdapter).interfaceId) with true — the factory verifies exactly this before it will take the address.

Once it's deployed and verified, there are two ways in:

  • Whitelisted (vetted). The factory owner approves it with addAdapter. Pools that use it are recorded as whitelisted, with no on-chain warning. Approval is owner-only, so this path is by request.
  • Non-standard (permissionless). Anyone can pass an interface-compliant adapter straight into createPool with no approval. The pool is created, but the factory emits NonStandardAdapterUsed and marks the pool non-whitelisted — a permanent, public signal that the adapter wasn't vetted.

More builder tools — a published ABI and SDK, verifiable calldata, and an agent API — are on the way.