![LastToSign's tweet photo. Identity.md NFT turned out not to be a ticket to launch your own token
Confirmed utility for $IMD
According to a GitHub mirror discovered by @0xfinne, it is a developer credential that allows its holder to complete tasks assigned by the factory
The mirror is highly likely to be authentic. It references the original private repository Identity-md/launch-3-new, factory issue #20 and launch number 3
The first commits were made by identitymd-launch-factory[bot]. The history also contains commits and signed merge commits from Adam under his surfer77 GitHub account
How the factory works in simple terms
Imagine a factory that produces new markets:
> someone proposes an idea for a token or market.
> the Identity.md team accepts or rejects it.
> the factory divides the development process into separate tasks:
>>design the architecture
>>write the smart contract
>>write the tests
> an Identity.md NFT holder registers as a worker.
the scheduler assigns them a specific task
> the worker uses Codex, Claude or writes the code manually
> the factory checks the code, tests and security.
> a maintainer accepts the result
> a multisig authorizes the deployment
> a new PROJECT/IMD market appears
This means the NFT is not required by Codex or by someone who simply proposes an idea. It is required by the developer-worker
The NFT tells the factory:
> this GitHub developer is linked to this wallet
> they own a valid Identity.md credential
> they can be assigned a task
> the factory can accept a signed result from them
Before accepting each PR, the system checks NFT ownership through ownerOf() on Ethereum mainnet. If the worker sells the NFT, they lose the right to complete the assigned work
This is implemented directly in the code: a developer owns an NFT, registers as a worker and receives the right to complete assigned hook-development tasks
They cannot independently choose any project, write an arbitrary hook and immediately launch it
This also explains the line from Adam’s logs: waiting for the next signed milestone
It now appears that a signed milestone is most likely not a command for an autonomous economic agent, but a specific task inside the factory
For example:
> design the architecture
> write the contract
> prepare the tests
The worker receives the task, completes it and signs the result tied to an exact commit and Git tree
The code then passes through several layers of verification. This means the agent published by Adam is probably an autonomous developer-worker:
> Codex writes the hook
> the signed milestone limits it to a specific task
> the factory verifies the result
> a maintainer accepts the code
> a multisig authorizes the launch
AI is not the final product here, at least for now. It is one of the factory workers
How is this different from a regular launchpad?
A regular launchpad works roughly like this:
> enter a name and ticker
> a standard token is created
> a bonding curve or regular pool opens
> trading begins
Almost every project launches from the same template
The name, supply and image change, but the market mechanics remain similar. Identity.md is trying to build a system where each project can receive its own mechanics programmed through a separate Uniswap v4 hook
One hook can:
> burn part of the fees
> change fees depending on specific conditions
> restrict certain trades
> direct assets according to predefined rules
> create a new liquidity or distribution model
This makes Identity.md look less like a regular token launchpad and more like a combination of:
> launchpad
> smart contract studio
> AI development pipeline
> security review system
The main potential know-how is not found in the individual components
NFT gating, AI coding, GitHub Actions, multisigs and Uniswap v4 hooks already exist. What may be new is combining them into a single factory that turns an idea into a finished and verified market
And this is where the role of $IMD appears.
The factory schema specifies: "quoteSymbol": { "const": "IMD" } It uses const, not one of several possible options
This means the current architecture requires every market to be created as:
> PROJECT/ $IMD
If the router hides the intermediate operations, the user may not even notice this. But inside the system, buying a new asset would still require $IMD
For the person proposing an idea, the potential offer looks like this:
> they bring the idea
> the factory creates the specification
> AI and NFT workers write the hook
> the system runs tests and security reviews
> the multisig authorizes the deployment
> a new programmable market appears
This means the person does not necessarily need to find a Solidity developer, auditor and DevOps team independently
The NFT currently gives its holder the right to work inside the factory, but the economic reason to buy that right has not yet been revealed
Identity.md is not building a single burn hook
It is an attempt to create a factory that turns an idea into a verified programmable market.
The NFT controls who can participate in production
$IMD is intended to become the shared settlement asset across all markets
Watching closely](https://pbs.twimg.com/media/HPYA3RdXoAAMWC0.jpg)
![LastToSign's tweet photo. Identity.md NFT turned out not to be a ticket to launch your own token
Confirmed utility for $IMD
According to a GitHub mirror discovered by @0xfinne, it is a developer credential that allows its holder to complete tasks assigned by the factory
The mirror is highly likely to be authentic. It references the original private repository Identity-md/launch-3-new, factory issue #20 and launch number 3
The first commits were made by identitymd-launch-factory[bot]. The history also contains commits and signed merge commits from Adam under his surfer77 GitHub account
How the factory works in simple terms
Imagine a factory that produces new markets:
> someone proposes an idea for a token or market.
> the Identity.md team accepts or rejects it.
> the factory divides the development process into separate tasks:
>>design the architecture
>>write the smart contract
>>write the tests
> an Identity.md NFT holder registers as a worker.
the scheduler assigns them a specific task
> the worker uses Codex, Claude or writes the code manually
> the factory checks the code, tests and security.
> a maintainer accepts the result
> a multisig authorizes the deployment
> a new PROJECT/IMD market appears
This means the NFT is not required by Codex or by someone who simply proposes an idea. It is required by the developer-worker
The NFT tells the factory:
> this GitHub developer is linked to this wallet
> they own a valid Identity.md credential
> they can be assigned a task
> the factory can accept a signed result from them
Before accepting each PR, the system checks NFT ownership through ownerOf() on Ethereum mainnet. If the worker sells the NFT, they lose the right to complete the assigned work
This is implemented directly in the code: a developer owns an NFT, registers as a worker and receives the right to complete assigned hook-development tasks
They cannot independently choose any project, write an arbitrary hook and immediately launch it
This also explains the line from Adam’s logs: waiting for the next signed milestone
It now appears that a signed milestone is most likely not a command for an autonomous economic agent, but a specific task inside the factory
For example:
> design the architecture
> write the contract
> prepare the tests
The worker receives the task, completes it and signs the result tied to an exact commit and Git tree
The code then passes through several layers of verification. This means the agent published by Adam is probably an autonomous developer-worker:
> Codex writes the hook
> the signed milestone limits it to a specific task
> the factory verifies the result
> a maintainer accepts the code
> a multisig authorizes the launch
AI is not the final product here, at least for now. It is one of the factory workers
How is this different from a regular launchpad?
A regular launchpad works roughly like this:
> enter a name and ticker
> a standard token is created
> a bonding curve or regular pool opens
> trading begins
Almost every project launches from the same template
The name, supply and image change, but the market mechanics remain similar. Identity.md is trying to build a system where each project can receive its own mechanics programmed through a separate Uniswap v4 hook
One hook can:
> burn part of the fees
> change fees depending on specific conditions
> restrict certain trades
> direct assets according to predefined rules
> create a new liquidity or distribution model
This makes Identity.md look less like a regular token launchpad and more like a combination of:
> launchpad
> smart contract studio
> AI development pipeline
> security review system
The main potential know-how is not found in the individual components
NFT gating, AI coding, GitHub Actions, multisigs and Uniswap v4 hooks already exist. What may be new is combining them into a single factory that turns an idea into a finished and verified market
And this is where the role of $IMD appears.
The factory schema specifies: "quoteSymbol": { "const": "IMD" } It uses const, not one of several possible options
This means the current architecture requires every market to be created as:
> PROJECT/ $IMD
If the router hides the intermediate operations, the user may not even notice this. But inside the system, buying a new asset would still require $IMD
For the person proposing an idea, the potential offer looks like this:
> they bring the idea
> the factory creates the specification
> AI and NFT workers write the hook
> the system runs tests and security reviews
> the multisig authorizes the deployment
> a new programmable market appears
This means the person does not necessarily need to find a Solidity developer, auditor and DevOps team independently
The NFT currently gives its holder the right to work inside the factory, but the economic reason to buy that right has not yet been revealed
Identity.md is not building a single burn hook
It is an attempt to create a factory that turns an idea into a verified programmable market.
The NFT controls who can participate in production
$IMD is intended to become the shared settlement asset across all markets
Watching closely](https://pbs.twimg.com/media/HPYA3QxWUAIwp64.jpg)
![LastToSign's tweet photo. Identity.md NFT turned out not to be a ticket to launch your own token
Confirmed utility for $IMD
According to a GitHub mirror discovered by @0xfinne, it is a developer credential that allows its holder to complete tasks assigned by the factory
The mirror is highly likely to be authentic. It references the original private repository Identity-md/launch-3-new, factory issue #20 and launch number 3
The first commits were made by identitymd-launch-factory[bot]. The history also contains commits and signed merge commits from Adam under his surfer77 GitHub account
How the factory works in simple terms
Imagine a factory that produces new markets:
> someone proposes an idea for a token or market.
> the Identity.md team accepts or rejects it.
> the factory divides the development process into separate tasks:
>>design the architecture
>>write the smart contract
>>write the tests
> an Identity.md NFT holder registers as a worker.
the scheduler assigns them a specific task
> the worker uses Codex, Claude or writes the code manually
> the factory checks the code, tests and security.
> a maintainer accepts the result
> a multisig authorizes the deployment
> a new PROJECT/IMD market appears
This means the NFT is not required by Codex or by someone who simply proposes an idea. It is required by the developer-worker
The NFT tells the factory:
> this GitHub developer is linked to this wallet
> they own a valid Identity.md credential
> they can be assigned a task
> the factory can accept a signed result from them
Before accepting each PR, the system checks NFT ownership through ownerOf() on Ethereum mainnet. If the worker sells the NFT, they lose the right to complete the assigned work
This is implemented directly in the code: a developer owns an NFT, registers as a worker and receives the right to complete assigned hook-development tasks
They cannot independently choose any project, write an arbitrary hook and immediately launch it
This also explains the line from Adam’s logs: waiting for the next signed milestone
It now appears that a signed milestone is most likely not a command for an autonomous economic agent, but a specific task inside the factory
For example:
> design the architecture
> write the contract
> prepare the tests
The worker receives the task, completes it and signs the result tied to an exact commit and Git tree
The code then passes through several layers of verification. This means the agent published by Adam is probably an autonomous developer-worker:
> Codex writes the hook
> the signed milestone limits it to a specific task
> the factory verifies the result
> a maintainer accepts the code
> a multisig authorizes the launch
AI is not the final product here, at least for now. It is one of the factory workers
How is this different from a regular launchpad?
A regular launchpad works roughly like this:
> enter a name and ticker
> a standard token is created
> a bonding curve or regular pool opens
> trading begins
Almost every project launches from the same template
The name, supply and image change, but the market mechanics remain similar. Identity.md is trying to build a system where each project can receive its own mechanics programmed through a separate Uniswap v4 hook
One hook can:
> burn part of the fees
> change fees depending on specific conditions
> restrict certain trades
> direct assets according to predefined rules
> create a new liquidity or distribution model
This makes Identity.md look less like a regular token launchpad and more like a combination of:
> launchpad
> smart contract studio
> AI development pipeline
> security review system
The main potential know-how is not found in the individual components
NFT gating, AI coding, GitHub Actions, multisigs and Uniswap v4 hooks already exist. What may be new is combining them into a single factory that turns an idea into a finished and verified market
And this is where the role of $IMD appears.
The factory schema specifies: "quoteSymbol": { "const": "IMD" } It uses const, not one of several possible options
This means the current architecture requires every market to be created as:
> PROJECT/ $IMD
If the router hides the intermediate operations, the user may not even notice this. But inside the system, buying a new asset would still require $IMD
For the person proposing an idea, the potential offer looks like this:
> they bring the idea
> the factory creates the specification
> AI and NFT workers write the hook
> the system runs tests and security reviews
> the multisig authorizes the deployment
> a new programmable market appears
This means the person does not necessarily need to find a Solidity developer, auditor and DevOps team independently
The NFT currently gives its holder the right to work inside the factory, but the economic reason to buy that right has not yet been revealed
Identity.md is not building a single burn hook
It is an attempt to create a factory that turns an idea into a verified programmable market.
The NFT controls who can participate in production
$IMD is intended to become the shared settlement asset across all markets
Watching closely](https://pbs.twimg.com/media/HPYA3QlWMAA3VR2.jpg)
Olivia
Online
LastToSign
@LastToSign
token mechanics, value capture, overlooked opportunities.
facts ≠ hypotheses
Onchain
Joined November 2021
288 Following
505 Followers
763 Posts
Pinned Tweet
For the first time, @surfcoderepeat “redacted agent thing” worked on its own.
After today’s update, the investment thesis for Identity.md NFTs looks at least as compelling as the thesis for $IMD.
It now seems we may have viewed Identity.md too narrowly as a single Uniswap v4 burn hook. The hook could be only the economic module of a larger autonomous AI agent system.
Adam posted: “omg my redacted agent thing just worked by itself for the first time”
And then: “it’s alive”
The published logs show:
> the identitymd_worker process running
> an agent initialized through agentclientprotocol/codex-acp
> Codex specified as the agent
> a worker pool created: agent_pool_ready agents=1
> after initialization, session_activity_age resets to near zero, indicating fresh activity inside a real agent session
But the most interesting line is: waiting for the next signed milestone
This suggests the agent may not operate continuously and without constraints. Instead, it could progress through signed tasks or checkpoints.
A possible flow:
> the agent retains a long-term goal
> receives a signed milestone
> executes the next stage
> returns to waiting for another signature
A signed milestone is not a standard feature of codex-acp.
It is more likely a custom authorization or coordination layer Adam has built on top of Codex.
The official codex-acp documentation confirms that this is more than a chatbot connection. Through ACP, Codex can work with files, terminals, MCP tools and subagents.
The experimental Goal Extension also allows an agent to retain a long-term objective and launch subsequent autonomous cycles.
However, there is no confirmation yet that identitymd_worker is using this specific feature.
What makes the timing especially interesting is that a wallet linked to the project bought two more Identity.md NFTs on the same day #1751 and #354
The wallet now holds five NFTs.
The newly purchased NFTs differ significantly in rarity, making this look more like the accumulation of functional identities for testing than a hunt for rare traits.
Only 2,000 Identity.md NFTs exist.
The most likely NFT use cases include:
> a persistent identity for an autonomous agent
> the right to create or launch an agent
> storage for settings, memory, history and reputation
> authorization of actions through the owner’s signature
> one NFT representing one agent or profile
> access to launching an autonomous market
The sequence of recent events is also worth watching.
First, Adam added to the existing mainnet IMD/WETH position:
> 33.2527 ETH
> 124,366 IMD
Then the linked wallet purchased two Identity.md NFTs.
After that, Adam reported the first autonomous activation of his agent.
This does not prove a direct connection between these events.
But the possible architecture is beginning to take shape:
> Identity.md NFT - identity
> identitymd_worker - persistent runtime
> Codex ACP - intelligence and task execution
> signed milestones - action authorization
> Uniswap v4 hook - autonomous economic module
> $IMD - potential shared asset of the system
As of today, Identity.md has an interesting but not yet fully connected stack:
> NFT identity + signed milestones + Codex agent + existing omnichain token + Uniswap v4 dynamic burn
None of these components is unique on its own.
The potentially unique part is how they may fit together.
There is still no proof that the NFT authorizes the agent, that milestones are stored onchain or that the system requires $IMD to operate.
The mainnet hook and confirmed economic integration of the NFTs have not appeared either.
Confirmation of these connections could become the main catalyst for both assets.
Is $IMD simply the first market inside the system, or will every autonomous identity need IMD to operate?
Watching closely...
While the $IMD token is trading sideways, the Identity MD NFTs have repriced from 0.015 $ETH to roughly 0.2$ ETH in just 10 days.
If the bet here is on future utility, sweeping the floor is the logical play. Paying a premium for rarity right now is pure speculation.
> the contract explicitly includes univ4Hook and univ4Pool fields, confirming the direct link to Adam's future system. But right now, both are zero addresses.
> the ability to write an identity is disabled: identityAllowed = false.
> all 2,000 NFTs currently share the exact same baseline: Memory State: Unwritten and Memory Lock: Open.
> there are zero mechanics in the current code that provide additional utility for rare traits or low token IDs.
Rarity on OpenSea is driven by combinations of fairly common traits. True 1/1 unique traits are almost non-existent.
@saintniko v4 made that builder first thesis even stronger, now the market itself is programmable
BoldLeonidas @boldleonidas and the associated @boldpfps account are teasing the return of cartoon PFPs
Today, Bold posted “Bring back cartoon PFPs”
Before that, @boldpfps wrote “Ok yeah I should do this now”, showed one of the PFPs and asked “Wen WL?”
On WL and the possible launch mechanic
Under the “Wen WL?” post, gmoney replied “no wl, drop it on fwa”. gmoney and @0xQuit have already publicly discussed the mechanic of a potential Bold mint via $FWA
$FWA, or Fake World Assets, is an NFT gacha from @token_works :
> a depositor places a supported NFT into a pool together with ETH backing
> a buyer pays a protocol-calculated price for a random pull
> Chainlink VRF selects the NFT
> the NFT can be kept, immediately relisted or returned to its original owner to receive 90% of its backing in ETH or through an automatic $FWA buy
Owning another NFT collection is not required to participate. If Bold chooses this setup, it will be a public gacha mechanic rather than a regular holder-gated mint
Another signal: Bold’s own collection, Bold Pepes, consisting of 92 original 1/1s, is already included in FWA’s initial allowlist
The probability of a regular WL based on a holder snapshot currently looks lower. Especially since back in 2024, @boldpfps wrote “No alpha group WL” and “No guaranteed WL for previous stuff”
If a holder snapshot does appear, the most logical candidates are:
> Bold Pepes: the most direct link to FWA and Bold’s current official Linktree. A small and almost illiquid 1/1 collection
> Classic Pepes: the most logical mass-market candidate. 1,069 cartoon PFPs by BoldLeonidas, stylistically close to the new teaser
> CopeBeanz: 1,500 cartoon PFPs released in April 2022. Bold included them in the main BoldVerse Phase 1 and wrote that he was thinking about what else could be offered to holders
> Bold PFP Commissions: a small and illiquid collection of custom PFPs on Base, listed in Bold’s official Linktree
> Boldinals: 99 original works on Bitcoin Ordinals. More likely a potential OG/VIP category than a mass WL
Bring back cartoon PFPs.
Who to follow
Be careful with partnerships on Anvil
A collection being listed on Anvil does not mean it has a partnership with @ClutchMarkets or $STONKBROKER
The platform is permissionless: anyone can pay 1 $ETH to create a market for their own-or a fake-collection
A suspicious unofficial $CLOCKIN has already appeared CA: 0x2079C001b1A1e1be53B7463387510DdaC2b45dA2
There is also a test market called tstdonotbuy, whose description explicitly says not to buy
I’m not calling the other Unverified collections scams yet. The lack of a checkmark alone proves nothing
Simply having a page on Anvil is not proof of legitimacy or a partnership
Identity.md NFT turned out not to be a ticket to launch your own token
Confirmed utility for $IMD
According to a GitHub mirror discovered by @0xfinne, it is a developer credential that allows its holder to complete tasks assigned by the factory
The mirror is highly likely to be authentic. It references the original private repository Identity-md/launch-3-new, factory issue #20 and launch number 3
The first commits were made by identitymd-launch-factory[bot]. The history also contains commits and signed merge commits from Adam under his surfer77 GitHub account
How the factory works in simple terms
Imagine a factory that produces new markets:
> someone proposes an idea for a token or market.
> the Identity.md team accepts or rejects it.
> the factory divides the development process into separate tasks:
>>design the architecture
>>write the smart contract
>>write the tests
> an Identity.md NFT holder registers as a worker.
the scheduler assigns them a specific task
> the worker uses Codex, Claude or writes the code manually
> the factory checks the code, tests and security.
> a maintainer accepts the result
> a multisig authorizes the deployment
> a new PROJECT/IMD market appears
This means the NFT is not required by Codex or by someone who simply proposes an idea. It is required by the developer-worker
The NFT tells the factory:
> this GitHub developer is linked to this wallet
> they own a valid Identity.md credential
> they can be assigned a task
> the factory can accept a signed result from them
Before accepting each PR, the system checks NFT ownership through ownerOf() on Ethereum mainnet. If the worker sells the NFT, they lose the right to complete the assigned work
This is implemented directly in the code: a developer owns an NFT, registers as a worker and receives the right to complete assigned hook-development tasks
They cannot independently choose any project, write an arbitrary hook and immediately launch it
This also explains the line from Adam’s logs: waiting for the next signed milestone
It now appears that a signed milestone is most likely not a command for an autonomous economic agent, but a specific task inside the factory
For example:
> design the architecture
> write the contract
> prepare the tests
The worker receives the task, completes it and signs the result tied to an exact commit and Git tree
The code then passes through several layers of verification. This means the agent published by Adam is probably an autonomous developer-worker:
> Codex writes the hook
> the signed milestone limits it to a specific task
> the factory verifies the result
> a maintainer accepts the code
> a multisig authorizes the launch
AI is not the final product here, at least for now. It is one of the factory workers
How is this different from a regular launchpad?
A regular launchpad works roughly like this:
> enter a name and ticker
> a standard token is created
> a bonding curve or regular pool opens
> trading begins
Almost every project launches from the same template
The name, supply and image change, but the market mechanics remain similar. Identity.md is trying to build a system where each project can receive its own mechanics programmed through a separate Uniswap v4 hook
One hook can:
> burn part of the fees
> change fees depending on specific conditions
> restrict certain trades
> direct assets according to predefined rules
> create a new liquidity or distribution model
This makes Identity.md look less like a regular token launchpad and more like a combination of:
> launchpad
> smart contract studio
> AI development pipeline
> security review system
The main potential know-how is not found in the individual components
NFT gating, AI coding, GitHub Actions, multisigs and Uniswap v4 hooks already exist. What may be new is combining them into a single factory that turns an idea into a finished and verified market
And this is where the role of $IMD appears.
The factory schema specifies: "quoteSymbol": { "const": "IMD" } It uses const, not one of several possible options
This means the current architecture requires every market to be created as:
> PROJECT/ $IMD
If the router hides the intermediate operations, the user may not even notice this. But inside the system, buying a new asset would still require $IMD
For the person proposing an idea, the potential offer looks like this:
> they bring the idea
> the factory creates the specification
> AI and NFT workers write the hook
> the system runs tests and security reviews
> the multisig authorizes the deployment
> a new programmable market appears
This means the person does not necessarily need to find a Solidity developer, auditor and DevOps team independently
The NFT currently gives its holder the right to work inside the factory, but the economic reason to buy that right has not yet been revealed
Identity.md is not building a single burn hook
It is an attempt to create a factory that turns an idea into a verified programmable market.
The NFT controls who can participate in production
$IMD is intended to become the shared settlement asset across all markets
Watching closely
![LastToSign's tweet photo. Identity.md NFT turned out not to be a ticket to launch your own token
Confirmed utility for $IMD
According to a GitHub mirror discovered by @0xfinne, it is a developer credential that allows its holder to complete tasks assigned by the factory
The mirror is highly likely to be authentic. It references the original private repository Identity-md/launch-3-new, factory issue #20 and launch number 3
The first commits were made by identitymd-launch-factory[bot]. The history also contains commits and signed merge commits from Adam under his surfer77 GitHub account
How the factory works in simple terms
Imagine a factory that produces new markets:
> someone proposes an idea for a token or market.
> the Identity.md team accepts or rejects it.
> the factory divides the development process into separate tasks:
>>design the architecture
>>write the smart contract
>>write the tests
> an Identity.md NFT holder registers as a worker.
the scheduler assigns them a specific task
> the worker uses Codex, Claude or writes the code manually
> the factory checks the code, tests and security.
> a maintainer accepts the result
> a multisig authorizes the deployment
> a new PROJECT/IMD market appears
This means the NFT is not required by Codex or by someone who simply proposes an idea. It is required by the developer-worker
The NFT tells the factory:
> this GitHub developer is linked to this wallet
> they own a valid Identity.md credential
> they can be assigned a task
> the factory can accept a signed result from them
Before accepting each PR, the system checks NFT ownership through ownerOf() on Ethereum mainnet. If the worker sells the NFT, they lose the right to complete the assigned work
This is implemented directly in the code: a developer owns an NFT, registers as a worker and receives the right to complete assigned hook-development tasks
They cannot independently choose any project, write an arbitrary hook and immediately launch it
This also explains the line from Adam’s logs: waiting for the next signed milestone
It now appears that a signed milestone is most likely not a command for an autonomous economic agent, but a specific task inside the factory
For example:
> design the architecture
> write the contract
> prepare the tests
The worker receives the task, completes it and signs the result tied to an exact commit and Git tree
The code then passes through several layers of verification. This means the agent published by Adam is probably an autonomous developer-worker:
> Codex writes the hook
> the signed milestone limits it to a specific task
> the factory verifies the result
> a maintainer accepts the code
> a multisig authorizes the launch
AI is not the final product here, at least for now. It is one of the factory workers
How is this different from a regular launchpad?
A regular launchpad works roughly like this:
> enter a name and ticker
> a standard token is created
> a bonding curve or regular pool opens
> trading begins
Almost every project launches from the same template
The name, supply and image change, but the market mechanics remain similar. Identity.md is trying to build a system where each project can receive its own mechanics programmed through a separate Uniswap v4 hook
One hook can:
> burn part of the fees
> change fees depending on specific conditions
> restrict certain trades
> direct assets according to predefined rules
> create a new liquidity or distribution model
This makes Identity.md look less like a regular token launchpad and more like a combination of:
> launchpad
> smart contract studio
> AI development pipeline
> security review system
The main potential know-how is not found in the individual components
NFT gating, AI coding, GitHub Actions, multisigs and Uniswap v4 hooks already exist. What may be new is combining them into a single factory that turns an idea into a finished and verified market
And this is where the role of $IMD appears.
The factory schema specifies: "quoteSymbol": { "const": "IMD" } It uses const, not one of several possible options
This means the current architecture requires every market to be created as:
> PROJECT/ $IMD
If the router hides the intermediate operations, the user may not even notice this. But inside the system, buying a new asset would still require $IMD
For the person proposing an idea, the potential offer looks like this:
> they bring the idea
> the factory creates the specification
> AI and NFT workers write the hook
> the system runs tests and security reviews
> the multisig authorizes the deployment
> a new programmable market appears
This means the person does not necessarily need to find a Solidity developer, auditor and DevOps team independently
The NFT currently gives its holder the right to work inside the factory, but the economic reason to buy that right has not yet been revealed
Identity.md is not building a single burn hook
It is an attempt to create a factory that turns an idea into a verified programmable market.
The NFT controls who can participate in production
$IMD is intended to become the shared settlement asset across all markets
Watching closely](https://pbs.twimg.com/media/HPYA3RuXgAAAKfo.jpg)
For the first time, @surfcoderepeat “redacted agent thing” worked on its own.
After today’s update, the investment thesis for Identity.md NFTs looks at least as compelling as the thesis for $IMD.
It now seems we may have viewed Identity.md too narrowly as a single Uniswap v4 burn hook. The hook could be only the economic module of a larger autonomous AI agent system.
Adam posted: “omg my redacted agent thing just worked by itself for the first time”
And then: “it’s alive”
The published logs show:
> the identitymd_worker process running
> an agent initialized through agentclientprotocol/codex-acp
> Codex specified as the agent
> a worker pool created: agent_pool_ready agents=1
> after initialization, session_activity_age resets to near zero, indicating fresh activity inside a real agent session
But the most interesting line is: waiting for the next signed milestone
This suggests the agent may not operate continuously and without constraints. Instead, it could progress through signed tasks or checkpoints.
A possible flow:
> the agent retains a long-term goal
> receives a signed milestone
> executes the next stage
> returns to waiting for another signature
A signed milestone is not a standard feature of codex-acp.
It is more likely a custom authorization or coordination layer Adam has built on top of Codex.
The official codex-acp documentation confirms that this is more than a chatbot connection. Through ACP, Codex can work with files, terminals, MCP tools and subagents.
The experimental Goal Extension also allows an agent to retain a long-term objective and launch subsequent autonomous cycles.
However, there is no confirmation yet that identitymd_worker is using this specific feature.
What makes the timing especially interesting is that a wallet linked to the project bought two more Identity.md NFTs on the same day #1751 and #354
The wallet now holds five NFTs.
The newly purchased NFTs differ significantly in rarity, making this look more like the accumulation of functional identities for testing than a hunt for rare traits.
Only 2,000 Identity.md NFTs exist.
The most likely NFT use cases include:
> a persistent identity for an autonomous agent
> the right to create or launch an agent
> storage for settings, memory, history and reputation
> authorization of actions through the owner’s signature
> one NFT representing one agent or profile
> access to launching an autonomous market
The sequence of recent events is also worth watching.
First, Adam added to the existing mainnet IMD/WETH position:
> 33.2527 ETH
> 124,366 IMD
Then the linked wallet purchased two Identity.md NFTs.
After that, Adam reported the first autonomous activation of his agent.
This does not prove a direct connection between these events.
But the possible architecture is beginning to take shape:
> Identity.md NFT - identity
> identitymd_worker - persistent runtime
> Codex ACP - intelligence and task execution
> signed milestones - action authorization
> Uniswap v4 hook - autonomous economic module
> $IMD - potential shared asset of the system
As of today, Identity.md has an interesting but not yet fully connected stack:
> NFT identity + signed milestones + Codex agent + existing omnichain token + Uniswap v4 dynamic burn
None of these components is unique on its own.
The potentially unique part is how they may fit together.
There is still no proof that the NFT authorizes the agent, that milestones are stored onchain or that the system requires $IMD to operate.
The mainnet hook and confirmed economic integration of the NFTs have not appeared either.
Confirmation of these connections could become the main catalyst for both assets.
Is $IMD simply the first market inside the system, or will every autonomous identity need IMD to operate?
Watching closely...
The first projects on the $STONKBROKER launcher go live at 00:00 UTC
The most interesting one looks like $YARD from @TickerYardHQ
The team is currently building a bridge for stocks: Robinhood Chain → Arbitrum
powered by Chainlink CCIP
Besides the token, there will be 3,333 Yardkeeper NFTs
Through Anvil, users will be able to swap $YARD for a Yardkeeper NFT and back
The setup also includes:
> NFT staking
> fees
> NFT-backed loans
The mechanic looks similar to the NFTs from $STONKBROKER, which are already trading at roughly 13 ETH on OpenSea
Each NFT will have its own ERC-6551 account.
A max Tier 4 holder will be able to link a separate runner wallet, fund it with ETH and perform tasks:
> completing and rescuing stuck bridge operations
> DCA, limit and recurring operations
> monitoring and alerts
> treasury and issuer actions
> solver/filler tasks
Initial $YARD parameters:
> mcap: $200,000
> starting price: roughly $0.0001
If the 95% AMM / 5% loans split described in the paper remains, the rough amount of $YARD per Yardkeeper would be:
> 1,999,999,980 × 95% ÷ 3,333
> ≈ 570,058 YARD per NFT
> ≈ $57 at the starting price
Robinhood Chain currently looks like the liveliest chain, with early signs it could make a run at flipping Solana
Watching how this develops
What is hidden inside the $STONKBROKER launchpad frontend from @realstonkbroker
This comes from StonkBrokers’ public JS modules, ABI, API and docs. Some mechanics have already been officially described, while others currently exist only in frontend scaffolds
1. Opening Bell creates automatic market demand
A portion of the fee from every bonding curve trade goes into the public Opening Bell fund. The more fees a token generates, the higher its probability of being selected
VRNG determines the timing of the draw and selects the winning token. The entire accumulated fund then buys the selected token on the market in a single transaction
In the frontend version I found, 16.5% of the trading fee was allocated to the fund. During the first 24 hours, it was also funded by higher token creation fees
The final values will need to be verified after launch
> monitor the size of the fund and the tokens generating the highest fee volume
> if a low-liquidity token is selected, a purchase using the entire fund could cause a sharp pump
> however, it is impossible to know the winner or the exact timing of the buyback in advance
2. Graduation can create demand for a second asset
The launcher supports bonding curves, fixed sales and configurable parameters
The standard graduation threshold is listed as four units of the base asset, although the specific conditions may differ for each launch. Once the sale is complete, a Uniswap V3 pool is created
For Special Projects, additional liquidity paired with $STONKBROKER has been officially announced and is added when the launch is finalized
The frontend scaffold also included an option to direct 10%, 25%, 33% or 50% of the raised ETH toward buying a second asset
The final implementation of this feature still needs to be confirmed onchain
> monitor projects approaching graduation and check which second asset has been selected
> its automatic purchase could create short-term demand and increased volatility
3. Creator Buyback & Burn is included in the code
In one of the frontend scaffolds, the creator could direct their share of the fees into a separate vault.
The vault was intended to buy the project token and send the purchased tokens to a burn address
This could potentially create a recurring source of demand while reducing the supply
However, this feature has not yet been confirmed in the current documentation, and the address of the corresponding mainnet contract has not been published
> consider this mechanism only after a real vault appears
> verify its address, accumulated balance and buyback transactions
@MemeIndexer @surfcoderepeat overall this looks right
the NFT seems to grant the right to do the work, but not to deploy independently
What is hidden inside the $STONKBROKER launchpad frontend from @realstonkbroker
This comes from StonkBrokers’ public JS modules, ABI, API and docs. Some mechanics have already been officially described, while others currently exist only in frontend scaffolds
1. Opening Bell creates automatic market demand
A portion of the fee from every bonding curve trade goes into the public Opening Bell fund. The more fees a token generates, the higher its probability of being selected
VRNG determines the timing of the draw and selects the winning token. The entire accumulated fund then buys the selected token on the market in a single transaction
In the frontend version I found, 16.5% of the trading fee was allocated to the fund. During the first 24 hours, it was also funded by higher token creation fees
The final values will need to be verified after launch
> monitor the size of the fund and the tokens generating the highest fee volume
> if a low-liquidity token is selected, a purchase using the entire fund could cause a sharp pump
> however, it is impossible to know the winner or the exact timing of the buyback in advance
2. Graduation can create demand for a second asset
The launcher supports bonding curves, fixed sales and configurable parameters
The standard graduation threshold is listed as four units of the base asset, although the specific conditions may differ for each launch. Once the sale is complete, a Uniswap V3 pool is created
For Special Projects, additional liquidity paired with $STONKBROKER has been officially announced and is added when the launch is finalized
The frontend scaffold also included an option to direct 10%, 25%, 33% or 50% of the raised ETH toward buying a second asset
The final implementation of this feature still needs to be confirmed onchain
> monitor projects approaching graduation and check which second asset has been selected
> its automatic purchase could create short-term demand and increased volatility
3. Creator Buyback & Burn is included in the code
In one of the frontend scaffolds, the creator could direct their share of the fees into a separate vault.
The vault was intended to buy the project token and send the purchased tokens to a burn address
This could potentially create a recurring source of demand while reducing the supply
However, this feature has not yet been confirmed in the current documentation, and the address of the corresponding mainnet contract has not been published
> consider this mechanism only after a real vault appears
> verify its address, accumulated balance and buyback transactions
@DefiIgnas tradfi is officially more bullish than ct
For the first time, @surfcoderepeat “redacted agent thing” worked on its own.
After today’s update, the investment thesis for Identity.md NFTs looks at least as compelling as the thesis for $IMD.
It now seems we may have viewed Identity.md too narrowly as a single Uniswap v4 burn hook. The hook could be only the economic module of a larger autonomous AI agent system.
Adam posted: “omg my redacted agent thing just worked by itself for the first time”
And then: “it’s alive”
The published logs show:
> the identitymd_worker process running
> an agent initialized through agentclientprotocol/codex-acp
> Codex specified as the agent
> a worker pool created: agent_pool_ready agents=1
> after initialization, session_activity_age resets to near zero, indicating fresh activity inside a real agent session
But the most interesting line is: waiting for the next signed milestone
This suggests the agent may not operate continuously and without constraints. Instead, it could progress through signed tasks or checkpoints.
A possible flow:
> the agent retains a long-term goal
> receives a signed milestone
> executes the next stage
> returns to waiting for another signature
A signed milestone is not a standard feature of codex-acp.
It is more likely a custom authorization or coordination layer Adam has built on top of Codex.
The official codex-acp documentation confirms that this is more than a chatbot connection. Through ACP, Codex can work with files, terminals, MCP tools and subagents.
The experimental Goal Extension also allows an agent to retain a long-term objective and launch subsequent autonomous cycles.
However, there is no confirmation yet that identitymd_worker is using this specific feature.
What makes the timing especially interesting is that a wallet linked to the project bought two more Identity.md NFTs on the same day #1751 and #354
The wallet now holds five NFTs.
The newly purchased NFTs differ significantly in rarity, making this look more like the accumulation of functional identities for testing than a hunt for rare traits.
Only 2,000 Identity.md NFTs exist.
The most likely NFT use cases include:
> a persistent identity for an autonomous agent
> the right to create or launch an agent
> storage for settings, memory, history and reputation
> authorization of actions through the owner’s signature
> one NFT representing one agent or profile
> access to launching an autonomous market
The sequence of recent events is also worth watching.
First, Adam added to the existing mainnet IMD/WETH position:
> 33.2527 ETH
> 124,366 IMD
Then the linked wallet purchased two Identity.md NFTs.
After that, Adam reported the first autonomous activation of his agent.
This does not prove a direct connection between these events.
But the possible architecture is beginning to take shape:
> Identity.md NFT - identity
> identitymd_worker - persistent runtime
> Codex ACP - intelligence and task execution
> signed milestones - action authorization
> Uniswap v4 hook - autonomous economic module
> $IMD - potential shared asset of the system
As of today, Identity.md has an interesting but not yet fully connected stack:
> NFT identity + signed milestones + Codex agent + existing omnichain token + Uniswap v4 dynamic burn
None of these components is unique on its own.
The potentially unique part is how they may fit together.
There is still no proof that the NFT authorizes the agent, that milestones are stored onchain or that the system requires $IMD to operate.
The mainnet hook and confirmed economic integration of the NFTs have not appeared either.
Confirmation of these connections could become the main catalyst for both assets.
Is $IMD simply the first market inside the system, or will every autonomous identity need IMD to operate?
Watching closely...
While the $IMD token is trading sideways, the Identity MD NFTs have repriced from 0.015 $ETH to roughly 0.2$ ETH in just 10 days.
If the bet here is on future utility, sweeping the floor is the logical play. Paying a premium for rarity right now is pure speculation.
> the contract explicitly includes univ4Hook and univ4Pool fields, confirming the direct link to Adam's future system. But right now, both are zero addresses.
> the ability to write an identity is disabled: identityAllowed = false.
> all 2,000 NFTs currently share the exact same baseline: Memory State: Unwritten and Memory Lock: Open.
> there are zero mechanics in the current code that provide additional utility for rare traits or low token IDs.
Rarity on OpenSea is driven by combinations of fairly common traits. True 1/1 unique traits are almost non-existent.
@surfcoderepeat especially hard to explain that balance to my five-year-old son and my daughter, who want to play with me every minute they’re awake
@0xpussyjuice @apex_ether that’s kind of the point- the real product is the fight for the fee stream
ENDGAME turned an LP position into a lifetime cash flow that can belong to only one address.
Dev @apex_ether launched the $FEES token and a single permanent Uniswap v4 LP position on Robinhood Chain.
The entire 1B token supply was placed into one-sided liquidity.
There is no team allocation, and the code does not allow the LP position to be removed.
Every trade pays a 1.5% fee:
> 0.5% goes to the developer
> 1% accumulates for the future winner
But there will only be one winner.
A purchase above the current floor resets a four-hour timer and makes the buyer’s address the new leader.
After every qualifying purchase, the floor increases by another 0.3%.
If four hours pass without another qualifying purchase, the last leader receives:
> the entire accumulated pot in ETH and $FEES
> 1% of every future trade in the pool
> that cash flow forever
The most unusual part is that leadership is tied to the address, not its token balance.
An address can buy the required amount, become the leader, sell all the $FEES it received and still retain the right to win until another address makes a qualifying purchase.
Current stats:
> 1,217 qualifying purchases
> only 79 unique addresses
> floor increased from 0.01 to 0.383 ETH
> pot reached 5.67 ETH + 39.38M $FEES
> nominal pot value is around $15.4K at roughly $115K FDV
But regular $FEES holders do not receive any fees.
The token may be held by hundreds of wallets.
The lifetime cash flow generated by its primary market will belong to one
Throwing my V4 hook in the ring.
ENDGAME is my take on fomo3d as a hook. last-buyer-wins.
Buy $FEES and the countdown begins. If nobody buys after you before the timer hits zero, you win the pot funded by the 1% swap fee.
Every qualifying buy resets the 4-hour clock, takes the lead, and raises the floor for the next buyer.
Powered by a @Uniswap v4 hook.
Deployed on @RobinhoodCrypto Chain.
CA: 0x77948655831f48aa17AC85233E6c921F7eF7bb2e
https://t.co/LqwRhNV1lb
@lmrankhan everything is just getting started...
Last Seen Users on Sotwe
gabugabu
Seen from Peru
Douyin Girl
yamada kyoto
Seen from Switzerland
สาวใหญ่ แอบเสียวในครอบครัว
Seen from Thailand
Hakkı Köyden
Seen from Turkey
+18 İzmir teşhir paylaşım tanışma.👀
Seen from Turkey
Marlys Kitsmiller
Seen from Germany
Matthew
Seen from Indonesia
Bikin Klimaks
Seen from Indonesia
Cepol jilbab
Seen from Indonesia
Most Popular Users
Elon Musk
@elonmusk
241.3M followers
Barack Obama
@barackobama
119.1M followers
Cristiano Ronaldo
@cristiano
113.1M followers
Donald J. Trump
@realdonaldtrump
111.8M followers
Narendra Modi
@narendramodi
107.1M followers
Rihanna
@rihanna
98.4M followers
NASA
@nasa
92.3M followers
Justin Bieber
@justinbieber
91.5M followers
KATY PERRY
@katyperry
89.2M followers
Taylor Swift
@taylorswift13
83.1M followers
Lady Gaga
@ladygaga
74.6M followers
Virat Kohli
@imvkohli
72.1M followers
Kim Kardashian
@kimkardashian
70.5M followers
YouTube
@youtube
68.8M followers
Neymar Jr
@neymarjr
65.1M followers
Bill Gates
@billgates
64.7M followers
The Ellen Show
@theellenshow
62.4M followers
Selena Gomez
@selenagomez
62.3M followers
CNN
@cnn
61.8M followers
X
@x
60.8M followers