Q:

Does protobuf-net support named tuples? 

Does protobuf-net support the serialisation of named tuples? 
eg
 [ProtoMember(1)]
 protected readonly SortedDictionary<double, (double Bid, double Ask, double Open, double High, double Low, double Close, int Volume, int OpenInt)> FuturesCurveData;

A:

"Partly yes, partly no". 
protobuf-net has no specific knowledge of named tuples, and the names are not available to library code, but from v2.2.0 onwards, protobuf-net is able to infer a contract for ValueTuple<...> types, essentially treating it as a positional type - so Bid would be field 1, Ask would be field 2, etc.  Some code like GetProto<T> will not produce the results you expect (since a: it can't see the names, and b: the shape gets very odd for large tuples), and you won't be able to control fine-grained serialization details (DataFormat, etc), but: it should work. 
The following works fine:
using ProtoBuf;
using System. Collections. Generic;

static class P
{
    static void Main()
    {
        var obj = new MyType { FuturesCurveData = {
                { 1.0, (1, 2, 3, 4, 5, 6, 7, 8) },
                { 2.0, (2, 3, 4, 5, 6, 7, 8, 9) },
            } };
        var clone = Serializer. DeepClone(obj);
        foreach(var pair in clone. FuturesCurveData)
        {
            System. Console. WriteLine($"{pair. Key}: {pair. Value}");
        }
    }
}
[ProtoContract]
class MyType
{
    [ProtoMember(1)]
    public SortedDictionary<double, (double Bid, double Ask, double Open, double High, double Low, double Close, int Volume, int OpenInt)> FuturesCurveData { get; } =
    new SortedDictionary<double, (double Bid, double Ask, double Open, double High, double Low, double Close, int Volume, int OpenInt)>();
}

output:
1: (1, 2, 3, 4, 5, 6, 7, 8)
2: (2, 3, 4, 5, 6, 7, 8, 9)

And here's what GetProto<MyType>() produces - not quite such a success:
syntax = "proto2";
package System;

message KeyValuePair_Double_ValueTuple_Double_Double_Double_Double_Double_Double_Int32_ValueTuple_Int32 {
   optional double Key = 1;
   optional ValueTuple_Double_Double_Double_Double_Double_Double_Int32_ValueTuple_Int32 Value = 2;
}
message MyType {
   repeated KeyValuePair_Double_ValueTuple_Double_Double_Double_Double_Double_Double_Int32_ValueTuple_Int32 FuturesCurveData = 1;
}
message ValueTuple_Double_Double_Double_Double_Double_Double_Int32_ValueTuple_Int32 {
   optional double Item1 = 1;
   optional double Item2 = 2;
   optional double Item3 = 3;
   optional double Item4 = 4;
   optional double Item5 = 5;
   optional double Item6 = 6;
   optional int32 Item7 = 7;
   optional ValueTuple_Int32 Rest = 8;
}
message ValueTuple_Int32 {
   optional int32 Item1 = 1;
}

As a side note, it should work as a map<,> if the key type was int or string, but it appears to have hit a bug, which I have logged.