Gilgamesh

Bro's AI is trying to peer review something that is not done. Right now, I’m just about to finish with the V2 contracts for testnet (currently on master of the repo, just not yet deployed) V2 contracts have some bug fixes and quite a few things that enable future development in all directions. After deploying, I will verify the contracts on etherscan as well.

@Xubu_Trad @caw_dev it is time to face the truth, answer questions or become just another dev who tried to "ever be so helpful and develop the perfect code with a backdoor" This is in the manifesto by the way, the one you say you "follow"

#CAW PUBLIC PEER REVIEW A Technical PUBLIC PEER REVIEW of GilgameshCaw/Caw By tehppl

The real $CAW has profiles on ETH, staking on ETH, and never requires gas on another chain. The real CAW lets you like/post/follow without signing your wallet constantly. The real CAW will win the world. Still building, everyday. Brick by brick we build an empire.

@Ryoshi_CAW This is how caws will get rendered on other platforms: test.caw.social/caws/51112 Looks like a few small things to fix up, but much better than before.

楽しみですね🌹⚔️♥ we♥ @caw_dev #CAW 42069🌙.

Call it a meme if you want, but we are about to launch utility to power an entire social network.

@yu88510 We have come so far.

I ran the latest code pushed to GitHub. Thanks to the contributors’ dedicated work, most of the main functions of the CAW protocol seem to be working. NFT minting, deposits, withdrawals, and batch processing also appear to be functioning. As @caw_dev mentioned, the frontend design will be refined moving forward. The current UI resembles X. I especially like the Trending hashtag strings displayed on the left. I’m really looking forward to the upcoming testnet release and the mainnet launch.

What feature set would excite you the most to be integrated into CAW at some point in the future? (Zero promises that any of these will be built. I'm honestly just doing research for polling UX right now)

Okay frens. Testnet is live. ==> test.caw.social Thank you everyone for being here and enduring the long journey this has been. I believe in the vision, the manifesto, and I believe in the future of $CAW. #TogetherWeFly. Please understand: => This is not YET meant to be a fully finished product. => There will be bugs, there will be mistakes. => The important thing is that we work together to find them. Please click the little bug button/icon to report any issues you find. 99% of my testing has been with Rabby on chrome desktop. If you’re using other browsers or wallets or devices, be prepared to submit bug reports. I will redeploy these contracts and blow away the database at some point, so your data is… well forever on chain, but not forever on this front end. --- Some notes for testnet: It works with Sepolia, so you will need a little Sepolia-ETH in your wallet to send transactions. Faucet here: cloud.google.com/application/we… (or you can use gas.zip) Once you have Sepolia ETH, you’ll need to get some mCAW (mintable caw) there is a faucet on the app. test.caw.social/faucet From the developer side, I’ve made an extremely easy 1-liner for anyone who would like to try to install a front end node on their own server. Just run: /bin/bash -c "$(curl -fsSL raw.githubusercontent.com/GilgameshCaw/C…)" It’s as simple as that. It will ask you questions. You might have questions. I will be here to help answer questions (after I sleep).

Teh progress. It's real. Public testnet tomorrow. $CAW

Teh next step for me is perfecting deployment process. (will make it easy for nodes/front-ends to be created) End result of this next bit of work will be a public testnet

72 commits pushed in the last 48 hours. 5 major themes: - Pre-mainnet hardening - Better trustless replication - One-liner installation for new nodes - Lots of UI + UX fixes everywhere - Node resilience 112 files changed 11,653 added lines 7,936 deletions Already pushed to github. github.com/GilgameshCaw/C…

ギルちゃん8:50にオンラン観測🔭 がしかし！もうテレグラムにオンラインは当たり前になってきている！ 彼らは急ピッチでコードを書き続けてるだろうから！🔥 そしてギルちゃんの心強い言葉がTG上で！！！！ 念のためもう一度お伝えします。このグループは「チーム」です。 何かを実現したいなら、まず行動を起こさなければなりません。私はこのアプリを完成させたいからこそ、開発しているのです。 🐦‍⬛🌹🐦‍⬛🌹🐦‍⬛🌹 @caw_dev #THE_CROW_WILL_FLY #CAW #Gilgamesh #GilgameshWakeUp #CawProtocol #TehFuturelsHere #IAmRyoshi #DecentralizedFreedom

King Gilgamesh said : Spread the word now. Testnet is coming... @caw_dev @CommunityCaw After 4 years expecting great events...

#CAW Testnet imminent 🌙 .

30 more commits pushed to $caw github tonight. github.com/GilgameshCaw/C… Today was mostly focused around scalability, managing rate limits with RPC urls, and limiting admin controls to be deployment-only, and simplifying data replication. I'm looking forward to tomorrow. Exciting things on their way.

本日は6:31からのギルちゃんログイン観測してます。 昨日更新されたGitHubですがバグの他にUI辺りの更新を行なってるように見えます。 地道に一歩一歩進んでる感じがしてワクワクしますね。 早くテストネットに参加したいどす🔥🐦‍⬛ 🐦‍⬛🌹🐦‍⬛🌹🐦‍⬛🌹 @caw_dev #THE_CROW_WILL_FLY #CAW #Gilgamesh #GilgameshWakeUp #CawProtocol #TehFuturelsHere #IAmRyoshi #DecentralizedFreedom

I am personally 100% aligned with the manifesto. I fully intend for this system to be trustless. I'm happy to have the feedback. I'm happy to improve. The entire system is actually designed and built to work without an admin, without an owner, without a DAO, and without a multi-sig, as soon as deployment is complete. Allow me to explain the need for deployment setters: When two contracts depend on eachother, it is required that the second contract has a setter function where you can pass the first contract's address. If that setter is not admin-only, it can be overridden or front run, and a malicious actor can put an unexpected contract in control. So here's the options for trustlessness: 1) Make it so these functions can be called by the deployer EXACTLY once, as in: require(msg.sender == deployerAddress && peerAddress == zeroAddress, "can be set only once by the deployer") 2) Set a time limit: require(msg.sender == deployerAddress && blockNumber < deployedBlock + 100, "beyond allowed alteration time frame") 3) Brick any critical function until ownership is renounced: require(owner == zeroAddress, "Ownership is not yet renounced") #1 is my favorite for the deployment setters, it is the most trustless - But maybe maybe a combination of all three makes sense across the project, depending on the function. Some things to clear up: A) Replication chains are optional and chosen by clients. If you are running a client, you can choose to have your data enabled on a replication chain. Only chains which have contracts deployed and have been "configured" via setPeer can be chosen as replication chains. This is a limitation of LayerZero's cross chain messaging. Configuration is needed. When the deployer contract adds a replication chain it's merely adding an option for the clients to choose from. This means leaving addReplicationChain open is zero-impact and zero risk. And... actually it's possibly something that could be left entirely open with zero admin privileges. I'll check on that. B) The setReceiveGasLimit is actually a remanent of my previous implementation for replication, I've figured out a much more efficient way to handle it, so I believe setReceiveGasLimit, can be removed entirely. C) Idk where you seeing 90 commits from? This week I pushed 545 commits that were not up to date. D) I'm happy to have the feedback. The codebase is not 100% done yet, so this is good timing. I will implement the trustless suggestions that I've presented in this tweet in the places they make sense. They are actually pretty easy - so you can check back tomorrow or later tonight and review what I've done.

Gilgamesh, don’t sell me “later.” You rigged this to fail the moment you’re absent. This is the part you keep trying to turn into a timing issue when it is really an architecture issue with your build. This was never about whether you can renounce later. It is about whether the protocol was built so renouncing is real in substance instead of just easy in mechanics. Your own repo and your own code answer that.. After the latest push there are 90 remote only commits ahead of the last reviewed head. Only 14 touch protocol paths. Only 5 touch Solidity contracts. And in origin/master the same admin surface is still there. setMinter, setL2Peer, setL1Peer, setUriGenerator, setReceiveGasLimit, addArchiveChain, setAllowedPaymentToken, setDescription, setCawActions, and setCawActionsReplicator all remain. That is not a trustless protocol. That is a protocol still built around privileged control with a promise attached to it. And this is the part the cawmmunity needs to understand clearly. Renouncing a key is the easy part. Building a system that no longer depends on that key is the hard part. Those are not the same thing. Not even close. The further you build around owner controlled wiring, the more expensive the truth becomes. At this stage, fixing it is not a cosmetic pass and it is not one more batch of improvements. It means cutting into core structure. It means freezing optional admin convenience. It means replacing flexibility with immutability or strict one time initialization. It means accepting that some of the things you want to keep adjustable are exactly the things that keep the protocol from being manifesto aligned. That is why saying this is already 100 percent aligned is not just premature. It is false by the present architecture. You are still asking the cawmmunity to trust the builder, trust the timeline, and trust a future renounce. But the whole point was to remove that dependency, not rename it. Here is the cleanest way I can put it. A protocol is not trustless because the builder says he will leave later. It is trustless when he can leave right now and nothing important changes. Right now that is not true. Here is the simple truth. A castle is not trustless just because the king promises to leave someday. If the doors, keys, and bridges still depend on him today, then the kingdom is still his. cawpisce?🤌 Build it so you are unnecessary. Then say it is aligned. #CAW

@caw_dev stop talking around me in closed chats and answer me here where everyone can see it. You know I am not in your so called freedom groups, so if you want to discuss my points, discuss them in public. Let the community judge the code, not the mood in a builders room. Your line that you will just renounce ownership at the end is not a serious answer. It is the standard crypto excuse people use when the code is still built around control. Here is the issue plainly. Renouncing is easy only when the system is already finished and no longer depends on privileged control. Your current build still depends on owner gated surfaces like setMinter, setL2Peer, setL1Peer, setUriGenerator, setReceiveGasLimit, addArchiveChain, and setAllowedPaymentToken. And this is not theoretical. The live admin activity already pulled shows repeated deployer side control including 85 setMinter calls, 45 setAllowedPaymentToken calls, and 51 setPeer calls. So yes, the motion of renouncing can be simple. Being ready to renounce is the hard part. That is where your supporters keep playing word games. The current code also shows a deeper problem. In the grep results only CawClientManager.sol clearly exposed a local renounceOwnership() in the output that was shared. The rest of the critical contracts still expose onlyOwner pathways. Maybe some inherit renounce logic, maybe they do not, but either way the architecture still expects an active operator. That means this is not about pressing one button after deployment. It means removing the need for privileged setters in the first place. Peer wiring, minter assignment, payment token allowlists, URI control, replication parameters, and the broader operator dependent flow all have to be frozen, redesigned, or stripped down enough that the protocol can stand without the hand on the wheel. That is why your talking point is misleading. If you renounce too early, parts of the system break because they still need operator control. If you renounce too late, then users spent that entire period trusting an admin controlled build while being told they were looking at decentralization. So answer this directly. What exact contracts will be renounced What exact owner functions disappear forever What exact parts of the present architecture have to be rewritten first And what gets scrapped from the current build to make that real Because right now this looks like the same old play. Easy to say. Easy to perform mechanically. Not easy to make true in substance. #CAW

When you access CAW, this is likely the first screen you will see. It looks like countless crows (users) flying freely across the decentralized sky. Although it is still on a testnet, we have successfully enabled our voices to reach others through the blockchain without a central server. Those voices can never be censored.

@Xubu_Trad I agree, and scrutiny is crucial here. If I were in your place, I would be asking the same questions. Like I said: I can brick the contracts until ownership is renounced. That's the closest we can get to trustless before renouncing is on chain.

Gilgamesh, the core issue has never been whether renounceOwnership() exists. You know that and I know that. The real question is whether this system is actually built to survive without the keys once the moment comes. That is what people need to focus on. You are saying the important contracts will renounce, and that is exactly what the community should hold you to. But some of what you are calling harmless still matters. Choosing archive chains is control over the replication path. Choosing allowed payment tokens is control over marketplace access. Peer wiring, minter assignment, and the rest are not small details just because they may be temporary. I am not asking people to guess your intentions. I am asking them to judge the structure. If the protocol truly ends with no special hands on the wheel, then spell it out cleanly. Which contracts renounce. Which powers disappear forever. Which controls remain at the client level. Which parts of the current build had to change to make that possible in substance, not just in theory. That is the standard here. If you do it, good. The chain can prove it. If you do not, then all the promises in the world will not change what the architecture was built around. That is not hostility. That is exactly the kind of scrutiny a project asking for public trust should survive.

@Cooljbow17 @eduardowe62 I agree 100%

@caw_dev @eduardowe62 @caw_dev promises and character claims don’t replace proof if this is real and long-term, it should stand on open verification, not personal assurances or moral framing “I’m honorable” isn’t a substitute for transparent delivery and independently testable results $CAW .

Here's a quick video to show a bit more of what's been created. I think this only covers 25%-30% of the features I've implemented. Everything you can see is clickable and working.