|
| 1 | +--- |
| 2 | +name: writing-bots |
| 3 | +description: Write a bot to continuously listen and respond to events on a public blockchain network. |
| 4 | +compatibility: Requires uv installed |
| 5 | +--- |
| 6 | + |
| 7 | +This skill describes when and how to a bot using the Silverback SDK. |
| 8 | + |
| 9 | +The user provides operational requirements such as which blockchain network they want it to run on, |
| 10 | +which smart contracts they want to interact with, what types of actions they want to take. |
| 11 | +They may provide additional context about technical constraints, or scenarios it must avoid. |
| 12 | + |
| 13 | +## Using This Skill |
| 14 | + |
| 15 | +**CRITICAL**: Before writing any Silverback bot code, you MUST: |
| 16 | +1. Use `web_fetch` to retrieve the latest documentation from https://docs.apeworx.io/silverback/stable |
| 17 | +2. Specifically fetch relevant pages like: |
| 18 | + - Development guide: https://docs.apeworx.io/silverback/stable/userguides/development |
| 19 | + - API reference: https://docs.apeworx.io/silverback/stable/methoddocs |
| 20 | + |
| 21 | +**DO NOT** rely on general knowledge about Silverback - always fetch the current documentation first to ensure accuracy. |
| 22 | + |
| 23 | +## Designing a Bot |
| 24 | + |
| 25 | +Before writing the bot, understand the types of actions you want to perform, |
| 26 | +and which on-chain or off-chain events you might want to monitor in order to trigger them |
| 27 | +- **New Block**: Do you want to perform an action on every block? |
| 28 | +- **Event Log**: Do you want to perform an action when a smart contract emits a particular event? |
| 29 | +- **Cron Job**: Do you want to perform an action on a time-based interval? |
| 30 | +- **Metrics**: Do you want to perform an action when a [metric](#defining-metrics) meets certain conditions? |
| 31 | + |
| 32 | +**CRITICAL**: Have a good understanding of the requirements first before proceeding to write any code. |
| 33 | + |
| 34 | +Then implement event handlers, which are callbacks implemented that trigger logic which might: |
| 35 | +- send a message on Telegram or Discord to a group or channel |
| 36 | +- send a social media post on X or Farcaster |
| 37 | +- send a POST request to another backend service |
| 38 | +- sign and broadcast a transaction on the listening chain and/or other blockchain(s) |
| 39 | +- measure a simple or derived [Metric](#defining-metrics) |
| 40 | +- provision a product or service |
| 41 | + |
| 42 | +### Defining Metrics |
| 43 | + |
| 44 | +In order to have visibility into the operation of the bot, |
| 45 | +it is often useful to define key "Metrics" or signal values that you can monitor over time to understand the real-world operation of the bot. |
| 46 | +This can also be very useful for monitoring purposes, but Silverback also lets you define event triggers based on the value of the metric. |
| 47 | +For example, if you've defined a complex metric based on the amount of trading volume occuring on a particular decentralized exchange pool in the latest block, |
| 48 | +you might want to trigger an action to occur when that volume signal is above or below a certain threshold. |
| 49 | +This can create more complex, reactive behaviors beyond what basic blockchain events can tell you. |
| 50 | + |
| 51 | +## Maintaining State |
| 52 | + |
| 53 | +Sometimes the actions you want to take in a bot depends on the results of other actions, |
| 54 | +so it is useful to maintain some internal state to track those results. |
| 55 | +Use internal state sparingly, and try to rely as much as you can on the blockchain state, |
| 56 | +or the state of other external services you've integrated the bot with in order to make correct decisions. |
| 57 | + |
| 58 | +## Managing Risk |
| 59 | + |
| 60 | +Overall, bots can do potentially risky actions and may end up being a part of critical user infrastructure. |
| 61 | +It is best to advise them on proceeding slowly and verifying the correctness of their implementation in stages, |
| 62 | +before more drastic steps like adding a signer to submit transactions or giving it access to a critical communications channel. |
| 63 | +You can easily do this through `print` debugging at first, |
| 64 | +or build-in operational modes based on the presence of a specific environment variable such as the availability of an API key, |
| 65 | +whether the `bot.signer` is configured, or based on other on-chain information like account balances. |
| 66 | + |
| 67 | +Also, you should suggest things like adding configurable limits (using environment variables via `os.environ`), |
| 68 | +emergency stop conditions (raising the `silverback.CircuitBreaker` exception), or others ways to effectively manage risk. |
| 69 | + |
| 70 | +## Running the Bot |
| 71 | + |
| 72 | +Only after the user thinks that the bot seems well-written and ready for testing should you install silverback and run it. |
| 73 | + |
| 74 | +To install silverback, run the following command with `uv` installed: |
| 75 | + |
| 76 | +```bash |
| 77 | +$ uv tool install silverback |
| 78 | +``` |
| 79 | + |
| 80 | +This will make the `silverback` cli command available. |
| 81 | +You can then run the bot on the `ecosystem` and `network` they want (such as "ethereum:mainnet") using: |
| 82 | + |
| 83 | +```bash |
| 84 | +$ silverback run --network <ecosystem>:<network> |
| 85 | +``` |
| 86 | + |
| 87 | +You can make the bot shutdown manually via ctrl+C, or sending the SHUTDOWN or KILL signal to the process. |
| 88 | + |
| 89 | +Monitor the bot's operations via it's logs and try to resolve errors until they rarely happen. |
| 90 | +Silverback can handle the occasional error, so you can't figure out exactly why something is failing, |
| 91 | +it could be okay to continue testing with. |
| 92 | + |
| 93 | +Ask the user to monitor their bot as well via the logs, and then ask if they like how the bot is working. |
0 commit comments