simple-pre-faktory/README.md

You're absolutely right with that clarification. Here's the updated summary:

Transitions and Function Availability

Period 1:

• buy-up-to: Available until Period 2 starts
• refund: Only available if Period 1 expires without reaching criteria and Period 2 hasn't started

Period 2:

• Begins automatically when 20 seats are sold to 10+ users
• buy-single-seat: Only available during Period 2 (100 blocks)
• set-contract-addresses: Only available after Period 2 starts

Token Distribution:

• initialize-token-distribution: Can only be called by the DAO token after Period 2 starts and set-contract-addresses is set properly
• claim: Only available after token distribution is initialized

Key Variables

• period-2-height: Marks successful completion of Period 1
• token-contract: Marks DAO token deployment and initialization (not redundant)

Workflow

1. Users buy seats in Period 1
2. Period 2 starts automatically when requirements met
3. Multi-sig agent sets contract addresses during Period 2
4. DAO token deploys and initializes distribution (which can only happen once)
5. Users can begin claiming tokens according to vesting schedule

Each check serves a distinct purpose in ensuring correct sequencing and authorization throughout the process. The token-contract variable is indeed not redundant - it specifically marks when the DAO token has deployed and initialized distribution, which is separate from the Period 2 transition.

Multi-sig Security Model

At no point does the multi-sig agent control the flow of money or token distribution. The agent only facilitates the creation of the multi-sig and setting of contracts. If an error occurs in setting addresses, the agent can create a new multi-sig with the correct configuration and update the addresses accordingly without risking funds.

The design ensures transparency as anyone can verify that the multi-sig members match the first buyers from Period 1. This establishes decentralized control from day one while maintaining the technical capability to deploy the necessary infrastructure.

Recovery Path: If the token is deployed with an address that doesn't match what's set in the pre-launch contract, initialize-distribution will fail. The agent can then create a new multi-sig, update the contract addresses, and redeploy the token correctly. This ensures STX funds in the pre-launch contract are never stuck, even if deployment errors occur.

If the multi-sig creator makes a mistake in setting addresses:

1. They can deploy a new multi-sig with the correct configuration
2. Call set-contract-addresses again with the correct addresses
3. Deploy the token contract through the new multi-sig
4. The token contract calls initialize-token-distribution

Since the condition is (asserts! (is-eq tx-sender (var-get dao-token)) ERR-NOT-AUTHORIZED), as long as the caller matches whatever is currently set as dao-token, the initialization will succeed.

This approach gives flexibility to fix mistakes without complex recovery mechanisms, while still maintaining the security of requiring the multi-sig for deployment. The only consequence is that the first incorrect multi-sig would need to be abandoned, but that's a reasonable tradeoff for the simplicity it provides.

;; Pre-launch participants are considered co-deployers of the DAO contract infrastructure through ;; the multi-sig and thus have legitimate claim to protocol fees based on: ;; ;; 1. They provide valuable service in protocol deployment and bootstrapping ;; 2. Fee distribution is transparent, immutable and programmatically defined ;; 3. Multi-sig creation formalizes their relationship with the DAO ;; ;; Fee compensation is separate from token purchase: ;; - Participants buy tokens through seat purchase ;; - Participants receive fees as compensation for their deployer role ;; - These are distinct forms of value with different legal bases ;; ;; Implementation follows standard DeFi practices: ;; ;; This creates proper incentive alignment and encourages long-term protocol engagement ;; beyond the initial vesting period.

Fee Airdrops

We simplified the fee distribution system by replacing a complex period-based claiming mechanism with a streamlined automatic airdrop approach. Instead of tracking fees per period and requiring each user to manually claim their share, the new system accumulates all fees in a single pool and distributes them proportionally to all seat holders in one transaction. We optimized the code by directly using the existing seat-holders list, implemented a cooldown period between airdrops, and added a special "final airdrop" mode on bonding. The new system is more gas-efficient and provides a much better user experience since users automatically receive their fees without any action required.