diff --git a/README.md b/README.md
index 80cc9ea..5eeefd8 100644
--- a/README.md
+++ b/README.md
@@ -17,7 +17,7 @@ The regulatory environment is catching up. Pending [U.S. market structure legisl
Token sales are a faster, more accessible way to raise capital. Compared to traditional fundraising, they offer real advantages:
-* **Global participation.** Anyone can participate. No geographic restrictions, no accredited investor gates.
+* **Global participation.** Broad access for eligible participants worldwide, subject to jurisdiction and compliance requirements.
* **Better price discovery.** Prices are [set by the market during the sale](https://docs.doppler.lol/how-it-works/implementation), not by underwriters in a closed room.
* **Instant settlement.** Transactions clear on-chain in [minutes](https://www.fireblocks.com/glossary/transaction-settlement), not days.
* **Lower cost and faster execution.** Traditional IPOs require [12-18 months of preparation and millions in fees](https://www.pwc.com/us/en/services/consulting/deals/library/cost-of-an-ipo.html). Token sales can launch in weeks at a fraction of the cost.
@@ -26,18 +26,18 @@ Token sales are a faster, more accessible way to raise capital. Compared to trad
Ready to launch with tally? [Talk to our team to get started](http://tally.xyz/contact).
-{% content-ref url="tally-features/token-sales-and-icos.md" %}
-[token-sales-and-icos.md](tally-features/token-sales-and-icos.md)
+{% content-ref url="token-sales/README.md" %}
+[How Token Sales Work](token-sales/README.md)
{% endcontent-ref %}
-{% content-ref url="tally-features/token-launch/" %}
-[token-launch](tally-features/token-launch/)
+{% content-ref url="sale-types/README.md" %}
+[Sale Types](sale-types/README.md)
{% endcontent-ref %}
-{% content-ref url="tally-features/incentives-and-staking/" %}
-[incentives-and-staking](tally-features/incentives-and-staking/)
+{% content-ref url="benefits/for-projects.md" %}
+[For Projects](benefits/for-projects.md)
{% endcontent-ref %}
-{% content-ref url="tally-features/governance/" %}
-[governance](tally-features/governance/)
+{% content-ref url="post-launch-tooling/README.md" %}
+[Post-Launch Tooling](post-launch-tooling/README.md)
{% endcontent-ref %}
diff --git a/SUMMARY.md b/SUMMARY.md
index 99ed6c4..f85a45b 100644
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -2,160 +2,48 @@
* [Welcome to Tally](README.md)
-## Tally Features
-
-* [Token sales & ICOs](tally-features/token-sales-and-icos.md)
-* [Token launch & airdops](tally-features/token-launch/README.md)
- * [Airdrops](tally-features/token-launch/airdrops.md)
- * [Vesting & disitribution](tally-features/token-launch/vesting-and-disitribution.md)
- * [Exchange listing & compliance documentation](tally-features/token-launch/exchange-listing-and-compliance-documentation.md)
- * [Features](tally-features/token-launch/features.md)
- * [Delegate registration & claim-and-delegate](tally-features/token-launch/delegate-registration-and-claim-and-delegate.md)
-* [Incentives & staking](tally-features/incentives-and-staking/README.md)
- * [Staking for value accrual](tally-features/incentives-and-staking/staking-for-value-accrual.md)
- * [Delegate compensation](tally-features/incentives-and-staking/delegate-compensation.md)
- * [Features](tally-features/incentives-and-staking/staking-customizations.md)
- * [FAQ](tally-features/incentives-and-staking/faq.md)
- * [Glossary](tally-features/incentives-and-staking/glossary.md)
-* [Governance](tally-features/governance/README.md)
- * [Security Council elections](tally-features/governance/security-council-elections/README.md)
- * [Arbitrum DAO Security Council Elections Guide](tally-features/governance/security-council-elections/arbitrum-dao-security-council-elections-guide.md)
- * [Optimistic governance](tally-features/governance/optimistic-governance.md)
- * [MultiGov](tally-features/governance/multigov.md)
- * [Delegate Reputation Score (DRS)](tally-features/governance/delegate-reputation-score-drs.md)
- * [Integrations](tally-features/governance/integrations/README.md)
- * [Karma - Delegate Scoring](tally-features/governance/integrations/karma-delegate-scoring.md)
- * [Discourse](tally-features/governance/integrations/forum-bot.md)
- * [Safe](tally-features/governance/integrations/safe.md)
- * [Features](tally-features/governance/features.md)
-* [Tally API](tally-features/welcome/README.md)
- * [How to use the Tally API](tally-features/welcome/how-to-use-the-tally-api.md)
-* [Tally Zero](tally-features/tally-zero.md)
-* [Tally partner benefits](tally-features/tally-partner-benefits.md)
-* [Tally Fees](tally-features/tally-fees.md)
-
-## How to Use Tally
-
-* [Navigate the Tally homepage](how-to-use-tally/navigate-the-tally-homepage.md)
-* [Set up a Tally profile](how-to-use-tally/set-up-a-tally-profile.md)
-* [Create proposals](how-to-use-tally/proposals/creating-proposals/README.md)
- * [Import & export proposal actions](how-to-use-tally/creating-proposals/import-and-export-proposal-actions.md)
- * [Proposal templates](how-to-use-tally/creating-proposals/proposal-templates.md)
- * [Custom actions](how-to-use-tally/proposals/creating-proposals/custom-actions/README.md)
- * [Chain Deployment of Uniswap v3](how-to-use-tally/proposals/creating-proposals/custom-actions/chain-deployment-of-uniswap-v3.md)
- * [Token vesting with Hedgey](how-to-use-tally/proposals/creating-proposals/custom-actions/token-vesting-with-hedgey.md)
- * [Token grants with Hedgey](how-to-use-tally/proposals/creating-proposals/custom-actions/token-grants-with-hedgey.md)
- * [Streaming payments with Sablier](how-to-use-tally/proposals/creating-proposals/custom-actions/streaming-payments-with-sablier.md)
- * [Tuple support](how-to-use-tally/proposals/creating-proposals/custom-actions/tuple-support.md)
- * [Swaps](how-to-use-tally/proposals/creating-proposals/swaps/README.md)
- * [Swaps: FAQs](how-to-use-tally/proposals/creating-proposals/swaps/swaps-faqs.md)
- * [Draft proposals](how-to-use-tally/proposals/creating-proposals/draft-proposals.md)
- * [Test proposals](how-to-use-tally/creating-proposals/test-proposals.md)
-* [Execute Proposals](how-to-use-tally/proposals/managing-proposals/README.md)
- * [Advanced Execution](how-to-use-tally/proposals/managing-proposals/advanced-execution.md)
-* [Delegate on Tally](how-to-use-tally/delegate-on-tally/README.md)
- * [Delegates Page](how-to-use-tally/delegate-on-tally/delegates-page.md)
- * [Delegate Voting Power](how-to-use-tally/delegate-on-tally/delegate-voting-power.md)
- * [Create a Delegate Statement](how-to-use-tally/delegate-on-tally/create-a-delegate-statement.md)
- * [Partial delegation](how-to-use-tally/delegate-on-tally/partial-delegation.md)
-* [Vote on Tally](how-to-use-tally/voting-on-proposals/README.md)
- * [Advanced voting](how-to-use-tally/voting-on-proposals/advanced-voting/README.md)
- * [Flexible voting extension](how-to-use-tally/voting-on-proposals/advanced-voting/flexible-voting-extension.md)
- * [Signal voting](how-to-use-tally/voting-on-proposals/advanced-voting/signal-voting/README.md)
- * [Snapshot](how-to-use-tally/voting-on-proposals/advanced-voting/signal-voting/diff-checker.md)
- * [Private voting](how-to-use-tally/voting-on-proposals/advanced-voting/private-voting.md)
- * [Gasless voting and delegation (Relay)](how-to-use-tally/voting-on-proposals/relay/README.md)
- * [Gasless voting](how-to-use-tally/voting-on-proposals/relay/gasless-voting.md)
- * [Gasless delegation](how-to-use-tally/voting-on-proposals/relay/free-delegation.md)
-* [Stake on Tally](how-to-use-tally/stake-on-tally/README.md)
- * [How to Stake OBOL](how-to-use-tally/stake-on-tally/how-to-stake-obol.md)
- * [How to Stake RARI](how-to-use-tally/stake-on-tally/how-to-stake-rari.md)
-* [Participate in Security Council Elections](how-to-use-tally/participate-in-security-council-elections.md)
-* [Use Tally as a Safe multisig](how-to-use-tally/use-tally-as-a-safe-multisig/README.md)
- * [Vote with a Gnosis Safe](how-to-use-tally/use-tally-as-a-safe-multisig/vote-with-a-gnosis-safe.md)
- * [Zodiac Governor Module for SubDAOs and Grants Programs](how-to-use-tally/use-tally-as-a-safe-multisig/zodiac-governor-module-for-subdaos-and-grants-programs.md)
- * [Upgrade Gnosis Safe to Governor with Zodiac](how-to-use-tally/use-tally-as-a-safe-multisig/upgrade-gnosis-safe-to-governor-with-zodiac.md)
-* [Get notifications on Tally](tally-features/enterprise-features/notifications.md)
-* [Using Ledger with Solana](how-to-use-tally/using-ledger-with-solana.md)
-
-## Set up & Technical Documentation
-
-* [Staking contracts](set-up-and-technical-documentation/staking-contracts/README.md)
- * [Get started](set-up-and-technical-documentation/staking-contracts/stgov-lst.md)
- * [How staking works](set-up-and-technical-documentation/staking-contracts/how-staking-works.md)
- * [Liquid staking](set-up-and-technical-documentation/staking-contracts/how-staking-works/liquid-staking/README.md)
- * [LST auto delegates](set-up-and-technical-documentation/staking-contracts/how-staking-works/liquid-staking/lst-auto-delegates.md)
- * [Staking operator's guide](set-up-and-technical-documentation/staking-contracts/staking-operators-guide.md)
- * [DeFi integration guide](set-up-and-technical-documentation/staking-contracts/defi-integration-guide.md)
- * [FAQ & troubleshooting](set-up-and-technical-documentation/staking-contracts/faq-and-troubleshooting.md)
-* [Tally architecture](set-up-and-technical-documentation/tally-architecture.md)
-* [Chain compatibility](set-up-and-technical-documentation/chain-compatibility.md)
-* [Token wrapper](set-up-and-technical-documentation/token-wrapper.md)
-* [Deploy a governor](set-up-and-technical-documentation/deploying-daos/README.md)
- * [Deploy a governor](set-up-and-technical-documentation/deploying-daos/deploy-a-dao-with-token-voting/README.md)
- * [Deploy a Governor with a new token](set-up-and-technical-documentation/deploying-daos/deploy-a-dao-with-token-voting/deploy-a-governance-token.md)
- * [Add a Governor to an existing token](set-up-and-technical-documentation/deploying-daos/add-a-dao-to-an-existing-token.md)
- * [Check for token contract compatibility](set-up-and-technical-documentation/deploying-daos/smart-contract-compatibility/README.md)
- * [Tokens: ERC-20 and NFTs](set-up-and-technical-documentation/deploying-daos/smart-contract-compatibility/tokens-erc20-and-nfts.md)
- * [OpenZeppelin Governor](set-up-and-technical-documentation/deploying-daos/smart-contract-compatibility/openzeppelin-governor.md)
- * [Compound Governor Bravo](set-up-and-technical-documentation/deploying-daos/smart-contract-compatibility/compound-governor-bravo.md)
- * [Supported Use Cases FAQ](set-up-and-technical-documentation/deploying-daos/smart-contract-compatibility/supported-use-cases-faq.md)
- * [Choose Governor parameters](set-up-and-technical-documentation/deploying-daos/how-to-pick-governor-parameters.md)
- * [Deploy an NFT Governor](set-up-and-technical-documentation/deploying-daos/deploy-an-nft-dao.md)
-* [Add an organization to Tally](set-up-and-technical-documentation/managing-a-dao/README.md)
- * [Organization admins](set-up-and-technical-documentation/managing-a-dao/dao-admins.md)
- * [Organization settings](set-up-and-technical-documentation/managing-a-dao/dao-settings.md)
-* [Use Governor with Gnosis Safe](set-up-and-technical-documentation/using-governor-with-gnosis-safe/README.md)
- * [Gnosis Safe overview](set-up-and-technical-documentation/using-governor-with-gnosis-safe/gnosis-safe.md)
- * [Vote with a Gnosis Safe](set-up-and-technical-documentation/using-governor-with-gnosis-safe/voting-with-a-gnosis-safe.md)
- * [Arbitrum Gnosis Safes](set-up-and-technical-documentation/using-governor-with-gnosis-safe/arbitrum-gnosis-safes.md)
- * [Zodiac Governor Module for sub-organizations and grants programs](set-up-and-technical-documentation/using-governor-with-gnosis-safe/zodiac-governor-module-for-subdaos-and-grants-programs.md)
- * [Upgrade Gnosis Safe to Governor with Zodiac](set-up-and-technical-documentation/using-governor-with-gnosis-safe/how-to-upgrade-a-gnosis-safe-to-a-governor-with-zodiac.md)
-* [Security](set-up-and-technical-documentation/security.md)
-* [Governor proposal standards](set-up-and-technical-documentation/governor-proposals/README.md)
- * [Governor proposal descriptions standards](set-up-and-technical-documentation/governor-proposals/whats-the-standard-for-governor-proposal-descriptions.md)
-* [Bridge Providers](set-up-and-technical-documentation/bridge-providers.md)
-
-## Education
-
-* [Intro to governance](user-guides/intro-to-governance/README.md)
- * [General ecosystem info](user-guides/intro-to-governance/general-ecosystem-info.md)
- * [Participating in governance](user-guides/intro-to-governance/participating-in-governance.md)
-* [Governance concepts](user-guides/governance-concepts/README.md)
- * [Decentralized governance overview](user-guides/governance-concepts/decentralized-governance-overview.md)
- * [On-chain vs off-chain voting](user-guides/governance-concepts/onchain-vs-offchain-voting.md)
- * [Application layer vs. base layer overnance](user-guides/governance-concepts/application-layer-vs-base-layer-governance.md)
- * [Governance execution methods](user-guides/governance-concepts/governance-execution-methods.md)
- * [Procedural governance](user-guides/governance-concepts/procedural-governance.md)
- * [Vote delegation](user-guides/governance-concepts/vote-delegation.md)
-* [Governance frameworks](user-guides/governance-frameworks/README.md)
- * [OpenZeppelin Governor](user-guides/governance-frameworks/openzeppelin-governor.md)
- * [Curve voting escrow](user-guides/governance-frameworks/curve-voting-escrow.md)
- * [Multisigs](user-guides/governance-frameworks/multisigs.md)
- * [Snapshot polls](user-guides/governance-frameworks/snapshot-polls.md)
-* [Organizational best practices](user-guides/dao-best-practices/README.md)
- * [Running an on-chain organization using OpenZeppelin Governor](user-guides/dao-best-practices/running-an-onchain-dao-using-openzeppelin-governor.md)
- * [Seatbelt for governance](user-guides/dao-best-practices/seatbelt-for-governance.md)
-* [Index of on-chain organizations](user-guides/index-of-daos/README.md)
- * [Organizations on Tally](user-guides/index-of-daos/daos-on-tally/README.md)
- * [Aave (AAVE)](user-guides/index-of-daos/daos-on-tally/aave-aave.md)
- * [Ampleforth (FORTH)](user-guides/index-of-daos/daos-on-tally/ampleforth-forth.md)
- * [Arbitrum (ARB)](user-guides/index-of-daos/daos-on-tally/arbitrum-arb.md)
- * [Compound (COMP)](user-guides/index-of-daos/daos-on-tally/compound-comp.md)
- * [Gitcoin (GTC)](user-guides/index-of-daos/daos-on-tally/gitcoin-gtc.md)
- * [GMX](user-guides/index-of-daos/daos-on-tally/gmx.md)
- * [Idle Finance (IDLE)](user-guides/index-of-daos/daos-on-tally/idle-finance-idle.md)
- * [Inverse Finance (INV)](user-guides/index-of-daos/daos-on-tally/inverse-finance-inv.md)
- * [PoolTogether (POOL)](user-guides/index-of-daos/daos-on-tally/pooltogether-pool.md)
- * [Uniswap (UNI)](user-guides/index-of-daos/daos-on-tally/uniswap-uni.md)
- * [ZKsync](user-guides/index-of-daos/daos-on-tally/zksync.md)
- * [DAOs Not on Tally](user-guides/index-of-daos/daos-not-on-tally/README.md)
- * [Balancer (BAL)](user-guides/index-of-daos/daos-not-on-tally/balancer-bal.md)
- * [Curve (CRV)](user-guides/index-of-daos/daos-not-on-tally/curve-crv.md)
- * [Index Coop (INDEX)](user-guides/index-of-daos/daos-not-on-tally/index-coop-index.md)
- * [KyberDAO (KNC)](user-guides/index-of-daos/daos-not-on-tally/kyberdao-knc.md)
- * [MakerDAO (MKR)](user-guides/index-of-daos/daos-not-on-tally/makerdao-mkr.md)
- * [Sushi (SUSHI)](user-guides/index-of-daos/daos-not-on-tally/sushi-sushi.md)
+## How Token Sales Work
+
+* [The Basics](token-sales/README.md)
+ * [Why Token Sales Matter](token-sales/why-token-sales.md)
+ * [Are You Ready?](token-sales/are-you-ready.md)
+ * [Choosing Your Sale Type](token-sales/choosing-your-sale-type.md)
+ * [Running Your Sale](token-sales/running-your-sale.md)
+ * [After Your Sale](token-sales/after-your-sale.md)
+
+## Sale Types
+
+* [Overview](sale-types/README.md)
+ * [Liquidity Bootstrapping Pools (LBPs)](sale-types/liquidity-bootstrapping-pools.md)
+ * [Continuous Clearing Auctions (CCAs)](sale-types/continuous-clearing-auctions.md)
+ * [Fixed-Price Sales](sale-types/fixed-price-sales.md)
+
+## Compliance
+
+* [Compliance Overview](compliance/README.md)
+ * [KYC & Verification](compliance/kyc-verification.md)
+ * [Geo-Restrictions](compliance/geo-restrictions.md)
+ * [Vesting & Lockups](compliance/vesting-lockups.md)
+
+## Post-Launch Tooling
+
+* [Overview](post-launch-tooling/README.md)
+ * [Governance](post-launch-tooling/governance-overview.md)
+ * [Voting & Delegation](post-launch-tooling/voting-delegation.md)
+ * [Staking & Incentives](post-launch-tooling/staking-incentives.md)
+ * [Security Councils](post-launch-tooling/security-councils.md)
+
+## Benefits
+
+* [Platform Benefits](benefits/README.md)
+ * [For Projects](benefits/for-projects.md)
+ * [For Participants](benefits/for-participants.md)
+
+## Developers
+
+* [Developer Documentation](developers/README.md)
+ * [API Documentation](developers/api-documentation.md)
+ * [Smart Contracts](developers/smart-contracts.md)
## Resources
diff --git a/benefits/README.md b/benefits/README.md
new file mode 100644
index 0000000..d0ffdef
--- /dev/null
+++ b/benefits/README.md
@@ -0,0 +1,125 @@
+---
+description: Why choose Tally for your token sale
+---
+
+# Benefits Overview
+
+Tally provides comprehensive token sale infrastructure that benefits both projects launching tokens and participants looking to invest. This section outlines the key advantages of using Tally's platform.
+
+## For Projects
+
+Projects launching token sales with Tally benefit from:
+
+### Turnkey Infrastructure
+
+- Production-ready sale mechanics
+- Audited smart contracts
+- White-labeled interfaces
+- Launch-day support
+
+### Compliance Integration
+
+- KYC/KYB/KYI verification
+- Geographic restrictions
+- Region-specific lockups
+- Regulatory best practices
+
+### Post-Sale Continuity
+
+- Governance deployment
+- Staking and incentives
+- Security councils
+- No vendor switching required
+
+[Full benefits for projects](for-projects.md)
+
+## For Participants
+
+Participants in Tally-powered token sales benefit from:
+
+### Trust and Security
+
+- Audited contracts
+- Transparent mechanics
+- Established platform
+- Professional execution
+
+### Fair Access
+
+- Anti-whale mechanisms
+- Price discovery
+- Clear eligibility rules
+- Equal treatment
+
+### Ongoing Engagement
+
+- Governance participation
+- Staking rewards
+- Delegation options
+- Community involvement
+
+[Full benefits for participants](for-participants.md)
+
+## Platform Advantages
+
+### Experience
+
+Tally has powered governance and token distribution for leading protocols:
+
+<>
+
+### Security
+
+Security-first approach:
+
+- Audited smart contracts
+- Battle-tested infrastructure
+- No custody of funds
+- Transparent operations
+
+### Flexibility
+
+Adapt to your needs:
+
+- Multiple sale mechanisms
+- Configurable parameters
+- Custom compliance rules
+- Branded experiences
+
+### Support
+
+Hands-on assistance:
+
+- Pre-sale planning
+- Launch-day support
+- Post-sale operations
+- Ongoing partnership
+
+## Comparison
+
+### Tally vs. Building In-House
+
+| Factor | Tally | In-House |
+|--------|-------|----------|
+| Time to market | Weeks | Months |
+| Development cost | Included | Significant |
+| Audit cost | Included | $50k-200k+ |
+| Compliance expertise | Included | Build or hire |
+| Support | Dedicated team | Internal resources |
+| Post-sale tools | Integrated | Separate projects |
+
+### Tally vs. Other Platforms
+
+<>
+
+## Success Metrics
+
+Projects using Tally achieve:
+
+<>
+
+## Get Started
+
+- [Benefits for Projects](for-projects.md) - Detailed project benefits
+- [Benefits for Participants](for-participants.md) - Detailed participant benefits
+- [Talk to our team](http://tally.xyz/contact) - Discuss your sale
diff --git a/benefits/for-participants.md b/benefits/for-participants.md
new file mode 100644
index 0000000..5256d7e
--- /dev/null
+++ b/benefits/for-participants.md
@@ -0,0 +1,280 @@
+---
+description: Why participants choose Tally-powered token sales
+---
+
+# Benefits for Participants
+
+Participating in a Tally-powered token sale provides advantages in security, fairness, and ongoing engagement. Here's what participants can expect.
+
+## Trust and Security
+
+### Audited Smart Contracts
+
+Your funds interact with secure code:
+
+- Professional security audits
+- Battle-tested implementations
+- Transparent, verifiable contracts
+- No custody risk - direct wallet interaction
+
+### Established Platform
+
+Tally has a proven track record:
+
+- Used by major protocols
+- Years of operational history
+- Professional team and support
+- Ongoing security focus
+
+### Transparent Mechanics
+
+Know exactly how the sale works:
+
+- Clear documentation
+- Published parameters
+- Verifiable on-chain
+- No hidden mechanics
+
+## Fair Access
+
+### Anti-Whale Protection
+
+Sales designed for broad participation:
+
+**LBPs (Liquidity Bootstrapping Pools):**
+- Declining price discourages large early purchases
+- Patient participants get fair prices
+- Market dynamics prevent manipulation
+
+**CCAs (Continuous Clearing Auctions):**
+- Batch clearing prevents front-running
+- All participants at same clearing price
+- MEV-resistant design
+
+**Fixed-Price Sales:**
+- Allocation limits per wallet
+- Eligibility rules reward genuine supporters
+- Fair distribution mechanisms
+
+### True Price Discovery
+
+Market-driven pricing:
+
+- No predetermined prices to manipulate
+- Collective price discovery
+- Transparent demand signals
+- Fair value through market mechanics
+
+### Equal Treatment
+
+Same rules for everyone:
+
+- Published eligibility criteria
+- Consistent application of rules
+- No special treatment
+- Auditable allocations
+
+## Clear Processes
+
+### Straightforward Participation
+
+Easy to understand and use:
+
+1. **Connect wallet:** Standard wallet connection
+2. **Complete verification:** KYC if required
+3. **Participate:** Buy or bid based on sale type
+4. **Receive tokens:** Direct to your wallet
+
+### Transparent Requirements
+
+Know what's needed before you start:
+
+- Eligibility criteria published
+- Required documents listed
+- Geographic restrictions stated
+- Timeline clearly communicated
+
+### Real-Time Information
+
+Stay informed during the sale:
+
+- Current prices and status
+- Participation metrics
+- Time remaining
+- Your position and allocation
+
+## Compliance Benefits
+
+### Legitimate Sales
+
+Participate with confidence:
+
+- KYC ensures legitimate participants
+- Geographic compliance reduces legal risk
+- Professional compliance framework
+- Regulatory-aware design
+
+### Protection from Scams
+
+Reduced fraud risk:
+
+- Verified projects using Tally
+- Professional execution
+- Established platform reputation
+- Not fly-by-night operations
+
+### Clear Terms
+
+Understand your rights:
+
+- Published terms of service
+- Clear risk disclosures
+- Documented mechanics
+- Professional documentation
+
+## Ongoing Engagement
+
+### Governance Participation
+
+Your tokens come with rights:
+
+- Vote on protocol decisions
+- Delegate to representatives
+- Participate in governance
+- Shape the protocol's future
+
+### Staking Opportunities
+
+Earn rewards on your holdings:
+
+- Staking for protocol revenue share
+- Governance participation rewards
+- Long-term holding incentives
+- Value accrual mechanisms
+
+### Community Membership
+
+Join an engaged community:
+
+- Connect with other stakeholders
+- Participate in discussions
+- Contribute to protocol development
+- Build relationships
+
+## Vesting and Claims
+
+### Clear Schedules
+
+Understand your token timeline:
+
+- Vesting schedules published upfront
+- On-chain enforcement
+- No surprises or changes
+- Transparent unlock dates
+
+### Easy Claims
+
+Simple process to receive tokens:
+
+- User-friendly claim interface
+- Connect wallet, claim tokens
+- Clear visibility into vested amounts
+- Transaction confirmation
+
+### Locked Token Benefits
+
+Even while locked:
+
+- Vote in governance
+- Delegate voting power
+- Earn staking rewards (where enabled)
+- Full participation rights
+
+## What to Look For
+
+### Before Participating
+
+Evaluate any token sale carefully:
+
+**Project fundamentals:**
+- Clear use case for the token
+- Team background and track record
+- Development progress and roadmap
+- Community and ecosystem
+
+**Sale mechanics:**
+- Fair distribution design
+- Reasonable pricing approach
+- Clear compliance framework
+- Post-sale plans
+
+**Platform:**
+- Reputable sale platform (like Tally)
+- Audited contracts
+- Professional execution
+- Clear documentation
+
+### Red Flags
+
+Be cautious of:
+
+- Unclear token utility
+- Anonymous teams
+- No security audits
+- Pressure tactics
+- Unrealistic promises
+- Poor documentation
+
+## Participant Rights
+
+### What You're Entitled To
+
+As a participant, expect:
+
+- Clear information about the sale
+- Fair treatment under published rules
+- Tokens delivered as promised
+- Support for issues or questions
+- Governance rights (if applicable)
+
+### Recourse
+
+If something goes wrong:
+
+- Contact project support
+- Tally support for platform issues
+- Documentation for reference
+- On-chain verification
+
+## Common Questions
+
+### Is my investment safe?
+
+Token sales carry risk. However, Tally's infrastructure is designed for security:
+- Audited contracts protect against technical failures
+- Compliance reduces legal risks for projects
+- Transparent mechanics prevent hidden manipulation
+- But token value is never guaranteed
+
+### How do I know it's legitimate?
+
+Look for:
+- Published audit reports
+- Clear team information
+- Professional documentation
+- Established platforms like Tally
+
+### What happens after the sale?
+
+Typical post-sale experience:
+- Tokens distributed per schedule
+- Governance participation enabled
+- Staking opportunities available
+- Ongoing project development
+
+## See Also
+
+- [Benefits for Projects](for-projects.md)
+- [Token Sales Overview](../token-sales/README.md)
+- [Sale Types](../sale-types/README.md)
+- [Compliance Overview](../compliance/README.md)
diff --git a/benefits/for-projects.md b/benefits/for-projects.md
new file mode 100644
index 0000000..9e76672
--- /dev/null
+++ b/benefits/for-projects.md
@@ -0,0 +1,234 @@
+---
+description: Why projects choose Tally for token sales
+---
+
+# Benefits for Projects
+
+Tally provides everything you need to execute a successful token sale, from infrastructure to compliance to post-sale operations. Here's why leading projects choose Tally.
+
+## Accelerated Time to Market
+
+### Production-Ready Infrastructure
+
+Launch faster than building in-house:
+
+- **Sale mechanics:** LBP, CCA, and fixed-price sales ready to deploy
+- **Smart contracts:** Audited contracts deployed for you
+- **Frontend:** White-labeled sale pages on your domain
+- **Monitoring:** Real-time dashboards from day one
+
+### Reduced Development Burden
+
+Focus on your product, not sale infrastructure:
+
+- No smart contract development required
+- No frontend engineering for sale UI
+- No DevOps for launch infrastructure
+- No security audits to commission
+
+### Typical Timeline
+
+| Phase | DIY Timeline | With Tally |
+|-------|--------------|------------|
+| Planning | 2-4 weeks | 1-2 weeks |
+| Development | 8-16 weeks | 0 weeks |
+| Audits | 4-8 weeks | Included |
+| Testing | 2-4 weeks | 1 week |
+| **Total** | **16-32 weeks** | **2-4 weeks** |
+
+## Comprehensive Compliance
+
+### Built-In Verification
+
+Compliance integrated into the flow:
+
+- **KYC/KYB/KYI:** Identity verification for participants
+- **Geographic controls:** Block or allow specific regions
+- **Allocation limits:** Per-wallet purchase caps
+- **Lockups:** Region-specific vesting schedules
+
+### Reduced Legal Risk
+
+Benefit from established practices:
+
+- Compliance patterns used by major projects
+- Documentation templates available
+- Regulatory-aware design
+- Best practices built in
+
+### Flexibility
+
+Adapt to your specific requirements:
+
+- Configure verification levels
+- Custom geographic rules
+- Project-specific lockup schedules
+- Integration with your legal framework
+
+## Professional Execution
+
+### Launch-Day Support
+
+You're not alone during launch:
+
+- Tally team available during your sale
+- Real-time monitoring and alerts
+- Rapid response to issues
+- Communication support
+
+### Proven Infrastructure
+
+Reliability when it matters:
+
+- Battle-tested at scale
+- High-availability architecture
+- Performance optimization
+- Disaster recovery planning
+
+### Transparent Operations
+
+Build trust with participants:
+
+- Clear sale mechanics
+- Real-time status updates
+- Auditable contracts
+- Professional presentation
+
+## Cost Efficiency
+
+### All-Inclusive Pricing
+
+Predictable costs, no surprises:
+
+- Infrastructure included
+- Audits included
+- Support included
+- Pricing: 2-3% of funds raised
+
+### Comparison to DIY
+
+| Cost Category | DIY | Tally |
+|---------------|-----|-------|
+| Smart contract development | $50-200k | Included |
+| Security audits | $50-200k | Included |
+| Frontend development | $30-100k | Included |
+| Infrastructure | $5-20k | Included |
+| Compliance integration | $20-50k | Included |
+| Launch support | Internal | Included |
+| **Total Fixed Cost** | **$155-570k** | **0** |
+| **Variable Cost** | 0% | 2-3% |
+
+*For a $10M raise, DIY costs $155-570k+ while Tally costs $200-300k - competitive for smaller raises and significantly cheaper development risk.*
+
+### No Hidden Costs
+
+Transparent pricing model:
+
+- No setup fees
+- No monthly fees
+- No per-transaction fees
+- Success-aligned incentives
+
+## Post-Sale Continuity
+
+### Integrated Platform
+
+Keep building with Tally after your sale:
+
+- **Governance:** Proposals, voting, delegation
+- **Staking:** Rewards and value accrual
+- **Incentives:** Participation rewards
+- **Security councils:** Democratic oversight
+
+### No Migration Required
+
+Single platform benefits:
+
+- Consistent user experience
+- Shared identity/KYC
+- Unified analytics
+- Reduced complexity
+
+### Long-Term Partnership
+
+Ongoing support for your token:
+
+- Feature updates
+- New capabilities
+- Platform improvements
+- Dedicated account support
+
+## Credibility and Trust
+
+### Platform Reputation
+
+Benefit from Tally's track record:
+
+<>
+
+### Professional Presentation
+
+First impressions matter:
+
+- Polished sale interfaces
+- Clear, professional UX
+- Trustworthy appearance
+- Established brand
+
+### Participant Confidence
+
+Buyers trust Tally-powered sales:
+
+- Known platform
+- Audited contracts
+- Proven execution
+- Professional support
+
+## Flexibility and Control
+
+### Multiple Sale Mechanisms
+
+Choose the right approach:
+
+- LBPs for broad distribution
+- CCAs for price discovery
+- Fixed-price for controlled allocation
+- Mix and match as needed
+
+### Configurable Parameters
+
+Tune for your goals:
+
+- Pricing and curves
+- Duration and timing
+- Eligibility rules
+- Vesting schedules
+
+### Your Brand
+
+Maintain your identity:
+
+- White-labeled interfaces
+- Custom domains
+- Your branding and design
+- Seamless user experience
+
+## Getting Started
+
+### Next Steps
+
+1. **Initial consultation:** Discuss your goals and requirements
+2. **Sale design:** Choose mechanism and configure parameters
+3. **Compliance setup:** Define eligibility and restrictions
+4. **Testing:** Verify everything works correctly
+5. **Launch:** Execute your sale with support
+
+### Contact
+
+Ready to launch? [Talk to our team](http://tally.xyz/contact) to get started.
+
+## See Also
+
+- [Benefits for Participants](for-participants.md)
+- [Token Sales Overview](../token-sales/README.md)
+- [Choosing Your Sale Type](../token-sales/choosing-your-sale-type.md)
diff --git a/compliance/README.md b/compliance/README.md
new file mode 100644
index 0000000..f819908
--- /dev/null
+++ b/compliance/README.md
@@ -0,0 +1,160 @@
+---
+description: Regulatory compliance tools for token sales
+---
+
+# Compliance Overview
+
+Running a compliant token sale is essential for long-term success. Tally provides integrated compliance tools that help you meet regulatory requirements while maintaining a smooth participant experience.
+
+## Compliance Capabilities
+
+Tally's compliance suite includes:
+
+### Identity Verification
+
+- **KYC (Know Your Customer):** Individual identity verification
+- **KYB (Know Your Business):** Business entity verification
+- **KYI (Know Your Investor):** Accredited investor verification
+
+[Learn more about KYC](kyc-verification.md)
+
+### Geographic Controls
+
+- **Geo-blocking:** Restrict participation by country or region
+- **Region-specific rules:** Different requirements for different jurisdictions
+- **IP and VPN detection:** Prevent circumvention attempts
+
+[Learn more about Geo-Restrictions](geo-restrictions.md)
+
+### Token Lockups
+
+- **Vesting schedules:** Time-based token release
+- **Region-specific lockups:** Different lockup periods by jurisdiction
+- **On-chain enforcement:** Smart contract-based compliance
+
+[Learn more about Vesting & Lockups](vesting-lockups.md)
+
+## Why Compliance Matters
+
+### Regulatory Protection
+
+Operating within legal frameworks:
+
+- Reduces legal risk for your project
+- Protects participants from regulatory action
+- Enables access to regulated markets
+- Supports future exchange listings
+
+### Market Access
+
+Compliant sales can reach more participants:
+
+- Access participants in regulated jurisdictions
+- Attract institutional investors
+- Build trust with cautious participants
+- Enable marketing in compliant channels
+
+### Long-Term Sustainability
+
+Compliance supports project longevity:
+
+- Avoid post-sale legal challenges
+- Maintain relationships with service providers
+- Build reputation for responsible operation
+- Create foundation for future compliance needs
+
+## Compliance Framework
+
+### Pre-Sale Planning
+
+Before your sale:
+
+1. **Jurisdiction analysis:** Identify target and restricted regions
+2. **Participant requirements:** Define who can participate
+3. **Legal review:** Engage counsel familiar with token sales
+4. **Documentation:** Prepare terms of service and risk disclosures
+
+### During the Sale
+
+Active compliance measures:
+
+1. **Identity verification:** KYC/KYB checks before purchase
+2. **Geographic filtering:** Block restricted regions
+3. **Allocation controls:** Enforce per-wallet limits
+4. **Documentation:** Record compliance data
+
+### Post-Sale
+
+Ongoing compliance:
+
+1. **Vesting enforcement:** Smart contract lockups
+2. **Record retention:** Maintain compliance documentation
+3. **Regulatory monitoring:** Track evolving requirements
+4. **Reporting:** Fulfill any reporting obligations
+
+## Integration with Sale Types
+
+All sale mechanisms support full compliance integration:
+
+| Feature | LBP | CCA | Fixed Price |
+|---------|-----|-----|-------------|
+| KYC/KYB/KYI | Yes | Yes | Yes |
+| Geo-blocking | Yes | Yes | Yes |
+| Region-specific lockups | Yes | Yes | Yes |
+| Allocation limits | Yes | Yes | Yes |
+
+## Compliance Partners
+
+Tally integrates with leading compliance providers:
+
+<>
+
+## Regional Considerations
+
+Different regions have different requirements:
+
+### United States
+
+<>
+
+### European Union
+
+<>
+
+### Other Jurisdictions
+
+<>
+
+## Best Practices
+
+### Start Early
+
+Compliance takes time:
+
+- Engage legal counsel early
+- Build compliance into your timeline
+- Don't rush compliance decisions
+
+### Document Everything
+
+Maintain comprehensive records:
+
+- Compliance policies and procedures
+- Participant verification records
+- Decision documentation
+- Regulatory correspondence
+
+### Stay Current
+
+Regulations evolve:
+
+- Monitor regulatory developments
+- Update policies as needed
+- Maintain relationships with legal advisors
+
+## Next Steps
+
+- [KYC Verification](kyc-verification.md) - Identity verification details
+- [Geo-Restrictions](geo-restrictions.md) - Geographic controls
+- [Vesting & Lockups](vesting-lockups.md) - Token lockup mechanisms
+- [Talk to our team](http://tally.xyz/contact) - Discuss your compliance needs
diff --git a/compliance/geo-restrictions.md b/compliance/geo-restrictions.md
new file mode 100644
index 0000000..32e4ddf
--- /dev/null
+++ b/compliance/geo-restrictions.md
@@ -0,0 +1,265 @@
+---
+description: Geographic controls and regional restrictions for token sales
+---
+
+# Geo-Restrictions
+
+Geographic restrictions help you comply with regional regulations by controlling where your token sale is accessible. Tally provides robust geo-blocking capabilities to ensure your sale only reaches permitted jurisdictions.
+
+## Why Geo-Restrictions Matter
+
+### Regulatory Compliance
+
+Different jurisdictions have different rules:
+
+- Some prohibit token sales entirely
+- Others require specific registrations
+- Participant protections vary by region
+- Securities laws differ globally
+
+### Risk Management
+
+Blocking high-risk jurisdictions:
+
+- Reduces legal exposure
+- Simplifies compliance requirements
+- Protects against enforcement actions
+- Clarifies regulatory position
+
+## How Geo-Blocking Works
+
+### Detection Methods
+
+Tally uses multiple signals to determine participant location:
+
+**IP-based detection:**
+- Primary location signal
+- Geolocation databases
+- Regular database updates
+
+**VPN detection:**
+- Identify common VPN services
+- Data center IP flagging
+- Behavioral analysis
+
+**KYC verification:**
+- Document-based location confirmation
+- Address verification
+- Most reliable method
+
+### Enforcement Layers
+
+Multiple enforcement points:
+
+1. **Frontend blocking:** Prevent access to sale page
+2. **Wallet screening:** Check address history and patterns
+3. **KYC verification:** Verify location through documents
+4. **Smart contract:** On-chain enforcement where applicable
+
+## Configuration Options
+
+### Blocklist vs. Allowlist
+
+**Blocklist approach:**
+- Block specific countries/regions
+- Allow all others
+- Simpler for broad sales
+
+**Allowlist approach:**
+- Allow specific countries/regions
+- Block all others
+- More restrictive, maximum control
+
+### Regional Settings
+
+Configure at multiple levels:
+
+| Level | Example | Use Case |
+|-------|---------|----------|
+| Country | United States | National regulations |
+| State/Province | New York | State-specific rules |
+| Region | OFAC sanctioned | Sanctions compliance |
+| Custom | Specific list | Project requirements |
+
+### Restriction Severity
+
+Different actions for restricted regions:
+
+- **Hard block:** Cannot access or participate
+- **Soft block:** Warning message, can proceed with acknowledgment
+- **Limited access:** Can view but not purchase
+- **Enhanced requirements:** Additional verification needed
+
+## Common Restricted Jurisdictions
+
+### Typically Blocked
+
+Most token sales restrict:
+
+<>
+
+### US Considerations
+
+United States requires special attention:
+
+- Federal securities laws
+- State-by-state variations
+- Accredited investor requirements
+- BitLicense states (New York)
+
+<>
+
+### EU Considerations
+
+European Union under MiCA:
+
+- Pan-EU framework coming into effect
+- Member state variations
+- Prospectus requirements
+- Consumer protection rules
+
+<>
+
+## Implementation
+
+### Technical Setup
+
+Tally configures geo-blocking:
+
+1. **Define restricted regions:** Provide your blocklist/allowlist
+2. **Select detection methods:** IP, VPN detection, KYC
+3. **Configure enforcement:** Hard/soft blocking, warnings
+4. **Test configuration:** Verify correct behavior
+
+### Integration with KYC
+
+Geo-restrictions work with KYC:
+
+- Location verified through documents
+- More reliable than IP-based detection
+- Supports region-specific requirements
+- Creates audit trail
+
+### Smart Contract Integration
+
+On-chain enforcement options:
+
+- Address allowlists in contracts
+- Attestation-based verification
+- Integration with on-chain identity
+
+## Region-Specific Rules
+
+### Differentiated Treatment
+
+Some sales need varied rules by region:
+
+| Region | KYC Level | Lockup | Allocation |
+|--------|-----------|--------|------------|
+| US Accredited | KYI | 12 months | Unlimited |
+| EU | KYC | 6 months | $50,000 max |
+| Asia | KYC | None | $25,000 max |
+
+### Lockup Variations
+
+Different lockups by jurisdiction:
+
+- Regulatory requirements may mandate lockups
+- Optionally extend for certain regions
+- On-chain enforcement via vesting contracts
+
+See [Vesting & Lockups](vesting-lockups.md) for details.
+
+## Handling Edge Cases
+
+### VPN Usage
+
+Participants may try to circumvent restrictions:
+
+- VPN detection helps identify
+- KYC provides verification
+- Terms of service prohibit circumvention
+- Technical measures are not foolproof
+
+### Expatriates and Travelers
+
+Address common questions:
+
+- Citizenship vs. residence rules
+- Temporary travel handling
+- Document requirements for expats
+
+### Dual Citizens
+
+Handle multiple citizenship:
+
+- Define policy clearly
+- Most restrictive approach common
+- Document in terms of service
+
+## Compliance Documentation
+
+### Record Keeping
+
+Maintain records of:
+
+- Restriction configuration
+- Blocked access attempts
+- Override decisions
+- Policy changes
+
+### Terms of Service
+
+Your terms should include:
+
+- Geographic restrictions clearly stated
+- Prohibited circumvention
+- Participant representation of location
+- Consequences of misrepresentation
+
+### Legal Disclaimers
+
+Standard disclaimers:
+
+<>
+
+## Best Practices
+
+### Conservative Approach
+
+When in doubt:
+
+- Block rather than allow
+- Consult legal counsel
+- Document decision rationale
+
+### Clear Communication
+
+Inform participants:
+
+- List restricted jurisdictions clearly
+- Explain why restrictions exist
+- Provide guidance for edge cases
+
+### Regular Review
+
+Regulations change:
+
+- Monitor regulatory developments
+- Update restrictions as needed
+- Document all changes
+
+## Testing Your Configuration
+
+Before launch:
+
+- [ ] Test access from blocked regions (via VPN)
+- [ ] Verify blocking messages display correctly
+- [ ] Confirm KYC flow respects geo-restrictions
+- [ ] Test edge cases and overrides
+
+## Next Steps
+
+- [KYC Verification](kyc-verification.md) - Identity verification
+- [Vesting & Lockups](vesting-lockups.md) - Token lockup mechanisms
+- [Compliance Overview](README.md) - Full compliance guide
diff --git a/compliance/kyc-verification.md b/compliance/kyc-verification.md
new file mode 100644
index 0000000..1de2092
--- /dev/null
+++ b/compliance/kyc-verification.md
@@ -0,0 +1,244 @@
+---
+description: Identity verification for token sale participants
+---
+
+# KYC Verification
+
+Know Your Customer (KYC) verification helps ensure your token sale meets regulatory requirements by verifying participant identities. Tally integrates KYC seamlessly into the sale flow, balancing compliance with user experience.
+
+## Types of Verification
+
+### KYC - Know Your Customer
+
+Standard individual identity verification:
+
+- **Purpose:** Verify individual participant identity
+- **Documents:** Government ID, proof of address
+- **Use case:** Retail participants
+
+### KYB - Know Your Business
+
+Business entity verification:
+
+- **Purpose:** Verify business entities and beneficial owners
+- **Documents:** Business registration, ownership structure
+- **Use case:** Corporate participants, DAOs
+
+### KYI - Know Your Investor
+
+Accredited investor verification:
+
+- **Purpose:** Verify accredited investor status
+- **Documents:** Financial statements, professional certifications
+- **Use case:** Sales requiring accredited investors
+
+## How KYC Works in Tally
+
+### Participant Flow
+
+1. **Connect Wallet:** Participant connects their wallet to the sale page
+2. **Start Verification:** Redirected to KYC provider interface
+3. **Submit Documents:** Upload required identity documents
+4. **Verification:** Provider verifies documents (usually minutes)
+5. **Approval:** Wallet address is approved for participation
+6. **Purchase:** Participant can now buy tokens
+
+### Project Configuration
+
+Configure KYC requirements:
+
+| Setting | Options | Description |
+|---------|---------|-------------|
+| Verification Level | KYC, KYB, KYI | Type of verification required |
+| Required Documents | ID, Proof of Address, etc. | Documents participants must provide |
+| Approval Flow | Auto, Manual | Automatic or manual approval |
+| Validity Period | 30-365 days | How long verification remains valid |
+
+## Integrated Providers
+
+Tally integrates with leading KYC providers:
+
+<>
+
+### Provider Selection Criteria
+
+When choosing a provider, consider:
+
+- **Geographic coverage:** Support for your target regions
+- **Verification speed:** Time to complete verification
+- **User experience:** Ease of use for participants
+- **Document support:** ID types accepted
+- **Compliance standards:** Certifications and audits
+
+## Configuration Options
+
+### Verification Requirements
+
+Define what's required:
+
+**Minimum verification:**
+- Government-issued photo ID
+- Selfie/liveness check
+
+**Enhanced verification:**
+- Proof of address
+- Source of funds declaration
+- Additional screening
+
+### Approval Workflows
+
+**Automatic approval:**
+- Verification completes instantly when documents clear
+- Best for standard KYC requirements
+- Faster participant experience
+
+**Manual review:**
+- Team reviews before final approval
+- Required for edge cases or enhanced due diligence
+- Adds processing time
+
+### Re-verification
+
+Set policies for ongoing verification:
+
+- Validity period before re-verification required
+- Triggers for additional verification (large purchases, etc.)
+- Handling of expired verifications
+
+## User Experience Considerations
+
+### Minimizing Friction
+
+KYC can create friction. Reduce impact by:
+
+- Allowing pre-registration before sale starts
+- Clear communication about requirements
+- Fast verification provider
+- Responsive support for issues
+
+### Communication
+
+Set expectations clearly:
+
+- Explain why KYC is required
+- List required documents in advance
+- Provide estimated verification time
+- Offer support channels
+
+### Common Issues
+
+**Document rejection:**
+- Provide clear guidance on acceptable documents
+- Allow multiple submission attempts
+- Have support available to assist
+
+**Verification delays:**
+- Set realistic time expectations
+- Consider opening verification early
+- Plan for peak demand
+
+## Privacy and Data Handling
+
+### Data Storage
+
+KYC data is handled securely:
+
+- Stored by KYC provider, not Tally
+- Encrypted at rest and in transit
+- Retention policies per regulations
+- Deletion upon request where permitted
+
+### Participant Privacy
+
+Respect participant privacy:
+
+- Collect minimum necessary data
+- Clear privacy policies
+- Transparent about data usage
+- Honor deletion requests
+
+<>
+
+## Compliance Considerations
+
+### Regulatory Requirements
+
+Different jurisdictions require different verification levels:
+
+| Jurisdiction | Typical Requirement |
+|--------------|---------------------|
+| United States | KYC + Accredited (for some sales) |
+| European Union | KYC per MiCA framework |
+| Singapore | KYC per MAS guidance |
+| Other | Varies by jurisdiction |
+
+### Sanctions Screening
+
+All verifications include:
+
+- OFAC screening (US sanctions)
+- EU sanctions list screening
+- Other relevant sanctions lists
+- Ongoing monitoring
+
+### Record Keeping
+
+Maintain compliance records:
+
+- Verification completion records
+- Document retention per regulations
+- Audit trail for approvals
+- Compliance reporting
+
+## Best Practices
+
+### Pre-Sale Preparation
+
+Before your sale:
+
+- Select and test KYC provider
+- Open verification 1-2 weeks early
+- Prepare support documentation
+- Train support team on common issues
+
+### During the Sale
+
+Active management:
+
+- Monitor verification queue
+- Respond quickly to escalations
+- Track completion rates
+- Communicate proactively about issues
+
+### Post-Sale
+
+Ongoing compliance:
+
+- Retain records per requirements
+- Monitor for regulatory changes
+- Update processes as needed
+
+## Troubleshooting
+
+### Common Issues
+
+**Low completion rates:**
+- Review document requirements
+- Check user experience friction
+- Verify geographic coverage
+
+**Slow verification:**
+- Check provider capacity
+- Review manual review queue
+- Consider additional provider
+
+**High rejection rates:**
+- Improve document guidance
+- Review rejection reasons
+- Adjust requirements if appropriate
+
+## Next Steps
+
+- [Geo-Restrictions](geo-restrictions.md) - Geographic controls
+- [Vesting & Lockups](vesting-lockups.md) - Token lockup mechanisms
+- [Running Your Sale](../token-sales/running-your-sale.md) - Execution guide
diff --git a/compliance/vesting-lockups.md b/compliance/vesting-lockups.md
new file mode 100644
index 0000000..5f3c8d6
--- /dev/null
+++ b/compliance/vesting-lockups.md
@@ -0,0 +1,302 @@
+---
+description: Token lockup periods and vesting schedules for compliance
+---
+
+# Vesting & Lockups
+
+Token lockups and vesting schedules control when participants can access their purchased tokens. These mechanisms serve both regulatory compliance and tokenomics goals, ensuring aligned incentives and meeting jurisdictional requirements.
+
+## Why Lockups Matter
+
+### Regulatory Compliance
+
+Many jurisdictions require or recommend lockups:
+
+- Securities regulations may mandate holding periods
+- Lockups can help distinguish utility from security
+- Different regions may require different periods
+- Demonstrates long-term alignment
+
+### Tokenomics Benefits
+
+Beyond compliance, lockups serve project goals:
+
+- Prevent immediate sell pressure
+- Encourage long-term holding
+- Align participant incentives
+- Support price stability at launch
+
+## Types of Lockups
+
+### Linear Vesting
+
+Tokens unlock gradually over time:
+
+```
+ 100% |................._____
+ | ___/
+Unlocked | ___/
+ | ___/
+ |___/
+ 0% +----------------------
+ Start End
+ Time
+```
+
+**Example:** 12-month linear vesting releases ~8.33% per month
+
+### Cliff Vesting
+
+Initial lockup followed by partial or full unlock:
+
+```
+ 100% |................_____
+ | |
+Unlocked | |
+ | |
+ |_______________|
+ 0% +----------------------
+ Start Cliff End
+ Time
+```
+
+**Example:** 6-month cliff, then linear vesting for remaining 6 months
+
+### Milestone Vesting
+
+Tokens unlock based on specific events:
+
+- Product launches
+- Revenue targets
+- Governance votes
+- Time-based checkpoints
+
+### Region-Specific Lockups
+
+Different vesting for different jurisdictions:
+
+| Region | Lockup Period | Vesting Type |
+|--------|---------------|--------------|
+| US Accredited | 12 months | Cliff |
+| EU | 6 months | Linear |
+| Asia-Pacific | 3 months | Linear |
+| Other | None | Immediate |
+
+## Configuration Options
+
+### Timing Parameters
+
+| Parameter | Description | Typical Range |
+|-----------|-------------|---------------|
+| Cliff Period | Initial lockup before any unlock | 0-12 months |
+| Vesting Duration | Total time until fully vested | 6-48 months |
+| Unlock Frequency | How often tokens vest | Daily/Weekly/Monthly |
+
+### Unlock Amounts
+
+| Parameter | Description | Options |
+|-----------|-------------|---------|
+| Initial Unlock | Tokens available at purchase | 0-25% typical |
+| Cliff Unlock | Released at cliff end | 10-50% typical |
+| Linear Release | Ongoing vesting rate | Remaining balance |
+
+### Triggers
+
+| Trigger | Description | Use Case |
+|---------|-------------|----------|
+| Time-based | Calendar date/duration | Standard vesting |
+| Block-based | Blockchain blocks | Chain-native timing |
+| Event-based | Specific conditions | Milestone vesting |
+
+## Technical Implementation
+
+### On-Chain Enforcement
+
+Lockups are enforced via smart contracts:
+
+- Tokens held in vesting contracts
+- Participants claim as tokens vest
+- Non-custodial design
+- Audited, battle-tested contracts
+
+### Vesting Contract Mechanics
+
+1. **Deposit:** Tokens locked at sale close
+2. **Tracking:** Contract tracks vested amounts
+3. **Claiming:** Participants claim vested tokens
+4. **Verification:** Contract verifies eligibility
+
+### Integration with Sale
+
+Vesting integrates with your sale:
+
+- Configured during sale setup
+- Applied automatically at distribution
+- Region-specific rules applied per KYC
+- Unified participant experience
+
+## Claim Interface
+
+### Participant Experience
+
+Tally provides a claim interface:
+
+1. **Connect wallet:** Participant connects verified wallet
+2. **View schedule:** See full vesting timeline
+3. **Check vested:** View currently claimable amount
+4. **Claim tokens:** Execute on-chain claim transaction
+5. **Track history:** View past claims
+
+### Dashboard Information
+
+Participants see:
+
+- Total tokens purchased
+- Vested (claimable) amount
+- Claimed amount
+- Remaining locked amount
+- Next unlock date
+- Full vesting schedule
+
+## Region-Specific Configuration
+
+### US Requirements
+
+<>
+
+### EU Requirements
+
+<>
+
+### Other Jurisdictions
+
+<>
+
+## Common Configurations
+
+### Conservative (High Compliance)
+
+For sales requiring maximum compliance:
+
+```
+Initial unlock: 0%
+Cliff: 12 months
+Vesting: 24 months linear after cliff
+Total lockup: 36 months
+```
+
+### Balanced
+
+For standard compliance with some liquidity:
+
+```
+Initial unlock: 10%
+Cliff: 6 months
+Vesting: 12 months linear after cliff
+Total lockup: 18 months
+```
+
+### Minimal
+
+For sales with fewer restrictions:
+
+```
+Initial unlock: 25%
+Cliff: None
+Vesting: 3 months linear
+Total lockup: 3 months
+```
+
+## Best Practices
+
+### Clear Communication
+
+Before the sale:
+
+- Publish vesting schedules clearly
+- Explain regional differences
+- Provide claim instructions
+- Set expectations on timing
+
+### Fair Design
+
+Balance stakeholder interests:
+
+- Sufficient lockup for compliance
+- Reasonable access for participants
+- Consistent with tokenomics
+- Aligned with team vesting
+
+### Technical Testing
+
+Before launch:
+
+- Test vesting contracts on testnet
+- Verify claim flow works correctly
+- Test regional differentiation
+- Audit smart contracts
+
+## Modifying Lockups
+
+### Can Lockups Be Changed?
+
+Generally, on-chain lockups are immutable:
+
+- Provides participant certainty
+- Enforces committed schedules
+- Cannot be shortened unilaterally
+
+### Emergency Provisions
+
+In rare cases:
+
+- Governance-approved changes (if applicable)
+- Migration to new contracts (complex)
+- Generally avoid if possible
+
+## Integration with Governance
+
+### Locked Token Voting
+
+Locked tokens may retain governance rights:
+
+- Configure voting with locked tokens
+- Delegation while locked
+- Integration with Tally governance
+
+See [Governance Overview](../post-launch-tooling/governance-overview.md)
+
+### Staking Integration
+
+Locked tokens may be stakeable:
+
+- Earn rewards while locked
+- Compounding vesting
+- Integration with Tally staking
+
+See [Staking & Incentives](../post-launch-tooling/staking-incentives.md)
+
+## Troubleshooting
+
+### Common Issues
+
+**Participants can't claim:**
+- Verify wallet connection
+- Check vested amount is non-zero
+- Confirm gas available for transaction
+
+**Wrong vesting schedule:**
+- Check KYC-determined region
+- Verify configuration applied correctly
+- Review purchase records
+
+**Contract issues:**
+- Contact Tally support
+- Review transaction errors
+- Check contract status
+
+## Next Steps
+
+- [KYC Verification](kyc-verification.md) - Identity verification
+- [Geo-Restrictions](geo-restrictions.md) - Geographic controls
+- [After Your Sale](../token-sales/after-your-sale.md) - Post-sale operations
diff --git a/developers/README.md b/developers/README.md
new file mode 100644
index 0000000..db2ffeb
--- /dev/null
+++ b/developers/README.md
@@ -0,0 +1,157 @@
+---
+description: Technical documentation for developers
+---
+
+# Developers Overview
+
+This section provides technical documentation for developers building on or integrating with Tally's token sale and governance infrastructure.
+
+## Available Resources
+
+### API Documentation
+
+Programmatic access to Tally's platform:
+
+- REST API endpoints
+- GraphQL queries
+- Webhook integrations
+- Rate limits and authentication
+
+[View API Documentation](api-documentation.md)
+
+### Smart Contracts
+
+Understand and interact with on-chain components:
+
+- Contract addresses and ABIs
+- Interaction guides
+- Integration patterns
+- Security considerations
+
+[View Smart Contract Documentation](smart-contracts.md)
+
+## Integration Patterns
+
+### Common Use Cases
+
+**Frontend Integration:**
+- Embed sale widgets
+- Custom sale interfaces
+- Real-time data display
+- User authentication
+
+**Backend Integration:**
+- Webhook processing
+- Data synchronization
+- Automated workflows
+- Reporting and analytics
+
+**Smart Contract Integration:**
+- Composability patterns
+- Cross-protocol interactions
+- Custom extensions
+- Upgrade patterns
+
+## Getting Started
+
+### Prerequisites
+
+Before integrating:
+
+- [ ] Tally account and API access
+- [ ] Development environment setup
+- [ ] Test network access (for development)
+- [ ] Understanding of EVM basics
+
+### Quick Start
+
+1. **Get API credentials:** Contact Tally for developer access
+2. **Review documentation:** Understand available endpoints
+3. **Start on testnet:** Build and test integrations safely
+4. **Deploy to production:** Launch with confidence
+
+## SDKs and Libraries
+
+<>
+
+### Supported Languages
+
+- JavaScript/TypeScript
+- Python
+- Go
+- Rust
+
+### Example Code
+
+<>
+
+## Development Environment
+
+### Testnets
+
+Develop safely on test networks:
+
+- Sepolia (Ethereum testnet)
+- Arbitrum Sepolia
+- Base Sepolia
+- Other supported testnets
+
+### Local Development
+
+Set up local environments:
+
+<>
+
+## Security Considerations
+
+### API Security
+
+Protect your integration:
+
+- Secure API key storage
+- Use environment variables
+- Implement rate limiting
+- Monitor for abuse
+
+### Smart Contract Security
+
+When integrating with contracts:
+
+- Verify contract addresses
+- Understand function behaviors
+- Handle reverts gracefully
+- Test thoroughly
+
+### User Security
+
+Protect your users:
+
+- Never store private keys
+- Validate user inputs
+- Implement proper authentication
+- Follow security best practices
+
+## Support
+
+### Developer Resources
+
+- Documentation (this site)
+- API reference
+- Code examples
+- Community forums
+
+### Getting Help
+
+<>
+
+## Changelog
+
+Stay updated on API and contract changes:
+
+<>
+
+## Next Steps
+
+- [API Documentation](api-documentation.md) - Detailed API reference
+- [Smart Contracts](smart-contracts.md) - Contract documentation
+- [Talk to our team](http://tally.xyz/contact) - Developer partnerships
diff --git a/developers/api-documentation.md b/developers/api-documentation.md
new file mode 100644
index 0000000..ecc6792
--- /dev/null
+++ b/developers/api-documentation.md
@@ -0,0 +1,401 @@
+---
+description: API reference for Tally's platform
+---
+
+# API Documentation
+
+Tally provides APIs for programmatic access to token sale data, governance information, and platform functionality.
+
+## Overview
+
+### Available APIs
+
+| API | Protocol | Use Case |
+|-----|----------|----------|
+| REST API | HTTP/JSON | General data access |
+| GraphQL | GraphQL | Flexible queries |
+| Webhooks | HTTP callbacks | Real-time notifications |
+
+### Base URLs
+
+<>
+
+| Environment | Base URL |
+|-------------|----------|
+| Production | `https://api.tally.xyz/...` |
+| Testnet | `https://api.testnet.tally.xyz/...` |
+
+## Authentication
+
+### API Keys
+
+Authenticate requests with API keys:
+
+```bash
+curl -H "Authorization: Bearer YOUR_API_KEY" \
+ https://api.tally.xyz/v1/...
+```
+
+### Obtaining Keys
+
+<>
+
+### Key Security
+
+Best practices for API key management:
+
+- Store in environment variables
+- Never commit to version control
+- Rotate keys periodically
+- Use separate keys for development/production
+
+## Rate Limits
+
+### Default Limits
+
+<>
+
+| Endpoint Type | Limit |
+|---------------|-------|
+| Read operations | X requests/minute |
+| Write operations | Y requests/minute |
+| Webhooks | Z per event |
+
+### Rate Limit Headers
+
+Responses include rate limit information:
+
+```
+X-RateLimit-Limit: 100
+X-RateLimit-Remaining: 99
+X-RateLimit-Reset: 1640000000
+```
+
+### Handling Rate Limits
+
+When rate limited:
+
+1. Check `X-RateLimit-Reset` header
+2. Implement exponential backoff
+3. Cache responses where appropriate
+4. Consider request batching
+
+## REST API
+
+### Token Sales
+
+#### List Sales
+
+Get information about token sales:
+
+```http
+GET /v1/sales
+```
+
+**Parameters:**
+<>
+
+**Response:**
+<>
+
+#### Get Sale Details
+
+Get details for a specific sale:
+
+```http
+GET /v1/sales/{saleId}
+```
+
+**Response:**
+<>
+
+#### Get Sale Participants
+
+List participants in a sale:
+
+```http
+GET /v1/sales/{saleId}/participants
+```
+
+**Parameters:**
+<>
+
+### Governance
+
+#### List DAOs
+
+Get list of DAOs on Tally:
+
+```http
+GET /v1/daos
+```
+
+#### Get DAO Details
+
+Get details for a specific DAO:
+
+```http
+GET /v1/daos/{daoId}
+```
+
+#### List Proposals
+
+Get proposals for a DAO:
+
+```http
+GET /v1/daos/{daoId}/proposals
+```
+
+#### Get Proposal Details
+
+Get details for a specific proposal:
+
+```http
+GET /v1/proposals/{proposalId}
+```
+
+### Staking
+
+#### Get Staking Positions
+
+Get staking positions for an address:
+
+```http
+GET /v1/staking/positions/{address}
+```
+
+#### Get Staking Stats
+
+Get aggregate staking statistics:
+
+```http
+GET /v1/staking/stats/{contractAddress}
+```
+
+## GraphQL API
+
+### Endpoint
+
+<>
+
+```
+POST https://api.tally.xyz/graphql
+```
+
+### Schema
+
+<>
+
+### Example Queries
+
+#### Get Sale Information
+
+```graphql
+query GetSale($id: ID!) {
+ sale(id: $id) {
+ id
+ name
+ status
+ startTime
+ endTime
+ totalRaised
+ participants {
+ count
+ }
+ }
+}
+```
+
+#### Get DAO Proposals
+
+```graphql
+query GetProposals($daoId: ID!, $first: Int) {
+ proposals(daoId: $daoId, first: $first) {
+ edges {
+ node {
+ id
+ title
+ status
+ forVotes
+ againstVotes
+ }
+ }
+ }
+}
+```
+
+#### Get Voter Participation
+
+```graphql
+query GetVoterStats($address: String!) {
+ voter(address: $address) {
+ totalVotes
+ proposalsVoted
+ delegatedPower
+ delegations {
+ from
+ amount
+ }
+ }
+}
+```
+
+## Webhooks
+
+### Available Events
+
+<>
+
+| Event | Description |
+|-------|-------------|
+| `sale.started` | Token sale has started |
+| `sale.ended` | Token sale has ended |
+| `sale.participation` | New participation recorded |
+| `proposal.created` | New proposal created |
+| `proposal.executed` | Proposal executed |
+
+### Webhook Setup
+
+Register webhook endpoints:
+
+<>
+
+### Payload Format
+
+Webhook payloads follow this structure:
+
+```json
+{
+ "event": "sale.participation",
+ "timestamp": "2024-01-15T12:00:00Z",
+ "data": {
+ "saleId": "...",
+ "participant": "0x...",
+ "amount": "1000000000000000000"
+ },
+ "signature": "..."
+}
+```
+
+### Verifying Webhooks
+
+Verify webhook authenticity:
+
+<>
+
+### Retry Policy
+
+Failed webhook deliveries are retried:
+
+- First retry: 1 minute
+- Second retry: 5 minutes
+- Third retry: 30 minutes
+- Final retry: 2 hours
+
+## Error Handling
+
+### Error Format
+
+Errors follow a consistent format:
+
+```json
+{
+ "error": {
+ "code": "INVALID_PARAMETER",
+ "message": "The 'address' parameter is invalid",
+ "details": {
+ "parameter": "address",
+ "value": "invalid"
+ }
+ }
+}
+```
+
+### Common Error Codes
+
+| Code | HTTP Status | Description |
+|------|-------------|-------------|
+| `UNAUTHORIZED` | 401 | Invalid or missing API key |
+| `FORBIDDEN` | 403 | Insufficient permissions |
+| `NOT_FOUND` | 404 | Resource not found |
+| `RATE_LIMITED` | 429 | Rate limit exceeded |
+| `INVALID_PARAMETER` | 400 | Invalid request parameter |
+| `INTERNAL_ERROR` | 500 | Server error |
+
+## Code Examples
+
+### JavaScript/TypeScript
+
+```typescript
+import axios from 'axios';
+
+const client = axios.create({
+ baseURL: 'https://api.tally.xyz/v1',
+ headers: {
+ 'Authorization': `Bearer ${process.env.TALLY_API_KEY}`
+ }
+});
+
+// Get sale details
+async function getSale(saleId: string) {
+ const response = await client.get(`/sales/${saleId}`);
+ return response.data;
+}
+
+// List proposals
+async function getProposals(daoId: string) {
+ const response = await client.get(`/daos/${daoId}/proposals`);
+ return response.data;
+}
+```
+
+### Python
+
+```python
+import requests
+import os
+
+class TallyClient:
+ def __init__(self):
+ self.base_url = "https://api.tally.xyz/v1"
+ self.headers = {
+ "Authorization": f"Bearer {os.environ['TALLY_API_KEY']}"
+ }
+
+ def get_sale(self, sale_id: str):
+ response = requests.get(
+ f"{self.base_url}/sales/{sale_id}",
+ headers=self.headers
+ )
+ response.raise_for_status()
+ return response.json()
+
+ def get_proposals(self, dao_id: str):
+ response = requests.get(
+ f"{self.base_url}/daos/{dao_id}/proposals",
+ headers=self.headers
+ )
+ response.raise_for_status()
+ return response.json()
+```
+
+## SDK Documentation
+
+<>
+
+## Changelog
+
+<>
+
+## Support
+
+For API support:
+
+- Documentation issues: Open a GitHub issue
+- Technical questions: Developer Discord
+- Enterprise support: Contact your account manager
+
+## See Also
+
+- [Smart Contracts](smart-contracts.md) - Contract documentation
+- [Developers Overview](README.md) - Getting started
diff --git a/developers/smart-contracts.md b/developers/smart-contracts.md
new file mode 100644
index 0000000..97f5c7d
--- /dev/null
+++ b/developers/smart-contracts.md
@@ -0,0 +1,349 @@
+---
+description: Smart contract documentation and integration guide
+---
+
+# Smart Contracts
+
+This documentation covers the smart contracts used in Tally's token sale and governance infrastructure, including addresses, ABIs, and integration patterns.
+
+## Contract Overview
+
+### Token Sale Contracts
+
+| Contract | Purpose | Chains |
+|----------|---------|--------|
+| LBP Controller | Manages LBP sales | Ethereum, L2s |
+| CCA Controller | Manages CCA auctions | Ethereum, L2s |
+| Fixed Sale | Fixed-price sale logic | Ethereum, L2s |
+| Vesting | Token lockups | All supported |
+
+### Governance Contracts
+
+| Contract | Purpose | Standard |
+|----------|---------|----------|
+| Governor | Proposal and voting | OZ Governor |
+| Timelock | Execution delay | OZ TimelockController |
+| Token | Governance token | ERC20Votes |
+
+### Staking Contracts
+
+| Contract | Purpose | Features |
+|----------|---------|----------|
+| Staking | Token staking | Rewards, governance |
+| LST | Liquid staking token | ERC20, composable |
+| Rewards | Distribution logic | Multiple tokens |
+
+## Contract Addresses
+
+### Mainnet
+
+<>
+
+| Contract | Address | Verified |
+|----------|---------|----------|
+| LBP Controller | `0x...` | Etherscan |
+| CCA Controller | `0x...` | Etherscan |
+| Vesting Factory | `0x...` | Etherscan |
+
+### Arbitrum
+
+<>
+
+### Base
+
+<>
+
+### Testnets
+
+<>
+
+## ABIs
+
+### Obtaining ABIs
+
+ABIs are available via:
+
+1. **Verified contracts:** Etherscan and block explorers
+2. **NPM package:** `@tally/contracts`
+3. **GitHub:** Contract repository
+4. **API:** `GET /v1/contracts/{address}/abi`
+
+### NPM Package
+
+```bash
+npm install @tally/contracts
+```
+
+```typescript
+import { LBPController__factory } from '@tally/contracts';
+
+const controller = LBPController__factory.connect(
+ contractAddress,
+ signer
+);
+```
+
+## Integration Patterns
+
+### Reading Sale Data
+
+Query sale state from contracts:
+
+```typescript
+// Get sale information
+const saleInfo = await controller.getSaleInfo(saleId);
+
+// Get participant allocation
+const allocation = await controller.getAllocation(saleId, userAddress);
+
+// Check if sale is active
+const isActive = await controller.isActive(saleId);
+```
+
+### Participating in Sales
+
+Interact with sale contracts:
+
+```typescript
+// Approve token spend (for payment token)
+await paymentToken.approve(controllerAddress, amount);
+
+// Participate in sale
+await controller.participate(saleId, amount, {
+ gasLimit: estimatedGas
+});
+```
+
+### Claiming Tokens
+
+Claim purchased/vested tokens:
+
+```typescript
+// Check claimable amount
+const claimable = await vesting.getClaimableAmount(userAddress);
+
+// Claim tokens
+await vesting.claim();
+```
+
+### Governance Integration
+
+Interact with governance:
+
+```typescript
+// Create proposal
+const proposalId = await governor.propose(
+ targets,
+ values,
+ calldatas,
+ description
+);
+
+// Cast vote
+await governor.castVote(proposalId, support);
+
+// Execute proposal
+await governor.execute(
+ targets,
+ values,
+ calldatas,
+ descriptionHash
+);
+```
+
+## Events
+
+### Sale Events
+
+Monitor sale activity:
+
+```solidity
+event SaleCreated(uint256 indexed saleId, address indexed creator);
+event Participated(uint256 indexed saleId, address indexed participant, uint256 amount);
+event SaleCompleted(uint256 indexed saleId, uint256 totalRaised);
+event TokensClaimed(uint256 indexed saleId, address indexed participant, uint256 amount);
+```
+
+### Governance Events
+
+Monitor governance activity:
+
+```solidity
+event ProposalCreated(uint256 proposalId, address proposer, ...);
+event VoteCast(address indexed voter, uint256 proposalId, uint8 support, uint256 weight);
+event ProposalExecuted(uint256 proposalId);
+```
+
+### Listening to Events
+
+```typescript
+// Filter for participation events
+const filter = controller.filters.Participated(saleId, null, null);
+
+// Listen for new events
+controller.on(filter, (saleId, participant, amount, event) => {
+ console.log(`${participant} participated with ${amount}`);
+});
+
+// Query historical events
+const events = await controller.queryFilter(filter, fromBlock, toBlock);
+```
+
+## Security Considerations
+
+### Contract Verification
+
+Always verify contracts before interaction:
+
+1. Check contract is verified on block explorer
+2. Verify address matches official documentation
+3. Review audit reports
+4. Compare bytecode if needed
+
+### Transaction Safety
+
+Safe transaction practices:
+
+- Simulate transactions before sending
+- Set appropriate gas limits
+- Use slippage protection where applicable
+- Verify transaction parameters
+
+### Approval Management
+
+Manage token approvals carefully:
+
+- Approve only required amounts
+- Revoke unused approvals
+- Use permit where supported
+- Monitor approval status
+
+## Audit Reports
+
+### Token Sale Contracts
+
+<>
+
+| Auditor | Date | Report |
+|---------|------|--------|
+| [Auditor 1] | 2024-XX | [Link] |
+| [Auditor 2] | 2024-XX | [Link] |
+
+### Governance Contracts
+
+Tally uses OpenZeppelin contracts:
+
+- [OpenZeppelin Governor Audit](https://github.com/OpenZeppelin/openzeppelin-contracts/tree/master/audits)
+- Additional custom logic audits: <>
+
+### Staking Contracts
+
+<>
+
+## Upgradeability
+
+### Upgrade Patterns
+
+Tally contracts use established upgrade patterns:
+
+- **Proxy patterns:** UUPS or Transparent Proxy
+- **Governance-controlled:** Upgrades require governance approval
+- **Timelock protection:** Upgrade delay for review
+
+### Checking Implementations
+
+```typescript
+// Get implementation address (for proxy contracts)
+const implementation = await upgrades.erc1967.getImplementationAddress(
+ proxyAddress
+);
+```
+
+## Gas Optimization
+
+### Estimated Gas Costs
+
+<>
+
+| Operation | Estimated Gas |
+|-----------|---------------|
+| Participate in sale | ~150,000 |
+| Claim tokens | ~80,000 |
+| Cast vote | ~100,000 |
+| Delegate | ~80,000 |
+
+### Optimization Tips
+
+- Batch operations where possible
+- Use multicall for read operations
+- Consider L2s for cost-sensitive operations
+- Monitor gas prices for optimal timing
+
+## Multichain Considerations
+
+### Cross-Chain Deployment
+
+Contracts are deployed on multiple chains:
+
+- Same logic, different addresses
+- Chain-specific optimizations
+- Cross-chain messaging for some features
+
+### Chain-Specific Details
+
+<>
+
+## Testing
+
+### Test Networks
+
+Test integrations on:
+
+- Sepolia (Ethereum)
+- Arbitrum Sepolia
+- Base Sepolia
+
+### Test Tokens
+
+<>
+
+### Local Testing
+
+Fork mainnet for local testing:
+
+```bash
+anvil --fork-url https://eth-mainnet.alchemyapi.io/v2/YOUR_KEY
+```
+
+## Troubleshooting
+
+### Common Issues
+
+**Transaction reverts:**
+- Check allowances are sufficient
+- Verify sale is active
+- Ensure eligibility requirements met
+- Review error message
+
+**Gas estimation fails:**
+- Transaction would revert
+- Check contract state
+- Verify parameters
+
+**Events not appearing:**
+- Check block range
+- Verify filter parameters
+- Consider indexing delay
+
+## Support
+
+For contract-related questions:
+
+- Technical documentation: This page
+- Developer Discord: <>
+- Security issues: security@tally.xyz
+
+## See Also
+
+- [API Documentation](api-documentation.md) - API reference
+- [Developers Overview](README.md) - Getting started
diff --git a/post-launch-tooling/README.md b/post-launch-tooling/README.md
new file mode 100644
index 0000000..58efd99
--- /dev/null
+++ b/post-launch-tooling/README.md
@@ -0,0 +1,178 @@
+---
+description: Continue building with Tally after your token sale
+---
+
+# Post-Launch Tooling Overview
+
+Your token sale is just the beginning. Tally provides a complete platform for your token's lifecycle, from governance and voting to staking and security councils. No need to switch providers - keep building with the same platform.
+
+## Why Post-Launch Matters
+
+A successful token sale creates stakeholders. What you do next determines whether those stakeholders become an engaged community or passive holders.
+
+### Common Post-Launch Challenges
+
+- **Governance void:** No mechanism for community decision-making
+- **Passive holders:** Token holders with no way to participate
+- **Value leakage:** Protocol revenue not flowing to stakeholders
+- **Security concerns:** Centralized control over critical operations
+
+### The Tally Solution
+
+Tally addresses each challenge:
+
+- **Governance:** Voting, proposals, and delegation
+- **Engagement:** Staking, incentives, and participation rewards
+- **Value accrual:** Protocol revenue distribution to stakers
+- **Security:** Council elections and distributed oversight
+
+## Available Tooling
+
+### Governance
+
+Empower your community with decentralized decision-making:
+
+- **Proposal creation:** Community members propose changes
+- **Voting:** Token holders vote on proposals
+- **Execution:** Approved proposals execute automatically
+- **Treasury management:** Secure fund allocation through governance
+
+[Learn more about Governance](governance-overview.md)
+
+### Voting and Delegation
+
+Enable flexible participation:
+
+- **Direct voting:** Token holders vote themselves
+- **Delegation:** Delegate voting power to representatives
+- **Partial delegation:** Split voting power across delegates
+- **Gasless participation:** Remove gas barriers to voting
+
+[Learn more about Voting & Delegation](voting-delegation.md)
+
+### Staking and Incentives
+
+Reward aligned behavior:
+
+- **Staking for value accrual:** Distribute protocol revenue to stakers
+- **Governance rewards:** Incentivize governance participation
+- **Liquidity incentives:** Reward LP providers
+- **Custom programs:** Design rewards for your specific needs
+
+[Learn more about Staking & Incentives](staking-incentives.md)
+
+### Security Councils
+
+Establish community oversight:
+
+- **Council elections:** Democratic selection of council members
+- **Emergency powers:** Rapid response to security issues
+- **Distributed control:** Decentralize critical operations
+- **Term limits:** Regular rotation and accountability
+
+[Learn more about Security Councils](security-councils.md)
+
+## Integration with Token Sales
+
+Post-launch tools integrate seamlessly with your sale:
+
+### Locked Token Participation
+
+Participants with locked tokens can still:
+
+- Vote in governance
+- Delegate voting power
+- Earn staking rewards (where configured)
+- Participate in council elections
+
+### Progressive Decentralization
+
+Build toward full decentralization:
+
+1. **Launch:** Core team maintains significant control
+2. **Transition:** Introduce governance and councils
+3. **Maturity:** Community takes full ownership
+
+### Unified Experience
+
+One platform, many capabilities:
+
+- Consistent user interface
+- Shared wallet connections
+- Integrated identity/KYC
+- Unified analytics
+
+## Feature Comparison
+
+| Feature | Description | Key Benefit |
+|---------|-------------|-------------|
+| Governance | Proposals and voting | Community decision-making |
+| Delegation | Voting power transfer | Representative democracy |
+| Staking | Token lockup for rewards | Value accrual and alignment |
+| Incentives | Reward distribution | Behavioral incentivization |
+| Security Councils | Elected oversight | Distributed security |
+
+## Getting Started
+
+### If You're Planning a Sale
+
+Include post-launch in your planning:
+
+- Consider governance structure from the start
+- Design tokenomics with staking in mind
+- Plan your decentralization roadmap
+
+### If You've Completed a Sale
+
+Add capabilities incrementally:
+
+1. Start with basic governance
+2. Add delegation for broader participation
+3. Introduce staking and incentives
+4. Establish security councils for critical operations
+
+### If You Have Existing Infrastructure
+
+Tally works with existing setups:
+
+- Compatible with OpenZeppelin Governor
+- Compatible with Compound Governor
+- Migration paths available
+- No vendor lock-in
+
+## Platform Capabilities
+
+### Multichain Support
+
+Deploy across networks:
+
+- Ethereum mainnet
+- Arbitrum
+- Base
+- ZKsync
+- And more
+
+### Cross-Chain Governance
+
+With MultiGov:
+
+- Govern from any supported chain
+- Unified voting across chains
+- Solana support available
+
+### Integrations
+
+Connect with your stack:
+
+- Safe (Gnosis) multisig
+- Forum bots for proposal notifications
+- Analytics integrations
+- Custom integrations available
+
+## Next Steps
+
+- [Governance Overview](governance-overview.md) - Start with governance
+- [Voting & Delegation](voting-delegation.md) - Enable participation
+- [Staking & Incentives](staking-incentives.md) - Add rewards
+- [Security Councils](security-councils.md) - Establish oversight
+- [Talk to our team](http://tally.xyz/contact) - Discuss your needs
diff --git a/post-launch-tooling/governance-overview.md b/post-launch-tooling/governance-overview.md
new file mode 100644
index 0000000..9bb368c
--- /dev/null
+++ b/post-launch-tooling/governance-overview.md
@@ -0,0 +1,224 @@
+---
+description: Decentralized decision-making for your protocol
+---
+
+# Governance Overview
+
+Deploy production-ready governance that scales with your protocol without requiring vendor migrations or custom integration work. As your governance matures, add advanced features like MultiGov, optimistic governance, or security council elections to meet the evolving needs of your community.
+
+## What is On-Chain Governance?
+
+On-chain governance enables decentralized decision-making through transparent voting:
+
+- **Proposals:** Community members suggest changes
+- **Voting:** Token holders express preferences
+- **Execution:** Approved proposals execute automatically
+- **Treasury:** Funds distributed through governance
+
+### Why Governance Matters
+
+After a token sale, governance:
+
+- Gives stakeholders a voice in protocol direction
+- Enables decentralized treasury management
+- Builds community trust and engagement
+- Supports regulatory positioning as utility
+
+## Key Features
+
+### Voting and Proposal Management
+
+Secure, transparent voting mechanisms:
+
+- **Proposal creation:** Structured proposal process
+- **Collaborative drafting:** Multi-author proposals
+- **No-code fund transfers:** Treasury distributions without coding
+- **Automatic execution:** Approved proposals execute on-chain
+
+### Delegation
+
+Enable representative democracy:
+
+- **Full delegation:** Transfer all voting power to a delegate
+- **Partial delegation:** Split power across multiple delegates
+- **Liquid delegation:** Change delegates at any time
+- **Delegation without transfer:** Keep tokens, delegate votes
+
+### Gasless Participation
+
+Remove barriers to voting:
+
+- **Free voting:** Organization pays gas costs
+- **Free delegation:** No cost to delegate
+- **Broader participation:** Smaller holders can participate
+
+### Multichain Support
+
+With MultiGov, govern from any chain:
+
+- **Cross-chain voting:** Vote from Ethereum, L2s, or Solana
+- **Unified governance:** Single governance system across chains
+- **Meet users where they are:** No bridge requirements for voting
+
+## Governance Models
+
+### Standard Governor
+
+OpenZeppelin Governor compatible:
+
+- Industry-standard implementation
+- Flexible parameter configuration
+- Wide ecosystem support
+- Audited and battle-tested
+
+### Optimistic Governance
+
+Faster execution with veto protection:
+
+- Proposals pass unless vetoed
+- Reduces governance overhead
+- Maintains community oversight
+- Suitable for routine decisions
+
+### Timelocked Governance
+
+Added security for critical decisions:
+
+- Delay between approval and execution
+- Time for community review
+- Emergency cancellation possible
+- Standard for high-stakes changes
+
+## Configuration Options
+
+### Voting Parameters
+
+| Parameter | Description | Typical Range |
+|-----------|-------------|---------------|
+| Voting Period | Duration of voting | 3-7 days |
+| Voting Delay | Time before voting starts | 1-2 days |
+| Proposal Threshold | Tokens needed to propose | 0.1-1% of supply |
+| Quorum | Minimum participation | 4-10% of supply |
+
+### Execution Parameters
+
+| Parameter | Description | Typical Range |
+|-----------|-------------|---------------|
+| Timelock Delay | Time before execution | 2-7 days |
+| Grace Period | Time to execute after approval | 7-14 days |
+
+## Getting Started with Governance
+
+### For New Projects
+
+1. **Define parameters:** Set voting periods, thresholds, quorum
+2. **Deploy contracts:** Tally deploys Governor and Timelock
+3. **Configure interface:** Branded governance portal
+4. **Launch:** Go live with governance
+
+### For Existing Projects
+
+1. **Compatibility check:** Verify contract compatibility
+2. **Add to Tally:** Register your DAO on Tally
+3. **Configure features:** Enable advanced features
+4. **Migrate users:** Direct community to Tally interface
+
+## Integration with Token Sales
+
+### Post-Sale Governance
+
+After your token sale:
+
+- Governance can be active from day one
+- Locked tokens can participate in voting
+- Delegation available for all holders
+- Treasury immediately under governance control
+
+### Progressive Decentralization
+
+Start controlled, become decentralized:
+
+1. **Phase 1:** Team retains significant voting power
+2. **Phase 2:** Community gains majority
+3. **Phase 3:** Full community control
+
+## Advanced Features
+
+### Security Council Integration
+
+Combine with security councils:
+
+- Councils handle emergencies
+- Governance handles routine decisions
+- Clear separation of concerns
+- Maximum decentralization with safety
+
+See [Security Councils](security-councils.md)
+
+### Staking Integration
+
+Governance participation can be rewarded:
+
+- Voting rewards for active participants
+- Delegation rewards for representatives
+- Staking with governance rights preserved
+
+See [Staking & Incentives](staking-incentives.md)
+
+## Supported Contract Standards
+
+### OpenZeppelin Governor
+
+Full support for OZ Governor:
+
+- All standard extensions
+- Custom extensions possible
+- Upgrade paths available
+
+### Compound Governor Bravo
+
+Support for legacy contracts:
+
+- Bravo compatibility
+- Migration to OZ available
+
+## Best Practices
+
+### Parameter Selection
+
+Choose parameters carefully:
+
+- **Voting period:** Long enough for participation, short enough for agility
+- **Quorum:** High enough for legitimacy, low enough to pass
+- **Thresholds:** Low enough for access, high enough to prevent spam
+
+### Proposal Guidelines
+
+Establish clear guidelines:
+
+- Proposal format standards
+- Discussion requirements before voting
+- Voting rationale expectations
+
+### Delegation Culture
+
+Encourage healthy delegation:
+
+- Delegate discovery and profiles
+- Delegate accountability metrics
+- Regular delegate elections or reviews
+
+## Resources
+
+For detailed technical documentation:
+
+- [Deploying DAOs](/set-up-and-technical-documentation/deploying-daos/)
+- [Governor Proposals](/set-up-and-technical-documentation/governor-proposals/)
+- [DAO Settings](/set-up-and-technical-documentation/managing-a-dao/dao-settings.md)
+
+## Next Steps
+
+- [Voting & Delegation](voting-delegation.md) - Participation mechanisms
+- [Security Councils](security-councils.md) - Oversight and security
+- [Staking & Incentives](staking-incentives.md) - Reward programs
+- [Talk to our team](http://tally.xyz/contact) - Launch governance
diff --git a/post-launch-tooling/security-councils.md b/post-launch-tooling/security-councils.md
new file mode 100644
index 0000000..c7ea6af
--- /dev/null
+++ b/post-launch-tooling/security-councils.md
@@ -0,0 +1,220 @@
+---
+description: Democratic oversight for protocol security
+---
+
+# Security Councils
+
+Security council elections are a pivotal aspect of decentralized governance, ensuring that the guardianship of a protocol remains in the hands of its community. With Tally's custom-built council elections, elevate your organization's oversight to the highest standards of excellence and integrity.
+
+## What is a Security Council?
+
+A security council is a group of elected members with authority to take rapid action in emergencies. Unlike slow governance processes, councils can respond quickly to threats while maintaining community legitimacy through elections.
+
+### Roles and Responsibilities
+
+Council members typically handle:
+
+- **Emergency actions:** Rapid response to critical situations threatening user funds
+- **Routine operations:** Software updates, maintenance, parameter adjustments
+- **Protocol oversight:** Monitoring for risks and vulnerabilities
+- **Upgrade execution:** Implementing governance-approved changes
+
+### Why Councils Matter
+
+Councils solve the speed vs. decentralization tradeoff:
+
+- **Security:** Rapid response to threats
+- **Legitimacy:** Community-elected members
+- **Accountability:** Regular elections enforce accountability
+- **Resilience:** Distributed control prevents single points of failure
+
+## Election Process
+
+Tally runs democratic elections to select council members:
+
+### Election Phases
+
+1. **Nomination:** Candidates register and meet minimum requirements
+2. **Compliance:** Foundation or team vets nominees
+3. **Voting:** Delegates vote for preferred candidates
+4. **Results:** Top candidates become council members
+5. **Implementation:** New members onboarded to council
+
+### Typical Timeline
+
+| Phase | Duration | Activities |
+|-------|----------|------------|
+| Nomination | 1-2 weeks | Candidate registration, endorsement gathering |
+| Compliance | 1 week | Background verification, eligibility confirmation |
+| Voting | 2 weeks | Community voting, often with declining weight |
+| Transition | 1 week | Outgoing/incoming member handoff |
+
+### Voting Mechanics
+
+Elections can use various voting methods:
+
+- **Weighted voting:** Based on token holdings or delegation
+- **Declining weight:** Voting power decreases over time (encourages early voting)
+- **Quadratic voting:** Reduces whale influence
+- **Ranked choice:** Multiple preferences per voter
+
+## Council Structure
+
+### Composition
+
+Typical council structures:
+
+| Element | Example | Rationale |
+|---------|---------|-----------|
+| Total Members | 12 | Enough for diversity, small enough for coordination |
+| Cohorts | 2 (6 each) | Staggered elections for continuity |
+| Term Length | 12 months | Regular accountability |
+| Election Frequency | Every 6 months | Half council elected each cycle |
+
+### Quorum Requirements
+
+Different actions require different approval levels:
+
+| Action Type | Typical Quorum | Example |
+|-------------|----------------|---------|
+| Emergency | 9/12 (75%) | Pause contracts |
+| Non-Emergency | 7/12 (~58%) | Parameter changes |
+| Routine | 5/12 (~42%) | Minor updates |
+
+## Security Measures
+
+### Constrained Access
+
+Councils operate with limited, defined powers:
+
+- Access only to specific functions
+- No unilateral control over treasury
+- Actions logged and auditable
+- Emergency powers time-limited
+
+### Timelocks and Delays
+
+Non-emergency actions include delays:
+
+- Gives community time to review
+- Enables veto through governance if needed
+- Balances speed with oversight
+
+### Transparency
+
+All council actions are visible:
+
+- On-chain execution
+- Public meeting notes
+- Decision documentation
+- Regular community updates
+
+## Integration with Governance
+
+### Separation of Concerns
+
+Councils and governance have distinct roles:
+
+| Domain | Governance | Council |
+|--------|------------|---------|
+| Routine decisions | Yes | No |
+| Treasury allocation | Yes | No |
+| Emergency response | No | Yes |
+| Technical upgrades | Approval | Execution |
+| Parameter changes | Major | Minor |
+
+### Governance Oversight
+
+Councils remain accountable to governance:
+
+- Elections through governance process
+- Council actions can be reviewed
+- Governance can modify council powers
+- Community retains ultimate authority
+
+## Use Cases
+
+### Protocol Security
+
+Respond to vulnerabilities:
+
+- Pause affected contracts
+- Deploy fixes rapidly
+- Coordinate disclosure
+- Manage communication
+
+### Network Operations
+
+Maintain protocol health:
+
+- Update contract parameters
+- Deploy approved upgrades
+- Monitor network status
+- Coordinate with operators
+
+### Compliance Response
+
+Handle regulatory issues:
+
+- Implement required changes
+- Coordinate with legal counsel
+- Document decisions
+- Maintain compliance
+
+## Implementation
+
+### Setup Process
+
+1. **Design structure:** Members, terms, quorums
+2. **Define powers:** What can the council do?
+3. **Deploy contracts:** Multisig with appropriate controls
+4. **Run election:** Select initial members
+5. **Go live:** Council begins operations
+
+### Technical Requirements
+
+- **Multisig wallet:** Safe or similar for execution
+- **Governance integration:** For elections and oversight
+- **Communication channels:** For coordination
+- **Documentation system:** For transparency
+
+## Best Practices
+
+### Candidate Selection
+
+Look for council members with:
+
+- Technical expertise
+- Protocol familiarity
+- Security background
+- Availability and commitment
+- Community trust
+
+### Operational Excellence
+
+Run effective councils:
+
+- Regular meetings and communication
+- Clear escalation procedures
+- Documented decision processes
+- Transparent reporting
+
+### Accountability
+
+Maintain community trust:
+
+- Public meeting notes
+- Decision rationale documentation
+- Regular community updates
+- Responsiveness to community concerns
+
+## Case Study: Arbitrum DAO
+
+<>
+
+## Next Steps
+
+- [Governance Overview](governance-overview.md) - Governance integration
+- [Voting & Delegation](voting-delegation.md) - Election mechanics
+- [Staking & Incentives](staking-incentives.md) - Council compensation
+- [Talk to our team](http://tally.xyz/contact) - Implement councils
diff --git a/post-launch-tooling/staking-incentives.md b/post-launch-tooling/staking-incentives.md
new file mode 100644
index 0000000..f5d7f4f
--- /dev/null
+++ b/post-launch-tooling/staking-incentives.md
@@ -0,0 +1,249 @@
+---
+description: Reward aligned behavior and accrue token value
+---
+
+# Staking and Incentives
+
+Well-designed incentives and staking programs attract aligned token holders who add value to your protocol. Tally provides a complete, modular staking solution - open-source smart contracts and a ready-to-use interface that makes participation effortless.
+
+## Why Staking Matters
+
+After a token sale, staking:
+
+- **Returns value:** Distribute protocol revenue to token holders
+- **Encourages commitment:** Reward long-term holding
+- **Drives participation:** Incentivize governance engagement
+- **Provides utility:** Give tokens functional value
+
+## Staking for Value Accrual
+
+Distribute protocol value to committed stakeholders:
+
+### How It Works
+
+1. **Stake tokens:** Holders lock tokens in staking contract
+2. **Earn rewards:** Protocol distributes rewards to stakers
+3. **Claim or compound:** Withdraw rewards or add to stake
+4. **Unstake:** Remove tokens (subject to any cooldown)
+
+### Reward Sources
+
+Staking rewards can come from:
+
+- **Protocol revenue:** Fees generated by the protocol
+- **Treasury allocation:** Distributions from treasury
+- **Token emissions:** New token issuance
+- **External rewards:** Partner incentives
+
+### Distribution Mechanics
+
+| Method | Description | Use Case |
+|--------|-------------|----------|
+| Pro-rata | Proportional to stake | Fair distribution |
+| Time-weighted | Longer staking = more rewards | Encourage commitment |
+| Activity-based | Rewards for specific actions | Behavioral incentives |
+
+## Governance Integration
+
+Staking integrates with governance:
+
+### Voting Power Preservation
+
+Staked tokens retain governance rights:
+
+- Vote while staking
+- Delegate staked voting power
+- No governance penalty for staking
+
+### Participation Rewards
+
+Reward governance participation:
+
+- Additional rewards for active voters
+- Delegate compensation for representatives
+- Governance engagement multipliers
+
+## Delegate Compensation
+
+Reward engaged governance participants:
+
+### How It Works
+
+1. **Define criteria:** Set participation requirements
+2. **Track activity:** Monitor delegate behavior
+3. **Calculate rewards:** Based on participation metrics
+4. **Distribute:** Automatic or claimable rewards
+
+### Eligibility Criteria
+
+| Criterion | Description | Example |
+|----------|-------------|---------|
+| Minimum stake | Tokens staked | 1,000 tokens |
+| Participation rate | Voting frequency | 80%+ of proposals |
+| Reputation score | Quality metrics | DRS > 75 |
+
+## Liquid Staking
+
+Stake while maintaining liquidity:
+
+### LST (Liquid Staking Tokens)
+
+Receive transferable token representing stake:
+
+- Trade or use in DeFi
+- Maintain staking rewards
+- No lockup requirement
+- Composable with other protocols
+
+### stGOV LST
+
+Tally's liquid staking implementation:
+
+- Automatic delegation
+- DeFi composability
+- Governance integration
+- Audited contracts
+
+## Configuration Options
+
+### Staking Parameters
+
+| Parameter | Description | Typical Range |
+|-----------|-------------|---------------|
+| Minimum Stake | Smallest allowed stake | 1-100 tokens |
+| Cooldown Period | Time to unstake | 0-30 days |
+| Reward Rate | Distribution rate | Variable |
+| Compound Option | Auto-compound rewards | On/Off |
+
+### Reward Parameters
+
+| Parameter | Description | Options |
+|-----------|-------------|---------|
+| Reward Token | Token distributed | Native/Other ERC20 |
+| Distribution Frequency | How often rewards distribute | Block/Daily/Weekly |
+| Vesting | Reward lockup | Immediate/Vested |
+
+## Integration with Token Sales
+
+### Post-Sale Staking
+
+Enable staking immediately after sale:
+
+- Participants can stake purchased tokens
+- Even locked tokens can earn rewards (where configured)
+- Build staking culture from day one
+
+### Incentivizing Lockups
+
+Reward longer commitments:
+
+- Higher rewards for longer stakes
+- Bonus multipliers for early stakers
+- Graduated reward tiers
+
+## Use Cases
+
+### Protocol Revenue Distribution
+
+Share success with stakeholders:
+
+```
+Protocol Revenue → Treasury → Staking Contract → Stakers
+```
+
+### Governance Incentivization
+
+Reward active governance:
+
+```
+Treasury Allocation → Participation Metrics → Active Voters
+```
+
+### Liquidity Mining
+
+Incentivize LP provision:
+
+```
+Token Emissions → LP Staking Contract → Liquidity Providers
+```
+
+### Network Security
+
+Reward validators or operators:
+
+```
+Protocol Fees → Operator Rewards → Network Validators
+```
+
+## Best Practices
+
+### Program Design
+
+Design sustainable programs:
+
+- **Sustainable rewards:** Don't over-promise emissions
+- **Clear mechanics:** Easy to understand
+- **Fair distribution:** Avoid whale concentration
+- **Aligned incentives:** Reward beneficial behavior
+
+### Communication
+
+Set clear expectations:
+
+- Document staking mechanics
+- Publish reward schedules
+- Explain risks clearly
+- Provide regular updates
+
+### Monitoring
+
+Track program health:
+
+- Participation rates
+- Distribution metrics
+- Stakeholder composition
+- Reward sustainability
+
+## Technical Implementation
+
+### Smart Contracts
+
+Tally provides audited staking contracts:
+
+- Open-source and verifiable
+- Modular design
+- Flexible configuration
+- Battle-tested security
+
+### Interface
+
+Ready-to-use staking interface:
+
+- Stake and unstake flows
+- Reward claiming
+- Position tracking
+- Historical analytics
+
+### Customization
+
+Adapt to your needs:
+
+- Custom eligibility criteria
+- Multiple reward tokens
+- Governance integration
+- DeFi composability
+
+## Resources
+
+For detailed technical documentation:
+
+- [Staking Contracts](/set-up-and-technical-documentation/staking-contracts/)
+- [How Staking Works](/set-up-and-technical-documentation/staking-contracts/how-staking-works.md)
+- [DeFi Integration Guide](/set-up-and-technical-documentation/staking-contracts/defi-integration-guide.md)
+
+## Next Steps
+
+- [Governance Overview](governance-overview.md) - Governance integration
+- [Voting & Delegation](voting-delegation.md) - Participation mechanisms
+- [Security Councils](security-councils.md) - Oversight structures
+- [Talk to our team](http://tally.xyz/contact) - Launch staking
diff --git a/post-launch-tooling/voting-delegation.md b/post-launch-tooling/voting-delegation.md
new file mode 100644
index 0000000..84cee77
--- /dev/null
+++ b/post-launch-tooling/voting-delegation.md
@@ -0,0 +1,254 @@
+---
+description: Enable flexible governance participation
+---
+
+# Voting and Delegation
+
+Effective governance requires broad participation. Voting and delegation mechanisms enable token holders to participate directly or through trusted representatives, ensuring all voices can be heard regardless of holdings size or technical expertise.
+
+## Why Delegation Matters
+
+Not every token holder can:
+
+- Stay informed on every proposal
+- Understand technical implications
+- Be available during voting periods
+- Pay gas costs for every vote
+
+Delegation solves these problems by allowing holders to transfer voting power to engaged representatives while retaining token ownership.
+
+## Voting Mechanisms
+
+### Direct Voting
+
+Token holders vote themselves:
+
+- **Full control:** Voter makes every decision
+- **Simple:** Connect wallet, cast vote
+- **Transparent:** Votes recorded on-chain
+
+### Delegated Voting
+
+Transfer voting power to representatives:
+
+- **Representative democracy:** Delegates vote on behalf of delegators
+- **Flexibility:** Change delegates anytime
+- **No transfer:** Tokens stay in your wallet
+
+### Partial Delegation
+
+Split voting power across multiple delegates:
+
+- **Diversification:** Multiple representatives
+- **Nuanced:** Different delegates for different expertise
+- **Control:** Retain portion for direct voting
+
+## Delegation Features
+
+### Delegate Discovery
+
+Find the right representatives:
+
+- **Delegate profiles:** Background, expertise, positions
+- **Voting history:** How delegates have voted
+- **Delegation stats:** How much voting power they hold
+- **Communication:** Links to delegate communications
+
+### Delegate Statements
+
+Delegates can share:
+
+- Governance philosophy
+- Areas of expertise
+- Availability and commitment
+- Contact information
+
+### Delegation Tracking
+
+Monitor your delegation:
+
+- Current delegates and amounts
+- Delegate voting activity
+- Proposals your delegates voted on
+- Alerts for important votes
+
+## Gasless Participation
+
+Remove financial barriers with Relay:
+
+### Free Voting
+
+Organizations can sponsor voting:
+
+- Token holders vote without gas costs
+- Organization pays transaction fees
+- Enables participation from small holders
+- Increases governance participation
+
+### Free Delegation
+
+Delegation without cost:
+
+- Change delegates freely
+- No barrier to participation
+- Encourage active delegation management
+
+### How It Works
+
+1. Voter signs a message (no gas)
+2. Tally submits transaction
+3. Organization's wallet pays gas
+4. Vote or delegation recorded on-chain
+
+## Configuration Options
+
+### Voting Settings
+
+| Setting | Description | Options |
+|---------|-------------|---------|
+| Voting Type | How votes are cast | Simple, Weighted, Ranked |
+| Vote Options | Available choices | For/Against, For/Against/Abstain |
+| Voting Period | Duration for voting | Configurable |
+
+### Delegation Settings
+
+| Setting | Description | Options |
+|---------|-------------|---------|
+| Partial Delegation | Allow split delegation | On/Off |
+| Delegation Cap | Max delegation to one address | Optional |
+| Delegation History | Track delegation changes | On/Off |
+
+## Integration with Token Sales
+
+### Locked Token Voting
+
+Participants with locked tokens can still govern:
+
+- Voting power active during lockup
+- Delegation available
+- Full governance participation
+- No governance disadvantage
+
+### Early Governance Participation
+
+Even before tokens unlock:
+
+- Vote on proposals
+- Delegate to representatives
+- Shape protocol direction
+- Build governance culture
+
+## Best Practices
+
+### For Token Holders
+
+**If you want to vote directly:**
+- Stay informed on proposals
+- Review proposal details carefully
+- Consider long-term implications
+- Vote consistently
+
+**If you prefer delegation:**
+- Research delegates thoroughly
+- Choose delegates aligned with your values
+- Monitor delegate behavior
+- Change delegates if needed
+
+### For Delegates
+
+**Build trust:**
+- Publish a clear delegate statement
+- Vote consistently with stated positions
+- Explain voting rationale
+- Communicate actively with delegators
+
+**Participate actively:**
+- Review all proposals
+- Vote on every relevant proposal
+- Engage in governance discussions
+- Represent delegators faithfully
+
+### For Organizations
+
+**Encourage participation:**
+- Educate on governance process
+- Highlight delegate opportunities
+- Enable gasless participation
+- Recognize active participants
+
+**Support delegates:**
+- Provide tools for delegate discovery
+- Consider delegate compensation
+- Create delegate accountability mechanisms
+
+## Advanced Features
+
+### Delegate Compensation
+
+Reward engaged delegates:
+
+- Automatic compensation for active participation
+- Tied to governance participation metrics
+- Configurable compensation criteria
+
+See [Staking & Incentives](staking-incentives.md) for delegate compensation details.
+
+### Delegate Reputation Score (DRS)
+
+Track delegate performance:
+
+- Participation rate
+- Voting consistency
+- Communication quality
+- Community engagement
+
+### Flexible Voting Extension
+
+Advanced voting patterns:
+
+- Vote with tokens in DeFi positions
+- Aggregate voting across protocols
+- Preserve voting rights in complex setups
+
+## Technical Implementation
+
+### Supported Standards
+
+Tally supports standard delegation:
+
+- ERC20Votes (OpenZeppelin)
+- Compound-style delegation
+- Custom delegation implementations
+
+### Integration Requirements
+
+To enable delegation:
+
+- Token must implement delegation
+- Governor must support delegated voting
+- Both standard in modern deployments
+
+## Common Questions
+
+### Does delegation transfer my tokens?
+
+No. Delegation only transfers voting power. Your tokens remain in your wallet under your full control.
+
+### Can I vote and delegate?
+
+With partial delegation, yes. Keep some voting power for yourself and delegate the rest.
+
+### How do I change my delegate?
+
+Simply delegate to a new address. The previous delegation is automatically replaced.
+
+### What happens if my delegate doesn't vote?
+
+Your voting power goes unused for that proposal. Consider delegating to more active representatives.
+
+## Next Steps
+
+- [Governance Overview](governance-overview.md) - Full governance guide
+- [Staking & Incentives](staking-incentives.md) - Participation rewards
+- [Security Councils](security-councils.md) - Advanced oversight
+- [Talk to our team](http://tally.xyz/contact) - Enable delegation
diff --git a/sale-types/README.md b/sale-types/README.md
new file mode 100644
index 0000000..1e26af5
--- /dev/null
+++ b/sale-types/README.md
@@ -0,0 +1,81 @@
+---
+description: Deep dive into each sale mechanism Tally supports
+---
+
+# Sale Types Overview
+
+Tally supports multiple token sale mechanisms, each designed to meet different project needs. This section provides detailed documentation on each sale type, helping you understand the mechanics, advantages, and implementation details.
+
+## Available Sale Types
+
+### Liquidity Bootstrapping Pools (LBPs)
+
+LBPs enable price discovery through a declining price curve. The price starts high and decreases over time, discouraging early speculation and allowing broader participation at fair prices.
+
+**Key characteristics:**
+- Automated price decline over time
+- Anti-whale mechanics built-in
+- Proven mechanism used by major projects
+- Simple participant experience
+
+[Learn more about LBPs](liquidity-bootstrapping-pools.md)
+
+### Continuous Clearing Auctions (CCAs)
+
+CCAs enable market-driven price discovery through a fully on-chain auction. Bidders place orders that are split across auction blocks, with each block clearing at the identified market price.
+
+**Key characteristics:**
+- Fully transparent on-chain mechanics
+- MEV-resistant batch clearing
+- Institutional-grade auction design
+- True market-driven pricing
+
+[Learn more about CCAs](continuous-clearing-auctions.md)
+
+### Fixed-Price Sales
+
+Set a predetermined price with optional allocation limits per wallet. Eligibility scoring and structured allocation reward long-term contributors.
+
+**Key characteristics:**
+- Predictable pricing and outcomes
+- Fine-grained allocation control
+- Community reward mechanisms
+- Simple to understand and participate
+
+[Learn more about Fixed-Price Sales](fixed-price-sales.md)
+
+## Choosing the Right Mechanism
+
+| Factor | LBP | CCA | Fixed Price |
+|--------|-----|-----|-------------|
+| **Price Discovery** | Market-driven via curve | Market-driven via auction | Project-determined |
+| **Distribution Control** | Lower | Medium | Higher |
+| **Complexity** | Medium | Medium | Low |
+| **Best For** | Broad distribution | Institutional sales | Community allocations |
+| **MEV Risk** | Medium | Low | Medium |
+
+## Common Configuration Options
+
+All sale types support:
+
+- **KYC Integration:** Identity verification for participants
+- **Geographic Restrictions:** Block or allow specific regions
+- **Allocation Limits:** Maximum purchase per wallet
+- **Vesting Schedules:** Post-sale lockup periods
+- **Multiple Payment Currencies:** USDC, USDT, ETH
+
+## Technical Implementation
+
+Tally handles all smart contract deployment and infrastructure:
+
+- Audited, battle-tested contracts
+- White-labeled frontend experience
+- Real-time monitoring dashboards
+- Launch-day support
+
+## Next Steps
+
+- [Liquidity Bootstrapping Pools](liquidity-bootstrapping-pools.md) - Detailed LBP documentation
+- [Continuous Clearing Auctions](continuous-clearing-auctions.md) - Detailed CCA documentation
+- [Fixed-Price Sales](fixed-price-sales.md) - Detailed fixed-price documentation
+- [Choosing Your Sale Type](../token-sales/choosing-your-sale-type.md) - Decision framework
diff --git a/sale-types/continuous-clearing-auctions.md b/sale-types/continuous-clearing-auctions.md
new file mode 100644
index 0000000..b10cc88
--- /dev/null
+++ b/sale-types/continuous-clearing-auctions.md
@@ -0,0 +1,203 @@
+---
+description: Market-driven price discovery through on-chain auctions
+---
+
+# Continuous Clearing Auctions (CCAs)
+
+Continuous Clearing Auctions enable market-driven price discovery through a fully on-chain auction mechanism. Bidders place orders that are split across auction blocks, with each block clearing at the identified market price. Transparent mechanics give buyers and investors confidence in the sale.
+
+## How CCAs Work
+
+### The Basic Mechanism
+
+1. **Bidding Period:** Participants submit bids specifying quantity and maximum price
+2. **Order Batching:** Bids are collected into auction blocks
+3. **Price Discovery:** Each block's clearing price is calculated based on supply and demand
+4. **Uniform Clearing:** All winning bids in a block pay the same clearing price
+5. **Continuous Operation:** Multiple blocks can run sequentially for extended sales
+
+### Clearing Price Calculation
+
+The clearing price for each block is determined by finding the price where:
+
+```
+Supply (tokens available) = Demand (sum of bids at or above clearing price)
+```
+
+All participants who bid at or above the clearing price receive tokens at that price, regardless of their maximum bid.
+
+### Example Clearing
+
+```
+Block Supply: 1,000 tokens
+
+Bids:
+- Alice: 500 tokens @ max $2.00
+- Bob: 300 tokens @ max $1.80
+- Carol: 400 tokens @ max $1.50
+- Dave: 200 tokens @ max $1.20
+
+Clearing: At $1.50, demand = 1,200 (Alice + Bob + Carol)
+ Tokens allocated pro-rata to bids >= $1.50
+
+Result: All pay $1.50 per token
+```
+
+## Configuration Parameters
+
+### Auction Structure
+
+| Parameter | Description | Typical Range |
+|-----------|-------------|---------------|
+| Block Size | Tokens per auction block | Varies by sale size |
+| Block Duration | Time per auction block | 1-24 hours |
+| Number of Blocks | Total blocks in sale | 1-10+ |
+| Reserve Price | Minimum clearing price | Project discretion |
+
+### Bidding Parameters
+
+| Parameter | Description | Guidance |
+|-----------|-------------|----------|
+| Minimum Bid | Smallest allowed bid | Low barrier preferred |
+| Maximum Bid | Largest allowed bid | Anti-whale measure |
+| Bid Currencies | Accepted payment tokens | USDC, USDT, ETH |
+
+## Advantages of CCAs
+
+### Full Transparency
+
+Every aspect is visible on-chain:
+
+- All bids are recorded
+- Clearing calculations are verifiable
+- No hidden mechanics or special treatment
+- Auditable by anyone
+
+### MEV Resistance
+
+Batch clearing prevents common attack vectors:
+
+- No front-running individual transactions
+- Order of submission doesn't determine allocation
+- All participants pay the same clearing price
+- Reduces bot advantage over regular users
+
+### True Price Discovery
+
+Market participants collectively determine fair value:
+
+- No predetermined price to manipulate
+- Aggregated demand signals true willingness to pay
+- Institutional-grade auction mechanics
+- Results reflect actual market conditions
+
+### Investor Confidence
+
+Professional investors appreciate CCA mechanics:
+
+- Familiar auction format from traditional finance
+- Clear rules and predictable execution
+- Equal treatment for all participants
+- Transparent allocation methodology
+
+## Considerations
+
+### Participant Education
+
+CCAs require more explanation than simple purchases:
+
+- Bid vs. purchase distinction
+- Clearing price concept
+- Pro-rata allocation
+- Timing within blocks
+
+Plan to educate your community before the sale.
+
+### Allocation Uncertainty
+
+Participants don't know their exact allocation until clearing:
+
+- Bids may be partially filled
+- Final price unknown until block closes
+- Requires comfort with uncertainty
+
+### Technical Complexity
+
+Implementation is more complex than fixed-price sales:
+
+- Tally handles all technical aspects
+- More parameters to configure correctly
+- Requires careful testing
+
+## Technical Implementation
+
+### Smart Contracts
+
+Tally deploys battle-tested CCA contracts:
+
+- Bid submission and management
+- Clearing price calculation
+- Token allocation and distribution
+- Integration with compliance layer
+
+### Powered by Uniswap
+
+CCAs leverage Uniswap's auction infrastructure:
+
+- Audited, production-ready contracts
+- Proven at scale
+- Continuous improvement and maintenance
+
+### Frontend Experience
+
+Tally provides an intuitive interface:
+
+- Clear bid submission flow
+- Real-time block status
+- Allocation tracking
+- Claim interface post-clearing
+
+### Monitoring
+
+Access comprehensive dashboards:
+
+- Current bids and demand curves
+- Estimated clearing prices
+- Block progress
+- Participation metrics
+
+## Best Practices
+
+### Setting Reserve Prices
+
+Consider floor pricing carefully:
+
+- Too high may result in unfilled blocks
+- Too low provides little protection
+- Base on fundamental analysis
+
+### Block Timing
+
+Structure blocks for optimal participation:
+
+- Allow sufficient time for bids
+- Consider global time zones
+- Account for blockchain confirmation times
+
+### Communication
+
+Keep participants informed:
+
+- Explain mechanics clearly before sale
+- Provide real-time updates during blocks
+- Communicate results promptly
+
+## Demo
+
+{% embed url="https://youtu.be/ycZv_XrzcKo" %}
+
+## Learn More
+
+- [Uniswap CCA Documentation](https://cca.uniswap.org/)
+- [Choosing Your Sale Type](../token-sales/choosing-your-sale-type.md)
+- [Running Your Sale](../token-sales/running-your-sale.md)
diff --git a/sale-types/fixed-price-sales.md b/sale-types/fixed-price-sales.md
new file mode 100644
index 0000000..8642870
--- /dev/null
+++ b/sale-types/fixed-price-sales.md
@@ -0,0 +1,226 @@
+---
+description: Controlled allocation at predetermined prices
+---
+
+# Fixed-Price Sales
+
+Fixed-price sales offer a straightforward approach: set a predetermined price with optional allocation limits per wallet. Eligibility scoring and structured allocation reward long-term contributors, giving you control over who can participate and how much they can purchase.
+
+## How Fixed-Price Sales Work
+
+### The Basic Mechanism
+
+1. **Price Setting:** Project determines token price in advance
+2. **Eligibility Definition:** Configure who can participate and their allocations
+3. **Sale Window:** Open purchases during defined period
+4. **Direct Purchase:** Participants buy tokens at the fixed price
+5. **Distribution:** Tokens allocated based on purchase order or pro-rata
+
+### Allocation Methods
+
+**First-Come-First-Served:**
+- Participants purchase in order of transaction
+- Earlier transactions get priority
+- Sale ends when supply exhausted
+
+**Pro-Rata Allocation:**
+- All purchases collected during window
+- Tokens distributed proportionally if oversubscribed
+- Excess funds returned to participants
+
+**Tiered Allocation:**
+- Different limits for different participant tiers
+- Based on eligibility score or allowlist status
+- Rewards loyal community members
+
+## Configuration Parameters
+
+### Pricing
+
+| Parameter | Description | Guidance |
+|-----------|-------------|----------|
+| Token Price | Fixed price per token | Based on valuation |
+| Payment Currencies | Accepted tokens | USDC, USDT, ETH |
+| Price Lock | Freeze price for duration | Typically locked |
+
+### Allocation Controls
+
+| Parameter | Description | Typical Range |
+|-----------|-------------|---------------|
+| Per-Wallet Maximum | Maximum tokens per address | Varies by goals |
+| Per-Wallet Minimum | Minimum purchase size | Low barrier preferred |
+| Total Supply | Tokens available for sale | Project discretion |
+
+### Eligibility
+
+| Parameter | Description | Options |
+|-----------|-------------|---------|
+| Allowlist | Specific addresses permitted | CSV upload |
+| Eligibility Score | Point-based qualification | Custom criteria |
+| KYC Requirement | Identity verification | On/Off |
+
+## Advantages of Fixed-Price Sales
+
+### Predictable Outcomes
+
+Know your results before you start:
+
+- Exact price per token
+- Maximum possible raise
+- Clear allocation structure
+- No price uncertainty
+
+### Simple Participation
+
+Easiest mechanism for participants:
+
+- Clear price, no complexity
+- Know exactly what you're getting
+- Familiar purchase flow
+- No auction mechanics to learn
+
+### Controlled Distribution
+
+Fine-grained allocation management:
+
+- Reward loyal community members
+- Prevent whale concentration
+- Implement tiered access
+- Enforce strict limits
+
+### Community Building
+
+Design sales around your community:
+
+- Recognize early contributors
+- Gate access to committed participants
+- Build goodwill through fair allocation
+- Strengthen stakeholder alignment
+
+## Considerations
+
+### No Price Discovery
+
+The project determines price, not the market:
+
+- Risk of over or under-pricing
+- No market signal on fair value
+- Requires independent valuation
+
+### Bot Risk
+
+Fixed prices can attract automated buyers:
+
+- Implement anti-bot measures
+- Consider allowlists
+- Use KYC as a filter
+- Rate limit transactions
+
+### Oversubscription Management
+
+Popular sales may have excess demand:
+
+- Plan allocation methodology in advance
+- Communicate clearly to participants
+- Ensure fair distribution process
+
+## Eligibility Scoring
+
+### How Scoring Works
+
+Eligibility scores allow nuanced participant selection:
+
+1. **Define Criteria:** Choose factors that matter (token holding, protocol usage, etc.)
+2. **Assign Points:** Weight each criterion appropriately
+3. **Calculate Scores:** Aggregate points for each address
+4. **Set Thresholds:** Minimum score to participate, tiered allocations
+
+### Example Criteria
+
+| Criterion | Description | Example Points |
+|-----------|-------------|----------------|
+| Token Holding | Amount of project token held | 1 point per token |
+| Holding Duration | Time tokens held | 10 points per month |
+| Protocol Usage | Interactions with protocol | 5 points per transaction |
+| Community Participation | Governance votes, forum posts | 20 points per action |
+| NFT Ownership | Specific NFT collections | 50 points per NFT |
+
+### Tier Structure Example
+
+| Tier | Score Required | Allocation |
+|------|----------------|------------|
+| Diamond | 1000+ | $10,000 |
+| Gold | 500-999 | $5,000 |
+| Silver | 100-499 | $1,000 |
+| Bronze | 1-99 | $250 |
+
+## Technical Implementation
+
+### Smart Contracts
+
+Tally deploys straightforward sale contracts:
+
+- Purchase and allocation logic
+- Eligibility verification
+- Refund handling (if pro-rata)
+- Integration with compliance layer
+
+### Frontend Experience
+
+Clean, intuitive interface:
+
+- Eligibility checking
+- Purchase flow
+- Allocation display
+- Transaction confirmation
+
+### Monitoring
+
+Track sale progress:
+
+- Purchases over time
+- Participation by tier
+- Remaining allocation
+- Geographic distribution
+
+## Best Practices
+
+### Pricing Strategy
+
+<>
+
+### Allocation Design
+
+Balance multiple goals:
+
+- Broad distribution vs. meaningful allocations
+- Rewarding loyalty vs. welcoming newcomers
+- Simplicity vs. nuanced tiers
+
+### Communication
+
+Set clear expectations:
+
+- Announce eligibility criteria in advance
+- Explain allocation methodology
+- Provide timeline and key dates
+- Be transparent about limits
+
+### Anti-Bot Measures
+
+Protect your sale:
+
+- Implement KYC requirements
+- Use eligibility scoring
+- Set reasonable rate limits
+- Consider captcha or proof of humanity
+
+## Demo
+
+{% embed url="https://youtu.be/ApvGHcz4wbI" %}
+
+## Learn More
+
+- [Choosing Your Sale Type](../token-sales/choosing-your-sale-type.md)
+- [Running Your Sale](../token-sales/running-your-sale.md)
+- [KYC Verification](../compliance/kyc-verification.md)
diff --git a/sale-types/liquidity-bootstrapping-pools.md b/sale-types/liquidity-bootstrapping-pools.md
new file mode 100644
index 0000000..6ae0160
--- /dev/null
+++ b/sale-types/liquidity-bootstrapping-pools.md
@@ -0,0 +1,191 @@
+---
+description: Price discovery through declining price curves
+---
+
+# Liquidity Bootstrapping Pools (LBPs)
+
+Liquidity Bootstrapping Pools enable price discovery through a declining price curve. The price starts high and decreases over time, discouraging early speculation and allowing broader participation at fair prices.
+
+Tally builds custom interfaces that abstract away the complexity of interacting with Balancer directly, providing a seamless experience for your participants.
+
+## How LBPs Work
+
+### The Basic Mechanism
+
+1. **Initial Setup:** Tokens are deposited into a weighted pool with a starting weight ratio (e.g., 96% project token / 4% USDC)
+2. **Weight Shift:** Over the sale duration, weights gradually shift (e.g., ending at 50/50)
+3. **Price Decline:** As weights shift, the price naturally decreases
+4. **Participant Entry:** Buyers enter when the price reaches their target
+5. **Equilibrium:** Buy pressure slows the decline, finding market equilibrium
+
+### Price Dynamics
+
+The LBP price follows a predictable curve:
+
+```
+Starting Price: High (set above expected fair value)
+ |
+ | \
+ | \
+Price | \ <- Price decline from weight change
+ | \
+ | \_____ <- Buy pressure slows decline
+ | \____
+ | \
+ +-------------------------> Time
+ Sale Duration
+```
+
+When no one buys, price declines according to the weight curve. When participants buy, they push the price up, creating a dynamic equilibrium.
+
+## Configuration Parameters
+
+### Weight Configuration
+
+| Parameter | Description | Typical Range |
+|-----------|-------------|---------------|
+| Starting Weight | Initial token weight in pool | 90-98% |
+| Ending Weight | Final token weight in pool | 30-50% |
+| Curve Shape | Linear or custom decay | Linear default |
+
+### Timing Parameters
+
+| Parameter | Description | Typical Range |
+|-----------|-------------|---------------|
+| Sale Duration | Total length of the LBP | 24-72 hours |
+| Start Time | When the sale begins | Scheduled |
+| End Time | When the sale concludes | Scheduled |
+
+### Price Parameters
+
+| Parameter | Description | Guidance |
+|-----------|-------------|----------|
+| Starting Price | Initial token price | 2-5x expected fair value |
+| Reserve Price | Optional price floor | Project discretion |
+
+## Advantages of LBPs
+
+### Anti-Whale Mechanics
+
+The declining price structure discourages large early purchases:
+
+- Buying early means paying a premium
+- Waiting risks missing out if others buy
+- Natural game theory promotes patience
+- Results in broader distribution
+
+### Fair Price Discovery
+
+Market dynamics determine the fair price:
+
+- No predetermined price to get wrong
+- Participants vote with capital
+- Transparent mechanism for all
+- Price reflects genuine demand
+
+### Simple Participant Experience
+
+Despite complex mechanics, the UX is straightforward:
+
+- Connect wallet
+- See current price
+- Decide to buy or wait
+- Execute purchase
+
+### Proven Track Record
+
+LBPs have been used successfully by major projects:
+
+<>
+
+## Considerations
+
+### Starting Price Setting
+
+Setting the starting price too high or too low creates issues:
+
+- **Too high:** Few early participants, may not sell out
+- **Too low:** Immediate buying pressure, less price discovery
+
+Work with Tally to model appropriate starting prices based on your targets.
+
+### Duration Selection
+
+Sale duration affects outcomes:
+
+- **Too short:** Less time for price discovery, favors fast actors
+- **Too long:** Participant fatigue, prolonged uncertainty
+
+24-72 hours is typical for most LBPs.
+
+### Market Conditions
+
+External market volatility can affect your sale:
+
+- Crypto market movements impact participant sentiment
+- Payment currency fluctuations affect real values
+- Consider timing relative to broader market conditions
+
+## Technical Implementation
+
+### Smart Contracts
+
+Tally deploys audited contracts on Balancer:
+
+- Pool creation and configuration
+- Weight shift programming
+- Integration with compliance layer
+
+### Frontend Experience
+
+Tally provides a white-labeled interface:
+
+- Real-time price display
+- Purchase flow with wallet integration
+- KYC verification (if required)
+- Transaction status and confirmation
+
+### Monitoring
+
+During the sale, access real-time dashboards:
+
+- Current price and weight status
+- Participation metrics
+- Funds raised
+- Time remaining
+
+## Best Practices
+
+### Communication
+
+Educate your community before the sale:
+
+- Explain how LBPs work
+- Set expectations about price dynamics
+- Encourage patience over FOMO
+
+### Timing
+
+Consider launch timing carefully:
+
+- Avoid major competing events
+- Account for global time zones
+- Ensure team availability during sale
+
+### Post-Sale
+
+Plan for what happens when the LBP concludes:
+
+- Token distribution mechanism
+- Remaining liquidity handling
+- Community communication
+
+## Demo
+
+{% embed url="https://youtu.be/UGoy6At6H6M" %}
+
+## Learn More
+
+- [Balancer LBP Documentation](https://docs.balancer.fi/concepts/explore-available-balancer-pools/liquidity-bootstrapping-pool.html)
+- [Choosing Your Sale Type](../token-sales/choosing-your-sale-type.md)
+- [Running Your Sale](../token-sales/running-your-sale.md)
diff --git a/token-sales/README.md b/token-sales/README.md
new file mode 100644
index 0000000..81c9aec
--- /dev/null
+++ b/token-sales/README.md
@@ -0,0 +1,48 @@
+---
+description: The essential guide to launching your token with Tally
+---
+
+# The Basics
+
+Token sales are the future of fundraising. Some of the most successful projects in crypto launched with token sales, and new legislation in the [US](https://www.congress.gov/bill/119th-congress/house-bill/3633/text) and [EU](https://www.esma.europa.eu/esmas-activities/digital-finance-and-innovation/markets-crypto-assets-regulation-mica) is clearing the path for more projects to do the same.
+
+A token sale lets you raise capital and build community in a single event. Done right, token sales have real advantages over alternatives:
+
+- **Venture funding** concentrates ownership with institutions
+- **Low-float airdrops** push price discovery to secondary markets
+- **IPOs** can take years and require intermediaries
+
+A well-structured token sale avoids all three.
+
+## What is a Token Sale?
+
+A token sale is a fundraising mechanism where a project sells tokens directly to participants. Unlike traditional fundraising, token sales can:
+
+- Distribute ownership broadly from day one
+- Enable price discovery through market mechanisms
+- Build an engaged community of stakeholders
+- Provide immediate liquidity for participants
+
+## How Tally Makes It Easy
+
+Tally handles the infrastructure so you can focus on growth:
+
+1. **Configure your sale:** Choose your mechanism, set pricing parameters, and define eligibility rules
+2. **Build your sale page:** Get a branded, white-labeled experience on your domain
+3. **Integrate compliance:** KYC/KYB/KYI verification, geo-blocking, and region-specific lockups
+4. **Launch and monitor:** Go live with real-time dashboards showing participation and price discovery
+5. **Close and distribute:** Tokens are distributed and vesting schedules execute automatically
+
+## What's in This Guide
+
+This documentation covers everything you need to know about running a successful token sale:
+
+- [Why Token Sales?](why-token-sales.md) - Understanding the benefits of token-based fundraising
+- [Are You Ready?](are-you-ready.md) - Assess your project's readiness for a token sale
+- [Choosing Your Sale Type](choosing-your-sale-type.md) - Compare LBPs, CCAs, and fixed-price sales
+- [Running Your Sale](running-your-sale.md) - Step-by-step guide to execution
+- [After Your Sale](after-your-sale.md) - Post-sale operations and next steps
+
+## Get Started
+
+Ready to launch? [Talk to our team](http://tally.xyz/contact) to discuss your requirements.
diff --git a/token-sales/after-your-sale.md b/token-sales/after-your-sale.md
new file mode 100644
index 0000000..d3f23f4
--- /dev/null
+++ b/token-sales/after-your-sale.md
@@ -0,0 +1,179 @@
+---
+description: Post-sale operations, distribution, and next steps
+---
+
+# After Your Sale
+
+Your token sale has closed. This guide covers what happens next and how to set your project up for long-term success.
+
+## Immediate Post-Sale Actions
+
+### Proceeds Distribution
+
+The majority of funds raised transfer directly to your designated wallet or multisig:
+
+- **Primary treasury:** Main funds go to your project treasury
+- **Liquidity allocation:** If configured, a portion seeds DEX liquidity
+- **Fee settlement:** Tally fees are settled automatically
+
+### Token Distribution
+
+Tokens are distributed according to your configured rules:
+
+**Instant Distribution:**
+- Tokens sent directly to participant wallets
+- Available for trading immediately
+- Suitable for fully liquid launches
+
+**Locked Distribution:**
+- Tokens subject to vesting schedules
+- Unlock according to your parameters
+- On-chain enforcement via vesting contracts
+
+### Liquidity Seeding
+
+If you enabled DEX integration:
+
+- A portion of funds and unsold tokens seed liquidity on Balancer or Uniswap
+- Your project controls the LP position
+- Provides immediate trading venue for token holders
+
+## Vesting and Lockups
+
+### Managing Vesting Schedules
+
+Tally integrates with on-chain vesting providers to enforce lockups:
+
+- **Linear vesting:** Tokens unlock gradually over time
+- **Cliff vesting:** Tokens unlock after an initial lockup period
+- **Milestone vesting:** Tokens unlock based on defined triggers
+
+### Geographic Lockups
+
+Different regions may have different lockup requirements:
+
+- Configure region-specific vesting schedules
+- Ensure compliance with local regulations
+- Manage multiple lockup tiers simultaneously
+
+See [Vesting & Lockups](../compliance/vesting-lockups.md) for details.
+
+## Building on Your Sale
+
+Tally provides a complete platform for your token's lifecycle. After your sale, consider:
+
+### Governance
+
+Empower your token holders with voting rights:
+
+- Proposal creation and voting
+- Delegation systems
+- Treasury management
+
+See [Governance Overview](../post-launch-tooling/governance-overview.md)
+
+### Staking and Incentives
+
+Reward long-term holders and active participants:
+
+- Staking for value accrual
+- Governance participation rewards
+- Liquidity mining programs
+
+See [Staking & Incentives](../post-launch-tooling/staking-incentives.md)
+
+### Security Councils
+
+Establish oversight for critical protocol decisions:
+
+- Council elections
+- Emergency response capabilities
+- Decentralized security
+
+See [Security Councils](../post-launch-tooling/security-councils.md)
+
+## Analytics and Reporting
+
+### Sale Performance
+
+Access detailed analytics on your sale:
+
+- Final participation numbers
+- Geographic distribution
+- Price discovery outcomes (for dynamic sales)
+- Funds raised by currency
+
+### Holder Analytics
+
+Track your token holder base:
+
+- Distribution concentration
+- Holder behavior over time
+- Governance participation rates
+
+<>
+
+## Common Post-Sale Questions
+
+### When can participants trade their tokens?
+
+This depends on your lockup configuration:
+- **No lockup:** Immediately after distribution
+- **With lockup:** According to your vesting schedule
+
+### What happens to unsold tokens?
+
+Options include:
+- Return to project treasury
+- Seed DEX liquidity
+- Burn (reduce supply)
+- Reserve for future distribution
+
+This is configured before your sale.
+
+### How do participants claim locked tokens?
+
+Tally provides a claims interface:
+- Participants connect their wallet
+- View vesting schedule and unlocked amounts
+- Claim available tokens on-chain
+
+### What if there are distribution issues?
+
+Tally support handles:
+- Technical issues with claims
+- Wallet address corrections (where possible)
+- Compliance-related holds
+
+## Long-Term Success
+
+### Community Engagement
+
+Your sale participants are now stakeholders:
+
+- Keep them informed about development progress
+- Involve them in governance decisions
+- Build genuine community connection
+
+### Exchange Listings
+
+<>
+
+### Ongoing Compliance
+
+Maintain compliance over time:
+
+- Monitor regulatory developments
+- Update restrictions as needed
+- Document compliance efforts
+
+## Continue with Tally
+
+No need to switch providers. Tally supports your project through:
+
+- **Governance:** Proposal management and voting
+- **Staking:** Reward programs and value accrual
+- **Incentives:** Liquidity mining and participation rewards
+- **Security:** Council elections and oversight
+
+[Talk to our team](http://tally.xyz/contact) about post-sale features.
diff --git a/token-sales/are-you-ready.md b/token-sales/are-you-ready.md
new file mode 100644
index 0000000..9c8cfd4
--- /dev/null
+++ b/token-sales/are-you-ready.md
@@ -0,0 +1,105 @@
+---
+description: Assess your project's readiness for a successful token sale
+---
+
+# Are You Ready?
+
+A successful token sale requires careful preparation. This page helps you assess whether your project is ready to launch and what you need to have in place before proceeding.
+
+## Readiness Checklist
+
+### Product & Technology
+
+- [ ] **Working product or clear roadmap:** Do you have a functional product or a detailed development plan?
+- [ ] **Token utility defined:** Is there a clear use case for your token within your ecosystem?
+- [ ] **Smart contracts audited:** Have your token and any related contracts been security audited?
+- [ ] **Technical team in place:** Do you have the engineering resources to support the sale and post-sale operations?
+
+### Legal & Compliance
+
+- [ ] **Legal structure established:** Is your entity properly incorporated?
+- [ ] **Legal counsel engaged:** Do you have lawyers familiar with token sales in your target jurisdictions?
+- [ ] **Regulatory analysis complete:** Have you assessed the regulatory requirements for your sale?
+- [ ] **Terms of service drafted:** Are your legal documents prepared?
+
+### Tokenomics
+
+- [ ] **Token supply determined:** Have you finalized your total supply and initial distribution?
+- [ ] **Vesting schedules defined:** Are lockup periods established for team, investors, and sale participants?
+- [ ] **Pricing strategy set:** Do you have a clear approach to initial pricing?
+- [ ] **Treasury allocation planned:** How will raised funds be managed and deployed?
+
+### Operations
+
+- [ ] **Team bandwidth available:** Can your team dedicate resources to sale preparation and execution?
+- [ ] **Communication plan ready:** How will you announce and market the sale?
+- [ ] **Support infrastructure:** Are you prepared to handle participant questions and issues?
+- [ ] **Post-sale roadmap:** What happens after the sale concludes?
+
+## Common Pitfalls to Avoid
+
+### Rushing to Market
+
+<>
+
+Taking shortcuts on preparation often leads to:
+- Security vulnerabilities
+- Regulatory issues
+- Poor participant experience
+- Reputational damage
+
+### Unclear Token Utility
+
+Tokens without clear utility face:
+- Regulatory scrutiny as potential securities
+- Lack of organic demand
+- Price instability
+- Community skepticism
+
+### Inadequate Compliance
+
+Skipping compliance steps can result in:
+- Geographic restrictions limiting participation
+- Post-sale legal challenges
+- Exchange listing difficulties
+- Ongoing regulatory burden
+
+## Timeline Considerations
+
+A typical token sale preparation timeline:
+
+| Phase | Duration | Key Activities |
+|-------|----------|----------------|
+| Planning | 2-4 weeks | Define goals, choose sale type, engage Tally |
+| Legal Setup | 4-8 weeks | Entity structure, compliance framework, documentation |
+| Technical Prep | 4-6 weeks | Smart contract deployment, audits, testing |
+| Marketing | 2-4 weeks | Community building, announcements, education |
+| Launch | 1-2 weeks | Sale execution, monitoring, support |
+
+*Note: Timelines vary based on project complexity and regulatory requirements.*
+
+## Working with Tally
+
+Tally's team can help you assess readiness and fill gaps in your preparation:
+
+- **Technical review:** Evaluate your smart contracts and infrastructure
+- **Compliance guidance:** Connect you with legal resources for your jurisdiction
+- **Sale design:** Recommend the optimal mechanism for your goals
+- **Launch support:** Provide hands-on assistance during execution
+
+## Self-Assessment Questions
+
+Before reaching out, consider:
+
+1. Why are you doing a token sale versus other fundraising methods?
+2. What role does the token play in your ecosystem?
+3. Who is your target participant base?
+4. What regulatory jurisdictions are you targeting or avoiding?
+5. What's your timeline and what's driving it?
+
+## Next Steps
+
+If you've completed the checklist and feel confident in your readiness:
+
+- [Choosing Your Sale Type](choosing-your-sale-type.md) - Select the right mechanism
+- [Talk to our team](http://tally.xyz/contact) - Get personalized guidance
diff --git a/token-sales/choosing-your-sale-type.md b/token-sales/choosing-your-sale-type.md
new file mode 100644
index 0000000..f80c075
--- /dev/null
+++ b/token-sales/choosing-your-sale-type.md
@@ -0,0 +1,150 @@
+---
+description: Compare sale mechanisms to find the right fit for your project
+---
+
+# Choosing Your Sale Type
+
+Tally supports multiple sale mechanisms, each with distinct advantages. This guide helps you understand the options and select the best fit for your distribution strategy and compliance requirements.
+
+## Sale Type Overview
+
+| Feature | LBP | CCA | Fixed Price |
+|---------|-----|-----|-------------|
+| Price Discovery | Declining curve | Market-driven auction | Predetermined |
+| Best For | Broad distribution | Transparent price finding | Controlled allocation |
+| Complexity | Medium | Medium | Low |
+| Participant Experience | Simple bidding | Batch auctions | Direct purchase |
+
+## Liquidity Bootstrapping Pools (LBPs)
+
+LBPs enable price discovery through a declining price curve. The price starts high and decreases over time, discouraging early speculation and allowing broader participation at fair prices.
+
+### How LBPs Work
+
+1. **Starting price:** Set above expected market value
+2. **Price decline:** Automatically decreases based on configured curve
+3. **Participant timing:** Buyers choose when to enter based on their price targets
+4. **Natural equilibrium:** Price stabilizes when buy pressure matches the decline rate
+
+### Advantages
+
+- **Anti-whale:** Declining price discourages large early purchases
+- **Fair distribution:** Participants self-select based on price tolerance
+- **Simple UX:** Straightforward buy experience for participants
+- **Proven mechanism:** Widely used and understood in crypto
+
+### Considerations
+
+- Requires careful initial price and curve configuration
+- Final price depends on market dynamics
+- May leave tokens unsold if starting price is too high
+
+### Best For
+
+- Projects prioritizing broad distribution
+- Teams comfortable with market-driven outcomes
+- Sales targeting crypto-native participants
+
+Learn more: [Liquidity Bootstrapping Pools](../sale-types/liquidity-bootstrapping-pools.md)
+
+## Continuous Clearing Auctions (CCAs)
+
+CCAs enable market-driven price discovery through a fully on-chain auction. Bidders place orders that are split across auction blocks, with each block clearing at the identified market price.
+
+### How CCAs Work
+
+1. **Bidding period:** Participants submit sealed bids
+2. **Block clearing:** Orders are batched and cleared at uniform prices
+3. **Price discovery:** Market dynamics determine clearing prices
+4. **Continuous operation:** Multiple blocks can run sequentially
+
+### Advantages
+
+- **Transparent:** Fully on-chain mechanics visible to all
+- **MEV-resistant:** Batch clearing prevents front-running
+- **True price discovery:** Market determines fair value
+- **Investor confidence:** Institutional-grade auction mechanics
+
+### Considerations
+
+- More complex UX than simple purchases
+- Requires participant education
+- Final allocation may differ from bid amount
+
+### Best For
+
+- Projects seeking institutional credibility
+- Sales where price discovery is paramount
+- Teams prioritizing transparency
+
+Learn more: [Continuous Clearing Auctions](../sale-types/continuous-clearing-auctions.md)
+
+## Fixed-Price Sales
+
+Set a predetermined price with optional allocation limits per wallet. Eligibility scoring and structured allocation reward long-term contributors.
+
+### How Fixed-Price Sales Work
+
+1. **Price setting:** Project determines token price in advance
+2. **Allocation rules:** Define per-wallet limits and eligibility criteria
+3. **Purchase window:** Participants buy during the sale period
+4. **Distribution:** Tokens allocated based on purchase order or pro-rata
+
+### Advantages
+
+- **Predictable outcomes:** Known price and raise amount
+- **Simple to understand:** No complex mechanics to explain
+- **Controlled distribution:** Precise allocation management
+- **Eligibility flexibility:** Reward loyal community members
+
+### Considerations
+
+- No market-driven price discovery
+- May over or under-price tokens
+- Potential for bot attacks without proper safeguards
+
+### Best For
+
+- Projects with strong existing community
+- Sales with specific allocation goals
+- Teams preferring predictable outcomes
+
+Learn more: [Fixed-Price Sales](../sale-types/fixed-price-sales.md)
+
+## Decision Framework
+
+### Choose LBP if:
+
+- You want the market to discover the fair price
+- Broad distribution is a priority
+- Your community is crypto-native
+
+### Choose CCA if:
+
+- Transparency and auditability are essential
+- You're targeting institutional participants
+- MEV resistance is important
+
+### Choose Fixed Price if:
+
+- You have a clear valuation in mind
+- Community allocation is a priority
+- Simplicity is valued over price optimization
+
+## Combining with Compliance
+
+All sale types can be configured with:
+
+- KYC/KYB verification requirements
+- Geographic restrictions
+- Lockups and vesting schedules
+- Allocation limits
+
+See [Compliance Overview](../compliance/README.md) for details.
+
+## Next Steps
+
+- [Liquidity Bootstrapping Pools](../sale-types/liquidity-bootstrapping-pools.md) - Deep dive on LBPs
+- [Continuous Clearing Auctions](../sale-types/continuous-clearing-auctions.md) - Deep dive on CCAs
+- [Fixed-Price Sales](../sale-types/fixed-price-sales.md) - Deep dive on fixed-price mechanics
+- [Running Your Sale](running-your-sale.md) - Execution guide
diff --git a/token-sales/running-your-sale.md b/token-sales/running-your-sale.md
new file mode 100644
index 0000000..04de0e6
--- /dev/null
+++ b/token-sales/running-your-sale.md
@@ -0,0 +1,170 @@
+---
+description: Step-by-step guide to executing your token sale
+---
+
+# Running Your Sale
+
+This guide walks you through the process of executing your token sale with Tally, from initial configuration through launch day.
+
+## Pre-Launch Preparation
+
+### 1. Configure Your Sale Parameters
+
+Work with Tally to define your sale configuration:
+
+**Core Parameters:**
+- Sale type (LBP, CCA, or Fixed Price)
+- Token amount to sell
+- Accepted payment currencies (USDC, USDT, or ETH)
+- Sale duration and timeline
+- Starting price and price curve (for LBPs)
+- Reserve price (for auctions)
+
+**Eligibility Rules:**
+- KYC requirements
+- Geographic restrictions
+- Wallet allowlists or blocklists
+- Allocation limits per wallet
+
+**Post-Sale Settings:**
+- Lockup periods and vesting schedules
+- DEX liquidity parameters
+- Token distribution timing
+
+### 2. Deploy Smart Contracts
+
+Tally handles contract deployment:
+
+- Sale mechanism contracts
+- Token distribution contracts
+- Vesting and lockup contracts (if applicable)
+- DEX liquidity contracts (if applicable)
+
+All contracts are audited and battle-tested.
+
+### 3. Build Your Sale Page
+
+Tally creates a branded, white-labeled experience:
+
+- Custom domain on your site
+- Your branding and design
+- Integrated wallet connection
+- Real-time sale status
+- Compliance verification flows
+
+### 4. Test Everything
+
+Before launch:
+
+- [ ] Test purchases on testnet
+- [ ] Verify KYC flow works correctly
+- [ ] Confirm geographic restrictions function
+- [ ] Review all messaging and copy
+- [ ] Test edge cases and error handling
+
+## Launch Day
+
+### Pre-Launch Checklist
+
+**T-24 hours:**
+- [ ] Final review of all parameters
+- [ ] Team communication channels ready
+- [ ] Support documentation published
+- [ ] Monitoring dashboards configured
+
+**T-1 hour:**
+- [ ] Team assembled and online
+- [ ] Communication channels open
+- [ ] Final systems check complete
+
+### During the Sale
+
+**Monitor Key Metrics:**
+- Participation count
+- Total funds raised
+- Current price (for dynamic sales)
+- Geographic distribution
+- Any error rates or issues
+
+**Be Ready For:**
+- Participant questions
+- Technical issues
+- Market volatility
+- Community management
+
+**Communication Best Practices:**
+- Regular updates on progress
+- Quick response to issues
+- Transparent about any problems
+- Celebrate milestones appropriately
+
+## Platform Capabilities
+
+Tally provides comprehensive tooling for your sale:
+
+### Sale Configuration
+- **Sale length:** Configurable duration and timeline phases
+- **Starting price & price curve:** Set initial price and auction decay parameters
+- **Bid currency:** USDC, USDT, or ETH
+
+### Compliance Integration
+- **KYC/KYI/KYB:** Identity verification through integrated providers
+- **Geo-blocking:** Configure region-specific blocking
+- **Lockups by geography:** Region-specific vesting schedules
+
+### Technical Features
+- **Post-sale liquidity:** Automatically seed DEX liquidity
+- **DEX integrations:** Balancer or Uniswap liquidity provision
+- **Multichain support:** Ethereum, Arbitrum, ZKsync, Base, and more
+
+### Experience
+- **Branded experience:** White-labeled sale page on your domain
+- **Real-time dashboards:** Monitor participation and metrics
+- **Launch-day support:** Tally team available during your sale
+
+## Handling Issues
+
+### Common Problems and Solutions
+
+**High demand causing delays:**
+- Communicate expected wait times
+- Ensure infrastructure can scale
+- Consider extending sale duration if needed
+
+**KYC verification delays:**
+- Have backup verification options
+- Communicate processing times clearly
+- Support participants through the process
+
+**Price volatility (for dynamic sales):**
+- This is expected behavior
+- Educate participants beforehand
+- Don't intervene in market dynamics
+
+<>
+
+## Post-Sale Transition
+
+Once your sale concludes:
+
+1. **Finalize the sale:** Close bidding/purchasing
+2. **Calculate allocations:** Determine final token distribution
+3. **Distribute tokens:** Send tokens to participants (instant or vested)
+4. **Seed liquidity:** If configured, deploy DEX liquidity
+5. **Communicate results:** Share outcomes with community
+
+See [After Your Sale](after-your-sale.md) for detailed post-sale guidance.
+
+## Working with Tally
+
+Tally provides hands-on support throughout:
+
+- **Pre-sale:** Configuration, testing, documentation
+- **Launch day:** Real-time monitoring and support
+- **Post-sale:** Distribution, liquidity, troubleshooting
+
+## Pricing
+
+Tally delivers production-ready token sales on accelerated timelines. Pricing ranges from 2-3% of funds raised, varying by complexity.
+
+[Talk to our team](http://tally.xyz/contact) to discuss your requirements.
diff --git a/token-sales/why-token-sales.md b/token-sales/why-token-sales.md
new file mode 100644
index 0000000..d073efa
--- /dev/null
+++ b/token-sales/why-token-sales.md
@@ -0,0 +1,77 @@
+---
+description: Understanding the advantages of token-based fundraising
+---
+
+# Why Token Sales?
+
+Token sales represent a paradigm shift in how projects raise capital and build communities. This page explains why token sales have become a preferred fundraising mechanism for crypto-native projects.
+
+## The Problem with Traditional Fundraising
+
+### Venture Capital Limitations
+
+Traditional VC funding has served the startup ecosystem well, but it comes with significant trade-offs:
+
+- **Concentrated ownership:** Early investors often acquire large stakes, leaving less room for community ownership
+- **Misaligned incentives:** VCs optimize for their fund's returns, which may not align with long-term protocol health
+- **Limited participation:** Only accredited investors can participate, excluding the very users who make protocols successful
+
+### Airdrop Challenges
+
+Airdrops became popular as an alternative, but they have their own issues:
+
+- **Low-float launches:** Most tokens remain locked, pushing price discovery to thin secondary markets
+- **Sybil attacks:** Free tokens attract farmers rather than genuine users
+- **No capital formation:** Projects don't raise funds to support development
+
+### IPO Drawbacks
+
+Traditional IPOs remain inaccessible for most crypto projects:
+
+- **Time-consuming:** The process can take years
+- **Expensive:** Legal and banking fees are substantial
+- **Intermediary-dependent:** Requires investment banks and regulatory approvals
+
+## The Token Sale Advantage
+
+Token sales solve these problems by combining fundraising with community building:
+
+### Broad Distribution from Day One
+
+- Tokens go directly to participants, not intermediaries
+- Anyone meeting eligibility requirements can participate
+- Creates a decentralized stakeholder base immediately
+
+### True Price Discovery
+
+- Market mechanisms determine fair value
+- Auction formats like LBPs and CCAs prevent manipulation
+- Participants set prices based on genuine demand
+
+### Capital + Community
+
+- Raise funds while building your user base
+- Participants become invested stakeholders
+- Aligned incentives between project and token holders
+
+### Regulatory Clarity
+
+<>
+
+## When Token Sales Make Sense
+
+Token sales are particularly effective when:
+
+- Your project has a clear utility for the token
+- You want broad community ownership
+- You need capital for development and growth
+- You're ready to operate transparently
+
+## Real-World Success Stories
+
+<>
+
+## Next Steps
+
+- [Are You Ready?](are-you-ready.md) - Assess your project's readiness
+- [Choosing Your Sale Type](choosing-your-sale-type.md) - Find the right mechanism for your goals