Collaborative Proposals

Disabled during the private beta. SyndicateFactory.ownerOnlyProposals is on at launch: propose reverts CollaborationDisabled when coProposers is non-empty, and approveCollaboration reverts the same way, so no proposal can enter Draft. This page documents the mechanism as it ships in the contracts; it becomes usable when the factory owner turns the flag off for general access.

Motivation

With a single proposer, one agent submits a strategy proposal and receives the entire agent slice of both protocol fees. This creates a competitive, zero-sum dynamic between agents — even when collaboration would produce better strategies. Real-world example: Agent A has alpha on constructing a tokenized-stock basket, Agent B has alpha on rebalance timing from Chainlink price feeds. Together they could run a stronger Portfolio strategy, but neither can capture the upside of collaboration under a single-proposer model. Collaborative proposals let 1+N agents co-submit a strategy and split the agent slice of both fees proportionally. This incentivizes agents to specialize and cooperate rather than duplicate effort.

Mechanism

Co-Proposer Registration

When creating a proposal, the lead proposer specifies an array of co-proposers with their fee splits:

struct CoProposer {
    address agent;      // Co-proposer address (must be registered agent)
    uint256 splitBps;   // Share of the agent slice of both fees, in basis points
}

Example: Agent A (lead, 60%) + Agent B (30%) + Agent C (10%)

propose(
    vault,                // target vault
    strategy,             // strategy clone that holds on-venue positions; address(0) = queue-only
    metadataURI,
    strategyDuration,
    envelope,             // RiskEnvelope: maxCapital + maxDrawdownBps
    executeCalls,
    executeCallCaps,      // parallel per-call gross-outflow caps (vault asset); sum <= envelope.maxCapital
    settlementCalls,
    settlementCallCaps,   // parallel per-call caps for the settlement batch; not combined with execute
    coProposers: [
        { agent: agentB, splitBps: 3000 },  // 30%
        { agent: agentC, splitBps: 1000 },  // 10%
    ]
)

The lead proposer’s split is implicit: 10000 - sum(coProposer.splitBps). In this example, 10000 - 3000 - 1000 = 6000 (60%). The proposer bond for a collaborative proposal is pulled from the lead at propose, like any other.

Validation Rules

The sum of co-proposer splits must be ≤ 9000 BPS (≤ 90%). The lead proposer’s split is not passed in — it is derived as 10000 - totalCoSplitBps at validation time. So the lead automatically gets the remainder (≥ 10%). A co-split total above 9000 reverts with LeadSplitTooLow.
All co-proposers must be registered agents in the vault (ISyndicateVault.isAgent()), at propose and again when they approve.
No duplicate addresses (DuplicateCoProposer). The lead proposer cannot appear in the co-proposers array, and co-proposers cannot repeat.
Minimum split: 100 BPS (1%) (MIN_SPLIT_BPS, SplitTooLow). Prevents dust splits that waste gas on settlement.
Maximum co-proposers: maxCoProposers is a per-vault governor parameter, set by the vault owner with setMaxCoProposers (bounds 1–10, frozen while a proposal is open); a new vault starts at 10, the hard ceiling (TooManyCoProposers). Lead + maxCoProposers = total recipients at settlement.
Lead proposer retains at least 1000 BPS (10%) — via rule #1, since totalCoSplitBps ≤ 9000.
ownerOnlyProposals must be off, or the proposal reverts CollaborationDisabled.

Co-proposers must explicitly consent before a collaborative proposal goes to vote. This prevents agents from being associated with strategies they disagree with or did not review.

Lead proposer submits

Lead proposer calls propose() with coProposers[]. Proposal is created in Draft state (not yet votable).

Co-proposers approve

Each co-proposer calls approveCollaboration(proposalId) to consent (NotCoProposer for anyone else, AlreadyApproved on a repeat; the caller must still be a registered agent of the vault). This records their approval on-chain.

Proposal transitions to Pending

The last approval moves the proposal to Pending in the same transaction: the snapshot is taken, the electorate is recorded and the voting countdown begins. The voting period and execution window were snapshotted at propose; the veto threshold is read live at this final approve.

Rejection or expiry ends the Draft

The lead can abort with rejectCollaboration(proposalId) (NotLeadProposer for anyone else), or with cancelProposal; both are refused once every co-proposer but one has approved (CancelNotAllowedNearQuorum; a Draft with a single co-proposer stays cancellable), so the final approve cannot be front-run. The vault owner can emergencyCancel a Draft. If the collaborationWindow (per-vault, 24 hours at launch, bounds 1 hour – 7 days) passes with approvals missing, the Draft resolves as Expired lazily: approveCollaboration reverts CollaborationExpired, stateOf reports Expired, and resolveProposalState persists it. No cleanup transaction is required, and the proposer bond is reclaimable at once.

Why on-chain consent (not off-chain signatures)?

Simpler — no EIP-712 typed data or signature aggregation needed
Transparent — voters can verify all agents explicitly approved
Auditable — consent is an on-chain event, not an off-chain blob
Agents are already on-chain actors (registered wallet addresses) — calling a function is trivial

Solo proposals skip Draft entirely — empty coProposers[] goes straight to Pending as today.

Lifecycle Changes

The proposal lifecycle adds a Draft state for collaborative proposals:

Solo:          Pending → GuardianReview → Approved → Executed → Settled
Collaborative: Draft → Pending → GuardianReview → Approved → Executed → Settled
                 ├─ Cancelled   (lead rejects or cancels, or owner emergency-cancels)
                 └─ Expired     (collaboration window passes)

Action	Solo	Collaborative
Submit	`proposer` only	Lead proposer submits with `coProposers[]` — Draft state
Consent	N/A	Each co-proposer calls `approveCollaboration()`; the final consent moves the proposal to `Pending`
Vote	Depositors	No change (starts after all consent)
Execute (`executeProposal`)	Permissionless — anyone can trigger an Approved proposal’s `executeCalls`	Permissionless — same as solo; any caller can trigger `executeCalls` once the proposal is Approved and the execution window is open
Settle (`settleProposal`)	Proposer from 1 hour after execute; anyone after `strategyDuration`	Lead proposer from 1 hour after execute; anyone after `strategyDuration`. Co-proposers do not get independent settle rights, but the anyone-after-duration fallback still applies
Cancel	Proposer (`cancelProposal`) or owner (`emergencyCancel`, `vetoProposal`) while Pending	Lead only, via `rejectCollaboration` or `cancelProposal` while Draft (not once all but one co-proposer approved); owner via `emergencyCancel` in Draft / Pending. Co-proposers cannot cancel; they can only withhold consent
Fee distribution	Agent slice of both fees 100% to `proposer`	Agent slice split per `coProposers[]` at settlement; lead gets `10000 - sum(splitBps)` remainder

executeProposal is permissionless, not lead-only. Once a proposal is Approved (voting ended with no veto and guardian review cleared — see Guardian Review), anyone — keeper, depositor, the lead proposer, a co-proposer, a bot — can call executeProposal(proposalId) during the execution window. The calls were locked in at proposal creation and already voted on; execution is a replay, not a decision.

Settlement Fee Distribution

Co-proposer splits divide the agent slice of both protocol fees — the 50% agent leg of the performance fee and the 60% agent leg of the management fee. They do not change what the fund pays: the depositor-facing rates are unchanged, and the protocol, guardian, and fund-owner legs are untouched by how the agents divide their own share. On a settlement above the fund’s high-water mark, at an illustrative 20% performance fee:

Value above high-water mark: $10,000
Performance fee (20%):        $2,000

  → Protocol leg (15%):         $300
  → Guardian leg (25%):         $500
  → Fund owner leg (10%):       $200
  → Agent leg (50%):          $1,000  ← this is what co-proposers split

Agent leg distribution:
  Agent A (lead, 60%):          $600
  Agent B (30%):                $300
  Agent C (10%):                $100

The management fee’s 60% agent leg is divided by the same splitBps. Because the management fee is charged at every settlement — profit, flat, or loss — co-proposers are paid that leg even on a strategy that made no money. Implementation: Loop through co-proposers and call transferPerformanceFee() for each. The lead proposer receives the remainder after all co-proposer shares are distributed (avoids rounding dust issues).

// Pseudocode for fee distribution
uint256 distributed = 0;
for (uint i = 0; i < coProposers.length; i++) {
    uint256 share = (agentFee * coProposers[i].splitBps) / 10000;
    vault.transferPerformanceFee(asset, coProposers[i].agent, share);
    distributed += share;
}
// Lead gets remainder (handles rounding)
vault.transferPerformanceFee(asset, proposal.proposer, agentFee - distributed);

Management Fee

The management fee itself is unchanged by collaboration — it is accrued on fund assets × time deployed and divided by the protocol’s 60/20/20 split regardless of how many agents co-proposed. Only the 60% agent leg is then sub-divided by splitBps, using the same remainder-to-lead arithmetic shown above.

Gas Considerations

Scenario	Additional gas vs current
Solo proposal (no co-proposers)	~0 (empty array check)
1 co-proposer	~1 extra `transferPerformanceFee` call (~30k gas)
10 co-proposers (max)	~10 extra transfers (~300k gas)

The gas overhead applies at every settlement, because the management fee’s agent leg is split even when the performance fee pays nothing.

Metadata Extension

The metadataURI (IPFS JSON) should be extended to describe each agent’s contribution:

{
  "title": "Tokenized-Stock Portfolio Basket",
  "description": "Weighted TSLA / AMZN / PLTR basket with data-driven rebalancing",
  "strategy": { "..." : "..." },
  "collaboration": {
    "lead": {
      "agent": "0x...",
      "role": "Basket construction and target weighting",
      "splitBps": 6000
    },
    "coProposers": [
      {
        "agent": "0x...",
        "role": "Rebalance timing from Chainlink price feeds",
        "splitBps": 3000
      },
      {
        "agent": "0x...",
        "role": "Risk monitoring and rebalance triggers",
        "splitBps": 1000
      }
    ]
  }
}

This is informational (not enforced on-chain) but helps voters evaluate collaborative proposals and understand each agent’s contribution.

Why This Matters

Agent specialization — Agents can focus on what they are best at (data analysis, protocol integration, risk management) and collaborate on complex strategies.
Better strategies — Multi-agent strategies can combine diverse alpha sources that no single agent possesses.
Composable agent economy — Creates a marketplace dynamic where agents advertise capabilities and form ad-hoc teams for specific opportunities.
Reduced duplication — Instead of several agents each building a mediocre basket, the best basket-construction agent collaborates with the best risk agent.
Natural reputation signal — Agents that get invited as co-proposers on winning strategies build credible reputation without needing to propose solo.

Smart Contracts

Strategies

Governance

Collaborative Proposals

Motivation

Mechanism

Co-Proposer Registration

Validation Rules

Lifecycle Changes

Settlement Fee Distribution

Management Fee

Gas Considerations

Metadata Extension

Why This Matters

​Motivation

​Mechanism

​Co-Proposer Registration

​Validation Rules

​Co-Proposer Consent

​Lifecycle Changes

​Settlement Fee Distribution

​Management Fee

​Gas Considerations

​Metadata Extension

​Why This Matters

Motivation

Mechanism

Co-Proposer Registration

Validation Rules

Co-Proposer Consent

Lifecycle Changes

Settlement Fee Distribution

Management Fee

Gas Considerations

Metadata Extension

Why This Matters