diff --git a/docs/01-architecture-intro.adoc b/docs/01-architecture-intro.adoc
index 7442fd43..6131546e 100644
--- a/docs/01-architecture-intro.adoc
+++ b/docs/01-architecture-intro.adoc
@@ -29,7 +29,7 @@ And for a request:
 - Is it for concrete data (_block #100_) or the latest (_get balance_)?
 - Is result a static value (_just block_) or may vary depending on network and node (_latest nonce_)?
 - Does it need to be repeated over multiple nodes (_broadcast transaction_)?
-- Request can also specify which subset of nodes should be able to execute the request by selecting node _Labels_ (see "link:09-quorum-and-selectors.adoc[Quorum and Selectors]")
+- Request can also specify which subset of nodes should be able to execute the request by selecting node _Labels_ (see "xref:09-quorum-and-selectors.adoc[Quorum and Selectors]")
 
 Based on these factors, Dshackle executes the request on a most optimal node.
 For most of the simple requests, it just gets a node that is synchronized to the point that must have a response for that particular request.
diff --git a/docs/07-methods.adoc b/docs/07-methods.adoc
index 73527369..171bbeb1 100644
--- a/docs/07-methods.adoc
+++ b/docs/07-methods.adoc
@@ -10,7 +10,7 @@ NOTE: It's not necessary to use gRPC, as Dshackle can provide standard JSON RPC
 
 === gRPC definition
 
-The source code for the Protobuf definitions could be found in link:../proto/[/proto].
+The source code for the Protobuf definitions could be found in https://github.com/p2p-org/emerald-grpc/tree/master/proto[/proto].
 
 .Service API
 [source,proto]