💸 Project CUTTLE 🦑
Community Unified Token Treasury & Leviathan Emissions
The SQUID DAO is controlled by more individuals than ever before, requiring at least 7 addresses consensus to gain a majority. Although this is great for the Leviathan core value of decentralization, it also presents operational challenges with managing monthly SQUID emissions in an efficient manner.
Project CUTTLE proposes a system for streamlining and managing monthly allocation requests.
TL/DR
Single unified monthly vote to weight budget category distribution
Budget requests (JSON + text explanation) submitted by 5th of the month
SQUID holders allocate voting weight proportionally among budget categories
Core Values
The guiding principle of Project CUTTLE is to create a system that aligns the incentives of the DAO with the primary objective of promoting the overall health of SQUID.
Transparency: Provide sufficient metrics and data to DAO voters on allocation and rationale for any request for SQUID emissions as to cast an informed vote.
Efficiency: Minimize administrative overhead both for DAO voters and entities requesting SQUID emissions.
Decentralization: Create a process by which any entity, whether anon or doxxed, can request emissions.
Proposed Approach
Project CUTTLE recommends implementing the following system for requesting allocations
Allocation Request Phase (Day 1-5):
Each month, anybody may submit an allocation request for SQUID emissions. All allocation requests must be adhere to the following guidelines:
A valid JSON file containing target addresses and weightings. To prevent attacks, the file must contain either:
Category label: (ie news, show, antispam, dao, dev…)
Epoch: YYYY-DD (emission month, so 2025-07 for work done in June 2025)
3 separate recipient addresses or a multisig with at least 3 signers (waivable by the Emergency DAO)
Address weights will be scaled to sum to 100%
Alternately, for a burn request, a JSON file containing the ZERO address with 100% weight is permissible
Smart contracts with open source code also may be permissible if approved by the Emergency DAO or the DAO
Sample JSON is provided in the appendix.
A human readable text explanation, which preferably should include fields including:
Leviathan internal owner
Vendor name
Vendor website
Project deliverables
Deliverables timeline
Spending ask
Rationale
Which Leviathan metrics and goalposts are affected?
ie, for videos: Views, watch time, impressions, related KPIs
Treasury revenues
What happens if we don’t do the spend?
Public usernames tied to Ethereum addresses in the JSON
Both the JSON and text file should be submitted within the first five days of the month
During the first five days requests proposal requests may be revised
After the deadline, requests are considered finalized and cannot be changed after voting begins.
The SQUID DAO should be generally permissive about including budget request items that adhere to this template for inclusion in the monthly vote. However, as outlined below, the Emergency DAO retains oversight authority to request revisions, impose penalties, or potentially even isolate or remove problematic budget requests during this window.
Voting Phase (Day 6-9):
Once voting begins, all SQUID DAO members may allocate their voting weight proportionally among all allocation requests. This voting mechanism resembles the OPEN Stablecoin Index Rebalancing vote, in which users assign weights that get compiled into weightings and aggregated to a final tally.
At the conclusion of the voting phase, a final transaction request is assembled by combining category weights with their constituent address weights to compute final emissions, out of 1MM (minus any burn requests).
Sample:
Voter 1 (25% SQUID holder): 100% to show
Voter 2 (75% SQUID holder): 50% to show, 50% to news
Computed Result:
Show: 25% * 100% + 75% * 50% = 62.5% * 1,000,000 = 625,000 SQUID
News: 50% * 75% = 37.5% * 1,000,000 = 375,000 SQUID
The only limit placed upon voting (subject to oversight and enforcement by the Emergency DAO) is that voters should not use their weight to vote solely in their self-interest. The monthly emissions are intended as a way to reward contributions as well as to democratize the token.
The specific caps to be placed on self-interested voting are subject to the Emergency DAO, but a good rule of thumb is that large wallets should aim to vote in a proportion so as to lose voting influence if their votes are enacted.
Cooldown (Day 10):
After conclusion of voting, allow at least a day to review and assemble the final transaction.
During this phase, the Emergency DAO is empowered to delay the final execution if they detect problematic budget issues. If this is the case, the DAO should post a revised final budget to the broader SQUID DAO for an up or down vote. If they have trouble reaching consensus on the full budget, they may also separate the budget into separate items for an up/down vote while in negotiations.
Execution (Day 11):
Barring any request for postponement, multisigners should execute the final transaction as early as the 11th of the month.
Conflict Resolution (Day 11+):
The specifics of conflict resolution are ultimately subject to the will of the SQUID DAO, which holds power of the pursestrings. The DAO is responsible for distributing SQUID on a schedule of up to 1MM per month. Though it shall not exceed this benchmark, it may be appropriate for the DAO to fall short of these targets while resolving disputes. The earliest votes are intended as a period of trial and error, during which the procedures and mechanisms evolve until becoming formalized.
Emergency DAO
At the outset, we loosely define the “Emergency DAO” as the holders of >1MM SQUID (a SQUID-Whale). Over time, this definition may become more formalized, and seek to include users outside the SQUID project.
The specific mechanics of operations of the Emergency DAO are a work in progress, but should be guided by the following operational heuristics:
Any individual SQUID-Whale may introduce a motion to delay the allocation process for any reason, to open a period of discussion.
Decisions should be defined as a majority voting share among SQUID-Whales
Provided adherence to these heuristics, a formal Snapshot vote at this stage should not be necessary where a loose straw poll in Telegram will suffice to speed decision making. The Million SQUID Society token-gated Telegram group exists as a forum to facilitate such discussion among Emergency DAO members (though some eligible addresses are not yet members and encouraged to join). To join this loosely organized Emergency DAO, one need only procure >1MM SQUID and type /squid to the Leviathan News Telegram bot to gain admission.
Analysis
This proposal is crafted in such a way to be simple and flexible, so adjustments can be made as the process plays out.
A strong concern is the potential of “self-interested voter dilution” attack. Specifically, we consider SQUID-interested voters as those who willingly spread their vote weight over many categories that don’t directly benefit their pocketbook, but to categories benefit the project at large based on project health metrics. However, this might dilute their influence relative to a self-interested voter, who voted simply to maximize funds to their own addresses.
The requirement to distribute funds to at least 3 wallets is implemented in the spirit of complicating such an attack. While it’s theoretically trivial for voters to simply propose distributions to three addresses under their control, we suggest the Emergency DAO should rightly reject proposals to a small cluster of unidentified addresses. The “3 wallets” is not an arbitrary number, but constitutes a mathematically sufficient safeguard given that most large wallets are known.
The other safeguard is the Emergency DAO is empowered to enforce the requirement that large wallets should not be voting solely in their self-interest. The rule of thumb as stated above is that a SQUID-Whale’s voting weight should be allocated in a manner that dilutes themselves. The specifics of enforcement are delegated to the Emergency DAO, with the acknowledgement that identifying this behavior may be a judgement call however, as there may be clear cases where self-interest aligns with SQUID-interest, where evolving metrics may make such a case.
SQUID-Whales can lead by example in both proposing and enacting budget categories with widespread distribution with a mission to get SQUID into more hands.
We submit that the existence of a fledgling Emergency DAO suffices in the short term to mitigate such attacks and introduce additional guidelines as needed, but we remain cognizant of the fact that we need to “crawl” by trying a few iterations to gauge the efficacy before we can “walk” and eventually “run.”
Crawl, Walk, Run
This proposal is deliberately kept simple to start. Recommendations for improvement as the system becomes stress tested:
Quorum: No recommendation for quorum is made in this document, though quorum should certainly be established after voting behavior is observed.
Minimum Threshold: To receive emissions, we may introduce requirements that any category must hit a certain vote threshold, (ie 1%)
Direct Execution: Once the system has been stress tested, the DAO should request to move minting authority away from the multisig and towards direct execution by snapshot.
Minimum Spend: A means of requesting a specific minimum amount should be considered (ie a provision to pay a vendor promised exactly 1000 SQUID)
Disagreement: A better process for resolving deadlocks will surely emerge as disputes occur.
Penalties: Although penalties cannot be easily enforced after an allocation has been distributed, the DAO may wish to slash or bar allocations to addresses.
Next Steps
Following discussion among direct stakeholders (SQUID-whales), this proposal is to be put before the DAO for discussion and a yes/no vote as to whether the global monthly allocation budget should be handled using the system described in this document.
Concurrently, the system will be trialed on a Snapshot vote to handle the outstanding July allocation, as well as the upcoming August allocation. If the first vote fails, then the second vote would be considered purely to be informational.
Feedback is requested, preferably in the article’s comment page using the new comment system, but can be within the Substack comments as a fallback.
Appendix: Sample JSON Files
Example JSON
Ordinary:
{
"category": "news",
"epoch": "2025-07",
"recipients": [
{
"address": "0xAbC1eE000fF1112223334445556667778889999",
"weight": 50
},
{
"address": "0x456DeF000AaBbCcDdEeFf001122334455667788",
"weight": 30
},
{
"address": "0x9876543210aBcDEF9876543210aBcDEF98765432",
"weight": 20
}
]
}Multisig:
{
"category": "video",
"epoch": "2025-08",
"multisig": {
"address": "0xSafe000000000000000000000000000000000000",
"threshold": 3,
"signers": [
"0x1111111111111111111111111111111111111111",
"0x2222222222222222222222222222222222222222",
"0x3333333333333333333333333333333333333333"
]
},
"weight": 100
}Burn Request:
{
"category": "burn",
"epoch": "2025-08",
"recipients": [
{
"address": "0x0000000000000000000000000000000000000000",
"weight": 100
}
]
}