## Case 1
-The first option is to create a `HTTP Server` connection that handles incoming requests from a REST API. In this scenario, the REST API communicates with the AEA and requests are handled by the `HTTP Server` connection package. The REST API should send CRUD requests to the `HTTP Server` connection (`fetchai/http_server:0.23.0`) which translates these into Envelopes to be consumed by the correct skill.
+The first option is to create a `HTTP Server` connection that handles incoming requests from a REST API. In this scenario, the REST API communicates with the AEA and requests are handled by the `HTTP Server` connection package. The REST API should send CRUD requests to the `HTTP Server` connection (`fetchai/http_server:0.23.1`) which translates these into Envelopes to be consumed by the correct skill.
## Case 2
-The second option is to create a front-end comprising a stand-alone `Multiplexer` with a `P2P` connection (`fetchai/p2p_libp2p:0.26.0`). In this scenario the Agent Communication Network can be used to send Envelopes from the AEA to the front-end.
\ No newline at end of file
+The second option is to create a front-end comprising a stand-alone `Multiplexer` with a `P2P` connection (`fetchai/p2p_libp2p:0.27.0`). In this scenario the Agent Communication Network can be used to send Envelopes from the AEA to the front-end.
\ No newline at end of file
diff --git a/docs/connection.md b/docs/connection.md
index 07a2366a06..f760b1e3ec 100644
--- a/docs/connection.md
+++ b/docs/connection.md
@@ -36,7 +36,7 @@ The developer needs to implement four public coroutines:
- The `receive` coroutine is continuously called by the AEA framework. It either returns `None` or an envelope. The `receive` coroutine must implement the logic of data being received by the agent, and if necessary, its translation into a relevant protocol.
-The framework provides a demo `stub` connection which implements an I/O reader and writer to send and receive messages between the agent and a local file. To gain inspiration and become familiar with the structure of connection packages, you may find it useful to check out `fetchai/stub:0.21.0`, `fetchai/http_server:0.23.0` or `fetchai/http_client:0.24.0` connections. The latter two connections are for external clients to connect with an agent, and for the agent to connect with external servers, respectively.
+The framework provides a demo `stub` connection which implements an I/O reader and writer to send and receive messages between the agent and a local file. To gain inspiration and become familiar with the structure of connection packages, you may find it useful to check out `fetchai/stub:0.21.1`, `fetchai/http_server:0.23.1` or `fetchai/http_client:0.24.1` connections. The latter two connections are for external clients to connect with an agent, and for the agent to connect with external servers, respectively.
### Primary methods to develop - sync connection interface
diff --git a/docs/contract.md b/docs/contract.md
index ad1035c674..8b92e03799 100644
--- a/docs/contract.md
+++ b/docs/contract.md
@@ -18,16 +18,16 @@ Interacting with contracts in almost all cases requires network access. Therefor
-In particular, the `fetchai/ledger:0.20.0` connection can be used to execute contract related logic. The skills communicate with the `fetchai/ledger:0.20.0` connection via the `fetchai/contract_api:1.0.0` protocol. This protocol implements a request-response pattern to serve the four types of methods listed above:
+In particular, the `fetchai/ledger:0.21.0` connection can be used to execute contract related logic. The skills communicate with the `fetchai/ledger:0.21.0` connection via the `fetchai/contract_api:1.0.0` protocol. This protocol implements a request-response pattern to serve the four types of methods listed above:
-- the `get_deploy_transaction` message is used to request a deploy transaction for a specific contract. For instance, to request a deploy transaction for the deployment of the smart contract wrapped in the `fetchai/erc1155:0.22.0` package, we send the following message to the `fetchai/ledger:0.20.0`:
+- the `get_deploy_transaction` message is used to request a deploy transaction for a specific contract. For instance, to request a deploy transaction for the deployment of the smart contract wrapped in the `fetchai/erc1155:0.23.1` package, we send the following message to the `fetchai/ledger:0.21.0`:
``` python
contract_api_msg = ContractApiMessage(
performative=ContractApiMessage.Performative.GET_DEPLOY_TRANSACTION,
dialogue_reference=contract_api_dialogues.new_self_initiated_dialogue_reference(),
ledger_id=strategy.ledger_id,
- contract_id="fetchai/erc1155:0.22.0",
+ contract_id="fetchai/erc1155:0.23.1",
callable="get_deploy_transaction",
kwargs=ContractApiMessage.Kwargs(
{"deployer_address": self.context.agent_address}
@@ -37,22 +37,22 @@ contract_api_msg = ContractApiMessage(
Any additional arguments needed by the contract's constructor method should be added to `kwargs`.
-This message will be handled by the `fetchai/ledger:0.20.0` connection and then a `raw_transaction` message will be returned with the matching raw transaction. To send this transaction to the ledger for processing, we first sign the message with the decision maker and then send the signed transaction to the `fetchai/ledger:0.20.0` connection using the `fetchai/ledger_api:1.0.0` protocol. For details on how to implement the message handling, see the handlers in the `erc1155_deploy` skill.
+This message will be handled by the `fetchai/ledger:0.21.0` connection and then a `raw_transaction` message will be returned with the matching raw transaction. To send this transaction to the ledger for processing, we first sign the message with the decision maker and then send the signed transaction to the `fetchai/ledger:0.21.0` connection using the `fetchai/ledger_api:1.0.0` protocol. For details on how to implement the message handling, see the handlers in the `erc1155_deploy` skill.
CosmWasm based smart contract deployments
-When using CosmWasm based smart contracts two types of deployment transactions exist. The first transaction stores the code on the chain. The second transaction initialises the code. This way, the same contract code can be initialised many times.
Both the store and init messages use the ContractApiMessage.Performative.GET_DEPLOY_TRANSACTION performative. The ledger API automatically detects the type of transactions based on the provided keyword arguments. In particular, an init transaction requires the keyword arguments code_id (integer), label (string), amount (integer) and init_msg (JSON).
For an example look at the fetchai/erc1155:0.22.0 package.
+
When using CosmWasm based smart contracts two types of deployment transactions exist. The first transaction stores the code on the chain. The second transaction initialises the code. This way, the same contract code can be initialised many times.
Both the store and init messages use the ContractApiMessage.Performative.GET_DEPLOY_TRANSACTION performative. The ledger API automatically detects the type of transactions based on the provided keyword arguments. In particular, an init transaction requires the keyword arguments code_id (integer), label (string), amount (integer) and init_msg (JSON).
For an example look at the fetchai/erc1155:0.23.1 package.
fetchai/default:1.1.0 protocol which satisfies the following protobuf schema:
+fetchai/default:1.1.1 protocol which satisfies the following protobuf schema:
``` proto
syntax = "proto3";
@@ -121,7 +121,7 @@ message DefaultMessage{
fetchai/default:1.1.0 protocol. The protobuf schema is given above.
+fetchai/default:1.1.1 protocol. The protobuf schema is given above.