Silver Glen Protocols LLC

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.

How to read this page: a field shown in bold is permanent — fixed when the pool is created and never changeable again. A field that is not bold is governable — it can be changed later by member vote, within limits the permanent settings set. Most fields are permanent, so set them deliberately.

Membership & contributions

  • Deposit token — the single ERC-20 the pool is denominated in. Permanent.
  • Minimum contribution / Maximum contribution — the smallest and largest a member may contribute, in the token's own units (e.g. 10 and 1000 USDC). Permanent.
  • Open vs. closed — whether anyone may join by contributing (open), or a current member must nominate a newcomer who is then approved by vote (closed). Permanent.
  • Maximum members — the cap on how many members the pool may ever hold. Permanent.
  • Cycle length — the contribution period, in days. Permanent.
  • Grace period / grace limit — a window of leniency for late contributions, and the amount it's capped at. Permanent.

Voting & governance

  • Who can vote — members, or only governors. Permanent.
  • Voting scale (claims) / voting scale (members) — how voting power is shaped (e.g. flat one-member-one-vote vs. weighted), set independently for claim votes and membership votes. Permanent.
  • Voting basis — the weighting basis applied to the scales above. Permanent.
  • Claim approval threshold — the share of voting power needed to pass a claim. Permanent.
  • Member approval threshold — the share needed to admit a new member (and used for other membership-class votes). Permanent.
  • Claim voting window / member voting window — how long a claim vote and a membership/proposal vote stay open, in days. Permanent.
  • Max claims per member — how many open claims one member may have per cycle. Permanent.
  • Max proposals per cycle / max yield proposals per cycle — rate limits on pool-change proposals and on yield proposals. Permanent.

Disbursements & governors

  • Disbursement range (minimum / maximum) — the smallest and largest a single claim may pay out, as a percentage of pool value. Permanent.
  • Maximum governors — the ceiling on how many governors the pool may ever have. Permanent.
  • Governors — the actual roster of privileged members. Governable: members can add a governor (nominateGovenor → voteGovenor) or remove one (removeGovenor → voteGovenor) by vote, at any time, up to the permanent maximum above. The initial roster is set at creation.

Yield (optional)

  • Yield adapter — the adapter address that routes idle funds to a vetted venue. Permanent: fixed at creation, never changeable. Leave it blank for a pool that can never use yield. (See the Yield tab.)
  • Maximum yield allocation — the largest share of pool value that may ever be routed to the adapter. Permanent: it is the hard ceiling the governable active share can never exceed.
  • Yield on/off and active share — governable: whether yield is currently routing, and what share of funds (up to the permanent maximum) is actively routed. Members change both by vote (nominateYield → voteYield). The adapter address itself never moves.

Pool state

  • Lifecycle state — governable: members can move the pool between its lifecycle states (for example, to cancel it) by vote (nominatePoolChange → votePoolChange). This is the one structural thing about a live pool that governance can change; the parameters above are not.

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.