# Overview **Simulacrum** is a new platform utilizing Existential Attestations of External Media to create a Synthetic Blockchain. Public profiles on Social Media provide some very interesting guarantees. It is very easy for a group of observers to come to an agreement on what was said at a specific point of time on a specific profile on a specific social network. If you can get a sufficient number of participants to agree that this information happened on a specific network at a specific time, you can provide this to an indexer, which can organize it into blocks. This was part of the core innovation of Solana, which utilizes [Proof Of History](https://solana.com/news/proof-of-history) to order transactions. Likewise, with [Ordinal Theory](https://docs.ordinals.com/) we saw how a MetaProtocol can be built as a hologram on top of a ledger, where the indexers are able to come to agreement on the state of the protocol. By defining a consistent syntax for inscribing satoshis, metaprotocols were able to be developed that could be indexed by a third party, and oracles would enable these assets to be traded in peer to peer marketplaces, perpetuals applications, PSBT, and more. By combining these concepts, we are able to define a MetaProtocol that is able to live on top of any blockchain, where an oracle network is able to provide attestations of publicly verifiable information, which in turn enable the protocol to take actions on behalf of users. A user can broadcast their transactions on a social media platform rather than utilizing a wallet, and as long as an indexer is able to get attestations of the transaction, it can be pushed and take action for that user onchain. These transactions are ordered into a synthetic blockchain, and are committed to update the state of an established ledger. Therefore the synthetic blockchain is able to interact with its base layer. By aggregating diverse social media sources, we are able to create a platform that allows users to manage their identity across multiple social networks. This removes the need for a wallet, as a user can broadcast their intents on any supported platform, and it is translated into a Command and executed.

Brought to you by Empyreal

# Existential Attestation **Existential Attestations** means an event is publicly verifiable by a quorum of [Validators](https://docs.simulacrum.network/existential-attestation/validators). If you can verify the **Identity, Timeframe** and **Content** of some public data, it can be confirmed by multiple validators, and it conforms to the protocol standard, this data can be treated as an intent from a user which can be pushed onchain and utilized as part of a MetaProtocol. The attestations are votes by validator to accept that an event happened. In the context of The Simulacrum, they are an agreement that information from one of the current [Sources](https://docs.simulacrum.network/synthetic-blockchain/organization/indexer/sources) fits the criteria for inclusion in the [Synthetic Blockchain](https://docs.simulacrum.network/synthetic-blockchain). This is done by a quorum of validators reaching consensus on the event. For example, if a user were to post on their twitter: ``` #simulacrum #launch MyNewToken ``` This information would be able to be: 1. Indexed: Any indexer looking for valid Simulacrum Commands would detect this post, and include it as a pending transaction 2. Attestations. The indexer would request attestations from the validator network to verify its existence. 3. Relayed. It could be trustlessly relayed to the Synthetic Blockchain via a standard transaction 4. Mempool. Submitted to the synthetic mempool on top of the base chain for inclusion in the next block 5. Executed. The user's command would be executed once it is included in a block. 6. Effects. Any additional effects would be created for the user intent, including external actions that validators can verify. For example, a limit order to sell 1 TKN for 0.01 ETH would be created as an effect with expiry in 24 hours. Anyone could provide 0.01 ETH to claim the 1 TKN bounty. # Validators "While any Fair Witness would do, the prestige of Cavendish was such that a lawyer was hardly necessary" -Robert Heinlein Validators are the entities that are able to provide attestations for the content of a specific piece of media. In this regard, they are merely a [**Fair Witness**](https://en.wikipedia.org/wiki/Stranger_in_a_Strange_Land#Fair_Witness) that are able to provide verification that a specific event exists on a specific platform with specific metadata. For example, they could attest that a user made a tweet saying "hello world", that this tweet currently has 10 likes and 5 retweets, and the tweet was made at 1:25pm on July 8th, 2024. The strength of this is, as multiple validators are able to come to consensus on the occurrence of an event, the risk to a user is significantly decreased. Instead of relying on a centralized service to execute on a user's behalf, a quorum of validators can rapidly come to consensus on the existence of an event, and this can be proven onchain and used to execute an action. Initially, we will rely on a 2 of 3 quorum of validators to attest the existence of an event on a source. We will increase the decentralization and security of this validator network over time, as we prove the viability of this solution. [
](https://docs.simulacrum.network/existential-attestation) # Synthetic Blockchain The Synthetic Blockchain is a blockchain-style structure built on top of an existing blockchain, used to capture and organize the commands from different sources. The Blockchain enables ordering the commands into blocks, which are executed based on priority and/or timestamp. The reason that it is considered synthetic is it is entirely created on top of an existing blockchain as a data structure. This facilitates the unification of multiple sources, and simplifies the architecture. It also allows for the protocol to be indexed separately from the underlying blockchain. # Organization The Synthetic Blockchain is composed of a few main components, not unlike a typical blockchain. There needs to be a place for transactions to be staged, a way for blocks to be finalized, a canonical format for a Command to be accepted onchain, and actions that are triggered by these commands. These components are: * [Indexer](https://docs.simulacrum.network/synthetic-blockchain/organization/indexer): The mechanism that adds new commands to the mempool * [Mempool](https://docs.simulacrum.network/synthetic-blockchain/organization/mempool): Where commands are staged until they are executed * [Blocks](https://docs.simulacrum.network/synthetic-blockchain/organization/blocks): The collection of commands executed in unison * [Commands](https://docs.simulacrum.network/synthetic-blockchain/organization/commands): The format for a user submitted request, analogous to a Transaction on standard blockchains * [Effects](https://docs.simulacrum.network/synthetic-blockchain/organization/effects): Requirements that require asynchronous actions to take place. Intents that can not be handled within the execution of the Command. # Indexer Indexers are used to subscribe to updates from [Sources](https://docs.simulacrum.network/synthetic-blockchain/organization/indexer/sources), and use that information to publish the information onchain. Indexers are rewarded for providing valid Commands in the form of points. An indexer is not able to publish a transaction directly, as they must first get [Existential Attestation](https://docs.simulacrum.network/existential-attestation) from an Oracle. # Sources ## Sources Sources are where commands are originated. They can be any platform that can be publicly verified, and gives the validator network the ability to confirm that a statement was made by a specific entity. For example, a Source could be a message board, a personally owned website, a social media profile, etc. When determining sources, it is important to consider a few concepts: #### Identity You must be able to confirm the identity of the person making the content #### Content The content must be publicly verifiable, so that a quorum of validators can verify the content #### Consistency Validators must be able to verify the content and get identical results. So they must agree on all metadata associated with any source media. # X ### Tweets A tweet is a public statement made in short form on twitter. In this regard, it is very similar to broadcasting a transaction to the mempool. When a tweet is made that's initial hashtag indicates it is part of a supported metaprotocol, this is indexed by our subscribers. Our oracles are then able to get validation of the tweet from the Validators and push this onchain. #### Format An **X Command** is defined with a specific format to simplify the parsing of the command. The first line must contain the MetaProtocol, and Module, with optional hashtags for its Action, Version and/or any #Decorators. A Version is indicated by the third hashtag starting with a V, followed by a number. If the number is larger than the latest version, it will be an invalid command. If no version is provided, the latest version will be used by default. The following lines will contain arguments, and can be packed on a single line or newline delimited. Lastly, keyword args are provided by a **keyword**, followed by colon (**:**), followed by the argument You can include `---` in the tweet to indicate everything below this point is a comment. ``` #testprotocol #testmodule #testfunc #v1 #testing really long first arg second arg third arg name: MY NAME favorite color: RED favorite food: Ramen --- This is what will be provided to the action when it is called ``` `#testprotocol` is the MetaProtocol `#testmodule` is the Module `#testfunc` is the Action `#v1` is the Version `#testing` is a decorator Then for our arguments we have `really long first arg, second arg, third arg` And our keyword args are: * name: MY NAME * favorite color: RED * favorite food: Ramen You can think of this as a function execution like: ``` # this emulates loading a specific version of a function (V1) # with a specific decoration (test) from testprotocol.testmodule import test_testfunV1 as testfunc # this is the additional context from the command injected into the execution context = { 'owner_id': sender_ID, 'origin': 'X', 'timestamp': time_sent, 'references': [], } # This is what will be provided to the action when it is called testfunc( "really long first arg", "second arg", "third arg", name="MY NAME", favorite_color="RED", favorite_food="Ramen", context=context, ) ``` ### Loading a Tweet Anyone can push any tweet onchain once it has gotten validator confirmation. We have created simplified tooling for a user to commit a tweet onchain using our cli: ``` thedrops x tweet ``` ### List A list is a collection of twitter accounts, usually organized by a cohesive theme. These lists can be used to create a group for things like airdrops. If a user is planning a launch and wants to airdrop a percentage of supply to a group of users, a twitter list is a simple way to create this grouping of users. A list can only have up to 100 members, otherwise the additional members will be ignored. It must be public so the validators can verify its members. ``` thedrops x list ``` # Telegram Telegram is best suited for integrations with Large Language Models (LLMs). We feel there is a great opportunity to utilize the simplicity of command execution on Simulacrum to enable LLM's that can easily capture and execute user intents. # TBD We are exploring additional sources, and will add another one pending community feedback. Some ideas for additional sources are: * Bitcoin Inscriptions * Additional Social Networks * Message Boards (ie Reddit or 4Chan) # Blocks Commands are organized into Blocks. This simplifies the process of aggregating multiple sources, and makes it so command execution happens more fairly. If there are 3 or 4 different sources competing for prioritization, instead of handling commands as they are submitted, the commands are placed into the [Mempool](https://docs.simulacrum.network/synthetic-blockchain/organization/mempool) and a block is finalized, allowing them to be ordered by both time and tips for prioritization. # Mempool The mempool allows for the ordering of transactions from various sources into [Blocks](https://docs.simulacrum.network/synthetic-blockchain/organization/blocks). This allows for the mempool to create prioritizations based on "tips", which will prioritize command execution. # Commands A command is the core building block of The Simulacra. A command is similar to a traditional blockchain transaction. A command is structured with some consistent fields. A command is structured: ``` struct Command { bytes32 id; // Identifier from the source uint256 chainId; // chainId, if blank can be executed on any chain uint256 nonce; // nonce to enable cancellation of commands uint256 value; // amount of NATIVE // wallet info bytes32 ownerId; // command owner's identifier bytes32 namespace; // namespace of the wallet (used for source) uint16 walletIndex; // defaults to 0 // command definition bytes32 metaprotocol; bytes32[] modifiers; // additional command indicators Reference[] references; // additional information about a referenced entity string[] args; Field[] kwargs; // additional data uint64 timestamp; // timestamp with ms uint256 gas; uint256 bribe; // bribe for priority in mempool bytes32 hash; // maybe we don't need this // validate the execution CommandStatus status; uint256 gasUsed; } enum CommandStatus { PENDING, SUCCESS, FAILURE, CANCELLED } struct Field { bytes32 key; string value; } struct Reference { bytes32 source; // This simplifies handling of the reference bytes32 identifier; // globally unique identifier } ``` # Wallet ### Owner ID The owner ID identifiers a user as a unique identifier. On twitter, this is your user ID. It is constrained to 32 bytes. ### Namespace A namespace is used to identify a command as belonging to a specific source/environment. Without the namespace, there could be collisions in the ownerId. By making wallets uniquely registered to a specific namespace, a user can have multiple wallets. For example, the Twitter source has the identifier "X". ### Wallet Index This allows for an Owner ID on a specific namespace to have multiple wallets. By default, this is assumed to be index 0 and is an optional argument. # Metaprotocols Metaprotocols are the identifiers used to route a command. Each metaprotocol has its own logic handling, and it allows a user to execute a diverse array of solutions. For example, the token metaprotocol exposes `transfer`, `transferFrom` and `approve` actions as modifiers. Application specific metaprotocols can have more advanced logic, such as the `tipping` metaprotocol which allows for actions like "swap and tip", where a single command executes 2 actions. A Metaprotocol should be designed as an isolated protocol that executes a smart contract call to solve a specific user intent. # Modifiers A modifier is a way to indicate that the Command should be modified for a special case. This is similar to a decorator in programming languages, where a decorator is a function that modifies another function or method. This allows a MetaProtocol to divide actions into logical groups, such as perps, tokens or bridging. Without this, every metaprotocol would need to have a singular focus. A module on Simulacrum is similar to a module in a software project, where each applications has one or more modules. For example, a metaprotocol might have two modifiers: ``` #metaprotocol #modifier1 #modifier2 0.01 ETH ``` These modifiers could be something like: `#token` `#launch` and this would tell the metaprotocol that the command args/kwargs are to be used to launch a token. Likewise, you could provide the modifiers `#nft` `#launch` and the metaprotocol would be able to handle this differently. # Arguments These are the arguments provided to the function, in addition to the user information. # Keyword Arguments These are the keyword arguments provided to the function, in addition to the user information. Keyword args are useful if you want the user to explicitly provide the field and argument to the Command. # Effects **Effects** are any side effects that need to be handled asynchronously. For example if a user provides a bounty for the execution of a specific action, the bounty will be placed into an Effect that is released as soon as someone executes the Effect and provides the required proof of execution necessary to release the funds. This can be something like a limit order, where an **Effect** is created with some expiry to buy an asset at a specific price, and the Effect is only finalized when the limit order is executed. More to follow on Effects, but they greatly expand the usability of the protocol beyond a single chain. ``` struct Effect { bytes32 id; uint256 index; bytes32 targetChain; bytes32 ownerId; bytes32 descriptor; // describes the type of the effect bytes args; bytes bounty; EffectStatus status; } enum EffectStatus { PENDING, COMPLETED, CANCELLED } ``` # Roadmap The general structure of Commands and Blocks is designed to be flexible, but immutable. There are additional fields reserved for future iterations of the protocol in the event of upgrades. Likewise, there is the ability to "fork" the chain, somewhat analogous to a fork on a blockchain like Ethereum, where the chain can introduce new features. Initially, the overall structure will be managed by the Empyreal team. Once the project has stabilized and we have made it through our initial iterations, we will be able to migrate this to a more decentralized solution where there is governance managing the upgrades to the protocol. A standard for SIPs (Simulacrum Improvement Proposals) will be released at a later point in time. #### Potential Upgrades * Adding gas (a fee for committing a transaction to the chain) * Rewards for mining/executing blocks * Omnichain transaction handling [
](https://docs.simulacrum.network/synthetic-blockchain/organization/effects) # Metaprotocols A MetaProtocol is a protocol built on top of the synthetic blockchain, that can be organized into a set of modules and/or commands. The first MetaProtocol will be [The Drops](https://docs.simulacrum.network/metaprotocols/the-drops), but additional metaprotocols are being developed. We will start by only allowing whitelisted protocols to be introduced, but eventually the registering of protocols will be permissionless. A MetaProtocol has a variety of customizations within the Synthetic Blockchain. For example, a MetaProtocol can decide to only accept [Commands](https://docs.simulacrum.network/synthetic-blockchain/organization/commands)from certain sources. This helps to limit risks associated with introducing experimental sources at a later point in time. The benefit of building a MetaProtocol on top of Simulacrum is, it allows for users to focus on implementation logic for arbitrary [Commands](https://docs.simulacrum.network/synthetic-blockchain/organization/commands). Developers can applications that leverage any or all Sources that are supported by The Simulacrum. For example, once a telegram source is introduced, we will be able to allow applications to be developed (such as trading bots) where a user can use a platform like Twitter or Telegram, and no longer has to trust Centralized Execution. # The Drops *This is in progress, most of the attention in documentation is focused on the base protocol* The Drops is a metaprotocol built on top of Simulacrum, that functions as an intents platform. It is initially launching with support for X (Twitter) as a source. The Drops enables users to deploy and manage their own tokens, as well as interact with other tokens. This is able to be done entirely from X, without needing to setup a wallet. The Drops frontend simplifies these interactions for the user, helping them navigate the existing metaprotocol. Additional, customized frontends are able to be built on top of The Drops as all data is fully onchain. # Modules The Drops Metaprotocol will consist of multiple Modules. [
](https://docs.simulacrum.network/metaprotocols/the-drops) # Tokens **IN PROGRESS.** The first Module will be a token deployment and trading module. It will focus on enabling users to launch and trade their own tokens. # Token Deployment **Reserve** **Config** **Launch** # Airdrops # Trading # Liquidity Liquidity will be managed using a bonding curve. # Trading **COMING SOON.** A module for trading established tokens. # Vaults Coming soon. # Points Points are used for accountability on TheDrops. They will be awarded for submitting valid commands, mining a block, and all actions that interact directly with The Drops. These Points initially have no cash value, but are used to claim rewards in the form of protocol revenue. A percentage (TBD) of protocol Revenue will be allocated to points holders each month. # MiniGame (TBD) # Sportsbook (TBD) # Lottery (TBD) # Revenue The Simulacrum will be able to generate revenue once it reaches a state of maturity. There is the potential to charge gas fees when including a transaction in a block, and the validator network will be able to generate revenue for validating transactions. Additionally, charges can be made to teams building MetaProtocols. # $EMP Staking In exchange for protocol maintanence, development and growth, 50% of protocol revenue will be allocated to Empyreal, to be distributed to staked tokenholders. # Fair Witness API The offchain API provides a way for builders to fetch [Existential Attestation](/existential-attestation) in the format necessary to be pushed onchain. The ApI can be accessed via [https://fairwitness.empyrealsdk.com](https://fairwitness.empyrealsdk.com/)/ {% openapi src="/files/irI1tj6CM7R2BFGvxyWY" path="/user" method="post" %} [openapi.json](https://3147612106-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRTDiCNWNhWcdy6MJQR2X%2Fuploads%2FEluP1CMIjVqnPA5gkGA2%2Fopenapi.json?alt=media\&token=4bec0bf9-8079-496c-945a-49661f4bd5a5) {% endopenapi %} {% openapi src="/files/irI1tj6CM7R2BFGvxyWY" path="/tweet" method="post" %} [openapi.json](https://3147612106-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FRTDiCNWNhWcdy6MJQR2X%2Fuploads%2FEluP1CMIjVqnPA5gkGA2%2Fopenapi.json?alt=media\&token=4bec0bf9-8079-496c-945a-49661f4bd5a5) {% endopenapi %} # Integration Here's an example of how a bounty can be established that will be paid out when sufficient replies to a user's twitter account are met by a user. ``` /* * This contract is to demonstrate some basic features of the fair witness. * In this example, a bounty is paid to a recipient once a single user has * replied to a set number of tweets. So if the score is 20, once a user has * replied 20 times, the bounty is paid. */ contract ReplyBounty { // user to create the bounty for bytes32 targetUser; // amount of the bounty uint256 bounty; IAttestationOracle public oracle; // who will receive the bounty address payable recipient; bytes32 constant _dataType = "FAIR_WITNESS_TWEET_v0.1"; mapping(bytes32 => mapping(bytes32 => bool)) private replies; mapping(bytes32 => bool) private validConversation; mapping(bytes32 => uint256) private userReplyScore; uint256 targetScore; constructor(bytes32 _targetUserId, IAttestationOracle _oracle, address payable _recipient, uint256 _targetScore) payable { targetUserId = _targetUserId; oracle = _oracle; bounty = msg.value; recipient = _recipient; targetScore = _targetScore; } function pushUserTweet(TweetLib.Tweet memory tweet, bytes memory attestation) external { require(oracle.verify(_dataType, tweet.asBytes(), attestation), "must be verified by oracle"); // TODO: push to conversation mapping require(tweet.userId == targetUser); validConverstion[tweet.conversationId] = true; } function pushReply(TweetLib.Tweet memory tweet, bytes memory attestation) external { require(oracle.verify(_dataType, tweet.asBytes(), verificationData), "must be verified by oracle"); require(validConversation[tweet.conversationId]); require(replies[tweet.userId][tweet.conversationId] == false, "tweet already indexed"); replies[tweet.userId][tweet.conversationId] = true; userReplyScore += 1; if (getScore(tweet.userId) > targetScore) { deliverBounty(); } } function getScore(bytes32 userId) external view returns(uint256) { return userReplyScore[userId]; } function deliverBounty() public { recipient.call{value: bounty}(""); } } ``` # FAQ ### What is Simulacrum? A simulacrum is an imitation or representation of a person or thing. Similar to how a caricature exaggerates certain features to create a recognizable yet unrealistic portrayal, a simulacrum borrows elements of the real thing but takes liberties in its implementation and representation. In the context of the Simulacrum network, it represents a blockchain without being constrained by traditional formalities. It emulates blockchain elements within an easily consumable on-chain application rather than a decentralized global network. This approach allows people to familiarize themselves with core blockchain concepts in a simplified environment—essentially, it's like a blockchain on easy mode. Simulacrum is a platform that connects off-chain identities from various data sources to a blockchain environment. It enables developers to build protocols that easily integrate with these sources, bridging the gap between off-chain data and on-chain applications. ### Can you explain this concept in simpler terms? Think of it as a bridge between the traditional internet and blockchain technology. It allows you to link your regular online accounts (like social media profiles or email) to a blockchain-based system. This makes it easier for people to interact with blockchain applications without needing to fully understand all the technical details. For developers, it provides tools to create blockchain-based applications that can easily access and use information from these familiar online sources. This simplifies the process of building blockchain projects that interact with real-world data and identities. ### How does Simulacrum enable AI agents and LLM-based use cases? By creating an entry point and a limited set of actions with a consistent format, Simulacrum allows AI agents to submit their intents on-chain in their desired format. Parsing these intents on-chain enables agents to communicate in a domain-specific language closer to natural language, making it easier to parse and handle on-chain. ### Is my wallet address public? Currently, wallet addresses are generated deterministically for each Twitter user, meaning they remain the same given specific inputs. Essentially, your Twitter profile serves as your wallet. The actual address is less relevant since all actions are conducted through Twitter. ### Why use a public wallet linked to my Twitter account? Having your main Twitter wallet as a public wallet makes it easy to airdrop tokens to anyone on Twitter or perform common actions. It provides a fully permissionless and entirely publicly verifiable wallet system. ### What can I currently do on Simulacrum? Currently, in the beta version, you can transfer, buy, and sell tokens, as well as mint Basenames. We envision a future where anything on-chain is possible and more accessible through Simulacrum. ### How do I use Simulacrum? Text before the first hashtag is ignored, and you can post your commands on a single line. For example: `#simu #token #transfer 0x55c4985F75904D41515F9Ad67F8395f9d88FCA36 @Xusername 1000000000000000` Here, #simu is short for #simulacrum (both work). You can also use a ticker symbol instead of a contract address: `#simulacrum #token #transfer ETH @Xusername 1000000000000000` To register a Basename: `#simulacrum #basenames #register MyFirstBasename @Xusername` ### Is using a public wallet linked to my Twitter account secure? Additional security measures are planned for future updates. The main goal is to have a wallet that anyone can transfer to, as long as you have a Twitter account. We plan to create different account types, allowing you to transfer from your social wallet to a private wallet or use a wallet that authenticates with a passkey. We will develop a heightened security wallet from which you can transfer funds. In the meantime, we recommend using two-factor authentication with your Twitter account. ### How can I hide my activity? If you wish to keep your activity private for now, you can use an alternate Twitter profile. ### How and where are the keys stored? To answer this question, it's important to understand the key differences between traditional Externally Owned Accounts (EOAs) and Contract Accounts in Ethereum. #### Externally Owned Accounts (EOAs) * **Definition:** An EOA is a basic Ethereum account controlled by a private key and does not contain any executable code. * **Control Mechanism:** Ownership and control depend entirely on possessing the private key. * **Functionality:** * Can send transactions, transfer Ether, and initiate smart contract functions. * Cannot execute code autonomously or have complex logic. * **Security:** If the private key is lost or compromised, access to the account and its assets is irretrievably lost. #### Smart Contract Wallets with Account Abstraction (ERC-4337) * **Definition:** A smart contract wallet is a contract account containing code to manage assets and execute transactions. ERC-4337 introduces account abstraction, allowing these wallets to handle user operations without relying on EOAs. * **Control Mechanism:** Ownership can be defined by customizable logic within the smart contract, such as multi-signature schemes, social recovery mechanisms, or biometric authentication. * **Functionality:** * Can execute complex operations autonomously based on predefined rules. * Supports features like batched transactions, transaction fee payment in ERC-20 tokens, and more flexible transaction validation. * **Security:** Enhanced security features like multi-factor authentication, spending limits, and recovery options can be built into the wallet. The **default Simulacrum wallet** is a **Smart Contract Wallet** with **Account Abstraction** (ERC-4337) on **Base** to provide the best user experience and security. Private Keys are not exportable here, as they do not exist; instead, this wallet serves as a frictionless starting point—a public-facing account tailored for interactions on X (formerly Twitter) through Simulacrum. Users who want additional privacy can move funds from their Simulacrum Smart Contract Wallet to personal wallets (EOAs) that exist inside the Enclave. These private wallets are securely accessed using Passkeys through Sapphire's privacy-preserving technology. (Coming Soon). In essence, we provide two wallet options catering to different user needs and skill levels, ensuring flexibility and adaptability based on preferences and use cases. ### How can I track what I have in my Simulacrum wallet? Our web UI will feature a dashboard (Coming soon). In the meantime, you can always check the block explorer (Currently basescan.org). Find your wallet address by using the following command: `@simulacrumai`\ `wallet` ### Are there any plans to expand beyond Twitter? Yes, Twitter was chosen for its low-friction implementation to showcase this technology to a broader audience, but it is not the end goal. We plan to expand to other platforms in the future. # Guides At time of launch, Simulacrum lets you perform onchain actions directly from X (Twitter) using simple commands. Each command starts with a hashtag and follows a specific format. **Coming soon:** LLM integration, so you can use natural language to execute onchain actions! ### Quick Start Example ``` #simu #tip 0.0002 ETH @username ``` This command tips 0.0002 ETH to the specified user. **All commands must begin with #simu** ### Available Commands #### 📝 Attest Put a simple message on-chain (fixed length). 
#simu #attest [your message]
#### 📛 Register Basename Register your unique Basename on-chain. ``` #simu #basenames #register [basename] [@username] ``` * `@username` is optional. If omitted, mints to your wallet Example:\ `#simulacrum #basenames #register simulacrum1`
#### 💱 Swap Tokens Trade between tokens. Keep it simple - no additional text after the command. Basic commands: ``` #simu #buy [amount in eth] [contract address] #simu #sell [Percentage] [Contract Address] ``` e.g. #simu #sell 3% 0x161e113B8E9BBAEfb846F73F31624F6f9607bd44 would sell 3% of your $SIMMI balance
## 💸 Tip Send tokens to another user. 
#simu #tip [amount] [token] [@recipient]
* `token` is optional (defaults to ETH) Example: `#simu #tip 0.0002 @username` * `recipient` can be a twitter username, or a wallet address
#### 🔄 Token Operations **Transfer tokens:** ``` #simu #token #transfer [token] [@recipient] [amount] ``` * `token` is optional (defaults to ETH)
**Approve token spending:** ``` #simu #token #approve [token] [spender] [amount] ``` * Allows another address to spend tokens on your behalf * Use this before certain DeFi operations **Burn tokens:** ``` #simu #burn [percentage of your balance] [contract address] ```
* % is percentage of tokens held in the wallet to be burned. ### Best Practices 1. Double-check all addresses and amounts before sending 2. For swap commands, avoid adding any extra text 3. Use ETH as the default token when possible for simpler commands 4. Make sure you have sufficient balance and gas fees